ReportAppServer: Different compile version and runtime version caused MissingMethodException

[Former Member]

Hi

I have a project which called ReportAppServer api which refers 13.0.10.xxxx assembly.

But when application runs on machine installed 13.0.13.xxxx.  Following code throws an MissingMethodException.

var printOptions = clientDoc.PrintOutputController.GetPrintOptions();

Error message:

Error: Missing method 'instance class CrystalDecisions.ReportAppServer.Controllers.PrintOutputController [WindowsFormsApplication4] CrystalDecisions.ReportAppServer.ClientDoc.ISCDReportClientDocument::get_PrintOutputController()' from class 'CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper'.

My project is very simple,

            CrystalDecisions.CrystalReports.Engine.ReportDocument rpt = new CrystalDecisions.CrystalReports.Engine.ReportDocument();

            rpt.Load(rptPath);

            CrystalDecisions.ReportAppServer.ClientDoc.ISCDReportClientDocument clientDoc = rpt.ReportClientDocument;

            var printOptions = clientDoc.PrintOutputController.GetPrintOptions();

Project was compiled as x86, references are x86 and client machine installed x86 CrystalReport.

Can you please tell me why throws this exception and how to solve?

Thanks,

Hugh

[former_member11696 · Accepted solution]

Hi Hugh,

You are likely getting that error because there have been updates to the Printer Classes, new members have been added, SavedPrinterName and SavedPaperSize are a few. So the expected pointer for the entry to that class has changed...

Only way to fix it would be to install SP 13 on your DEV PC and recompile and redistribute your executable.

Don

[michaelrybicki]

I had a similar issue today and saw this thread and proved out the solution to be correct. But I actually went a little farther and found something out. If I compile on a Dev machine with SP13 to SP15, I was not able to run on any client that is running SP12 or earlier. So between SP13 and SP12, there's is not backwards compatibility? This seems like a crazy concept to me just between service packs. So if I deploy patches regularly to customers (basically Xcopy upgrades) and I have thousands of users, I must keep all my Developers and Users stuck on SP12. Otherwise - I'm looking at a massive upgrade across all users and dev to get the fixes in SP13 and beyond.

Is that the hard truth or am I missing something? I understand I could go thru the trouble of compiling on two different machines with two different SAP Dev Tools installed (SP12 and SP15+), then query which version is installed in a launcher to execute the compiled version that matches the client environment, but OMG that seems crazy.

[DellSC]

Think about what you wrote:  "I'm looking at a massive upgrade across all users and dev to get the fixes in SP13 and beyond".  Since the fixes don't exist in the earlier runtime, they wouldn't actually appear in your updated application unless the updated runtime is also available.  Yes, some service packs can have major changes in them and you should always match the installed runtime with the version of the SDK that your application is compiled with.

-Dell

[michaelrybicki]

Thank you for the reply Dell. However, respectfully, I DID think about what I wrote - A LOT. But maybe I didn't explain my perspective well enough as a software developer so I will elaborate.

There is not one piece of 3rd party referenced software that I have ever seen where changing service pack levels would break compatibility - especially backwards.Different versions are a completely different story. I believe .NET actually allows you to account for target versions in some scenarios by using app.config files, however I've never messed with that and I am pretty sure that doesn't work when the base version is the same like this Crystal scenario.

Here's another way to look at it:

Consider a client machine, that has two different software applications (from two different vendors) that reference SAP Crystal Reports version 13. Because of this matching Compile Version vs. Runtime version requirement, if Vendor A decides to support SP15 and Vendor B still compiles on Service Pack 12 because they are not ready for Service Pack 15 because they can't deploy the Service Pack to all their users, then as soon as Vendor A decides to push out their update compiled code using SP15, and release SP15 runtime as part of their upgrade, they have broken Vendor B's application.

If that's true, then this is the return of DLL Hell. One of the reasons people like the .NET Framework is that madness is gone.

[former_member11696]

Hi Michael,

CR .NET has dependencies on COM dll's and Native C++ dll's as well so it's not pure .NET. That would have required a complete rewrite which is simply too much work to do.

When Microsoft announced they were dropping COM and moved to the Framework. We committed to the Framework, as a wrapper around our native C++ and COM components, then MS reversed and COM is still supported. TO late for us as we committed to much into the framework... So long to the RDC....

The whole core CR engine is still based on crpe32.dll and basically everything we have wraps around it in one way or another. The basic engine has not changed much, it's all in the wrappers where things are getting enhanced.

So to enhance our .NET components to be more like crpe32 days we've added updates to some API's, new members, and created new ones to expose what people have been asking for. The side effect is it does from time to time require you to update your project and recompile and redistribute the new updates. Even if you do not take advantage of the enhancements you still need to rebuild.

So if you do not want to update your project then don't redistribute the update runtime packages.

If you need the updates to be able to support new third party updates like Windows 10 or new DB clients/servers then your only option is to update/recompile/redistribute everything....

This product does not patch previous patches for just platform updates. To much to maintain...

CR for VS is a free product ( mostly, see licensing for details) for our CR users.

So I understand where you are coming from, but the answer is simple, update, recompile and redistribute.

If you do not need to support new platform updates then don't update the redist packages for your application....

Also, not every release has an enhancement or new property so 90% of the time a simple update to the redist package is all that is required.

Don