xsharp.eu

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 is The old property (which still exists) is To 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:ReportPro239XSBin and I ran it from a DOS prompt with Path=C:ReportPro239XSbin 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.8) 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....

.