TOPIC:

Trying to run ReportPro2 2.38 for X# 2.60 ends with the following exception:

Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.MissingMethodException
at ReportPro2_Base.Functions.rpLoadLanguageDLL()
at ReportPro2_Runtime.Functions._LoadRpLanguageDLL()
at ReportPro2_Runtime.Functions.$Init2()
at <Module>.$AppInit()

Running it from an X# application via runtime dll also produces the same exception.

To specify a bit more - it doesn't run when XSharp 2.8a is installed.

Michal and Trimel,

Sorry about that guys, accidentally this version (2.38) uses something from the X# runtime that is only available in our current internal build (2.9), which means that it will be working fine after the new build is released in a few days.

In the meantime, can you please download and install the RP2 2.36 version instead? If there's something included in 2.38 that is necessary for you now, please let me know and I will recompile it with X# 2.8 and will send you new binaries.

.

Chris,
You are right. I checked it too and this build uses the new overloads for Empty() that we added to the runtime.
I will recompile 2.38 against the older runtime tomorrow.

Robert

Robert,

It's also using the new RuntimeState:CompilerOptionFox2 property.

.

It's OK, we're still only trying out our options for migration from VO to X# and we're not bound to any specific version yet. ReportPro2 2.36 works so far.

A new installer for RP2.39 for X# has been uploaded to the website. This fixes the issues with 2.38.

Check here:
www.xsharp.eu/itm-downloads/download?pat...p2Net239XS-XS260.zip

Robert

Hello Robert.

This time ReportPro starts. But when I open an existing report or select File/New it crashes immediately. Also when I limit the DOS path to the ReportPro directory itself, so I suspect it has nothing to do with my installed X# 2.7 instead of 2.8x.

Below the Application Log data (EDIT: I added one more entry, something is missing, not sure if that is dependent on an installed 2.8 or not)

Dick

Faulting application name: ReportPro2.exe, version: 2.39.0.4, time stamp: 0x616ee972
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0x448a4f5d
Exception code: 0xc000041d
Fault offset: 0x0012b5b2
Faulting process ID: 0x1a90
Faulting application start time: 0x01d7c506bf9ee14c
Faulting application path: C:\ReportPro239XS\Bin\ReportPro2.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report ID: 17982c64-f026-485b-8c2b-fa5e7c04413e
Faulting package full name:
Faulting package-relative application ID:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Application: ReportPro2.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.MissingMethodException
at ReportPro2.RpReportDesigner.Dispatch(XSharp.__Usual[])

Exception Info: XSharp.Error
at XSharp.RT.OOPHelpers.SendHelper(System.Object, System.Reflection.MethodInfo, XSharp.__Usual[], XSharp.__Usual ByRef)
at XSharp.RT.OOPHelpers.SendHelper(System.Object, System.String, XSharp.__Usual[], XSharp.__Usual ByRef)
at XSharp.RT.OOPHelpers.DoSend(System.Object, System.String, XSharp.__Usual[])
at XSharp.RT.Functions.__InternalSend(XSharp.__Usual, System.String, XSharp.__Usual[])
at VO.__DocApp.Dispatch(XSharp.__Usual[])
at VOGUIClasses.Functions.__WCDocAppWndProc(Void*, UInt32, UInt32, Int32)

Dick,
sure, you got 2.39?
Just got me the download, installed, run designer, open my designed rpts, works.Called rpts from app, works, too.
Thx Robert!

Karl,
Dick tries to use it with X# 2.7.
I'll check to see why this does not work.


Robert

Dick,

The reason that this fails is that I compiled the ReportPro assemblies against the 2.8 runtime.
And this build contains one small change compared to the 2.7 runtime:
We got a request from a customer to add an overload to the array class that accepts 2 indices, instead of an
overload that accepts an array of indices.
The new property isThe old property (which still exists) isTo use the old property the compiler would have to create an array of integers to hold the 2 indices needs to
access an array element.
That is slightly less efficient than the new code with 2 simple INT parameters

The Dispatch method has a event that reads the file names for the Recent files from a 2 dimensional array.
And the .Net runtime fails because the code uses the new property which does not exist in your 2.7 runtime.

