One of the things lost in the migration of reporting from an internal engine within AX to the SSRS reporting engine is a good compare tool and a good merge tool.
From within AX, comparing two layers of the same report is technically equivalent to comparing the two underlying RDL files, which is an unfriendly and extremely raw way to be forced to deal with SSRS reports as complex as those that are provided with AX. It can be done, but comparatively speaking (compared to 4.0 and 2009) it is very much lacking in one of the strengths of AX as a platform -- the value of layers, comparing an object between its layers to identify changes, and merging those changes between versions or from changed lower layers.
Furthermore, there seem to be some real performance issues with comparing SSRS reports within the AX client. The larger reports, of which the largest is clearly SalesInvoice, often grind away for 10 to 20 minutes before finally crashing the AX client. This has been reproduced by Microsoft, but no fix will be forthcoming because the crashing can be resolved by giving the client more memory (something on the order of 12 GB apparently for SalesInvoice), and the underlying performance of this process is apparently unimportant.
By contrast, I can export SalesInvoice to an XPO file and compare with another tool like WinMerge or even WinDiff and get results within seconds. By the way, the resulting XPO will be approximately 20 MB in size, so one has to wonder why comparing two 20 MB files should require memory in the order of multiple GB.
How are developers dealing with this? How are you doing SSRS report compares in a way that is time efficient and lowers your development time and TCO of the product? How are you working around the performance issues of doing straight compares within AX for SSRS reports? How are you merging changes from lower layers that come from CU's and SP's into your SSRS reports?
Thanks in advance.