TOPIC:

Greetings XSharp developers.

While we are still in the process of migrating old CAVO 2.8 applications to X#, I got the idea to try to run ReportPro3 X# via a wrapper .NET library to avoid issues in CAVO->X# type mismatches.
If I call ReportPro3 X# via this wrapper from a tester .NET application, it works perfectly fine, but if I try to run it from a CAVO application, the XSharp.Core.Functions.WorkDir() function throws an "Object reference not set to an instance of an object." exception.

I then tried to call just the XSharp.Core.Functions.WorkDir() function outside of ReportPro3 X# entirely and it produces the same exception.
So I'm thinking if there is some kind of property CAVO applications do not set in their application thread which the WorkDir() function requires, or am I missing something else?

Michal,
Are you calling the .Net app as a COM Object?
Maybe the runtime state is not properly initialized?
Can you create an example ?

Robert

The wrapper is a .NET 4.7.2 library registered in COM via RegASM.exe, and the wrapper class is then instantiated in CAVO using OLEAutoObject.
I will try to put some minimalistic example together.

robert wrote:

Can you create an example ?

There are two projects in the attached file.
One is a Visual Studio 2015 solution with the wrapper library and a WPF tester application. Run it and press the button, it calls the mentioned function just fine and displays the working directory in a message box.
The other is a CAVO 2.8 SP3 project which calls the same wrapper library. Run it and press Open file. It gets the object reference error.
Don't forget to register the wrapper library, there is a BAT file included to do this.

Michal,

Thanks for the example.
I see that you are using X# version 2.8a from May 2021.
This was fixed in a build after 2.8a (in October 2021).
If you use the latest build of X# this should work correctly.
The original code was using System.Reflection.Assembly.GetEntryAssembly() to fetch the main assembly.
In the case of a component running from COM this main assembly is not a .Net assembly so the call returns a NULL_OBJECT.
As alternative we now fall back to System.Reflection.Assembly.GetExecutingAssembly() which returns the location of the XSharp.Core.DLL.

Robert

Great, thanks, Robert. I will get the latest build then.