We always strive to make our product backward compatible. So old code will still run with newer runtime.
But the opposite is difficult / impossible as this shows.

We could solve this by recompiling ReportPro against 2.7, but I am not sure that I want to do that.
Version 2.7 is from Nov 2020. Do you really have to use this version ?

Robert

Hello Robert,

Do you really have to use this version ?

O no, not at all so please don't spend time on that! I assumed that it didn't use the X# 2.7 files because I see all x*.dll's in C:\ReportPro239XS\Bin and I ran it from a DOS prompt with Path=C:\ReportPro239XS\bin set and Reportpro2.exe started from that DOS prompt.

To be honest I don't understand why it still crashes with all those X# and VO dll's in the bin directory and no path pointing to my X# 2.7 installation. But if Karl gets it working it assume it still needs something in the X# directory which will let it crash with the same error if that Dispatch isn't found (because of path to X# 2.7) as when the whole DLL isn't found (because of no path),

And of course, when used together with X# 2.8/2.9 it will find all DLL's from X# anyway. I was just trying and as I saw it fail I thought that there must be something else still wrong. Sorry I wasted your time!

Dick

Dick,

ic2 wrote: To be honest I don't understand why it still crashes with all those X# and VO dll's in the bin directory and no path pointing to my X# 2.7 installation. But if Karl gets it working it assume it still needs something in the X# directory which will let it crash with the same error if that Dispatch isn't found (because of path to X# 2.7) as when the whole DLL isn't found (because of no path),

It crashes because the 2.7 DLLs are in the GAC.
The .Net runtime gives precedence to DLLs in the GAC over the same named DLLs in the current folder because the DLLs in the GAC are "pre-validated".

We have (deliberately) kept the Assembly version numbers for the X# Runtime DLLs the same since 2.6, so a newer version (2.7, 2. of the DLL can replace the older version and you do not have to recompile old code. If you would register the X# runtime DLLs from the Reportpro bin folder in the GAC then it would work on your machine too.

Btw for .Net Core they have changed things: assemblies are no longer installed in the GAC. You are expected to deploy your app as "self-contained" with all the DLLs that it depends on in the same folder.
That will cost a bit more disk space, but can prevent problems like these.

Robert

Hello Robert,

robert wrote: Btw for .Net Core they have changed things: assemblies are no longer installed in the GAC. You are expected to deploy your app as "self-contained" with all the DLLs that it depends on in the same folder.

That is big news. It means that actually Microsoft improved something by correcting a goof from the past which the GAC is. That is, I would say, a once-in-a-decade event.

Dick

Hi Dick,

I would say they are removing a good feature, because they failed to adjust it to work as it would be natural to do so. A fix would be very easy, to just give priority to the dlls in the app folder, instead of those in the GAC...

Even right now, you can simply uninstall all runtime XSharp dlls from the GAC and the problem will go away. (But please don't do it, better just install the latest build and all will be fine again)

Hello Chris,

As often, you are right with your observation that giving priority to DLL's in a folder instead of the GAC would have been better (I saw several posts of people, also from Microsoft, actually writing something like this "While executing .Net will first look in to your Bin folder for referenced dll. If found it will use that, if not it will search for GAC". The GAC has been a source of trouble for throughout the years, probably all because it doesn't work like that.

If it did work like that, I suppose suppliers could decide not to install commonly used DLL's in their program directory because they are installed in the GAC. On the other hand, the safest way to guarantee a working environment of any software is to install all DLL's connected to the installed version, even if the same DLL's are installed in multiple program directories, as it would prevent issues like mine with ReportPro. And if that's the safest solution anyway, I see no advantage in the GAC, even if it worked like a normal programmer (=someone not working for Microsoft) would expect.

Dick

Hi Dick,

The GAC is very useful, because it can be used as a central space of having all common dlls together, without needing to put them in every single folder of .Net apps that you use/develop. If managed correctly, when new versions get released, it is so much easier updating the dlls in one common place, instead of having to do it in dozens of places and probably missing some. With a properly implemented GAC, all .Net apps would be using the same common dlls, and only the apps that need specific versions, would have different dlls versions directly in the bin folder. But..., MS....

.