.Net 8 Nethost/Hostfxr implementation

[horch004]

Hi Rick,

We use your wwDotnetBridge many years now. Although a bit rewriten over time. It runs very stable in our classic asp application.

I saw you had a newer bridge to the .net core versions. For a normal desktop application it seems to work. But in an asp environment it is crashing. I also found your question (from 2019) on the github issue page of dotnet about the issue.
From there I picked up the sample code of microsoft, using the nethost / hostfxr approach, and rewrote it. I only had to add a delegate to your wwDotnetBridge factory class matching the CreatewwDotnetBridgeByRef factory method which is called from the unmanaged code and returns an IDispatch pointer.

So, I have implemented the new functionality, based on the nethost / hostfxr approach, in the ClrHost which I now use in our asp application. It is not crashing anymore and on every request our vfp dll can re-attach to the .net 8 runtime. It is still in an early test phase, but it seems promissing. Our c# assemblies could be upgraded to .net core (VS .Net Upgrade Assistent extension) with little modifications afterwards.

Are you interested in the code? I can also zip the whole project and upload it. You probably have to rewrite some code to fit it in your project. But that's probably piece of cake.

Regards, Wijnand

[horch004]

Hi Rick,

There might be a trick for you to explore in your implementation.
Because VFP loads the dll, it also unloads it when finished. In a classic Asp environment this makes it unstable and when unloaded we cannot attach to the runtime again.
My implementation is able to attach, thereby not really suffering of losing the IDispatch handle. Because my implementation needs the path to the module I use GetModuleHandleEx (and GetModuleFileName). I found out that passing GET_MODULE_HANDLE_EX_FLAG_PIN as flag, the module will be prevented from unloading. Even if VFP tries to unload it.
This way it seems the static variables are kept alive.

So, you could just make a call the this function with that flag and you might be done.
Advice is to keep the IDispatch pointer (CComPtr) as a global static variable and do the AddRef in the C++ code instead of the VFP code (SYS(3097, this.oDotNetBridge)). The AddRef might be unnecessary at all, but just for insurance.
At the beginning of CoreClrCreateInstanceFrom just return the IDispatch pointer when not null.

void module_handle_function() { }
HMODULE GetClrHostModuleHandle()
{
	HMODULE hm = NULL;

	void* address = module_handle_function;

	// The GET_MODULE_HANDLE_EX_FLAG_PIN flag seems to prevent VFP of unloading and clearing memory.
	GetModuleHandleEx(
		GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_PIN,
		(LPCSTR)address,
		&hm
	)

	return hm;
}

(removed error handling for clarity)

[RickStrahl]

Sorry for the delay on this - I had missed messages from this repo for some time.

So is this the primary change or are there additional changes? As long as this doesn't muck up the NETFX version anything that makes to Core version more reliable would be good 😄 as I've seen issues too when you do CLEAR ALL/RELEASE ALL which immediately kills FoxPro.

Probably better to look at the entire code - I'm not quite sure where this code would go to test.

[whorchner]

Hi Rick,

I moved the code from my personal github to a repository under our company github account. It is a private repository, so I added you as collobarator to be able to view the code. You may copy and use anything you like. But please do not change the code of this repository.

In the readme I tried to explain the changes compared to your codebase. I hope I did not forget something.
Questions and/or comments are welcome. We are still developing in Vfp side by side with C#. So, C++ is not really my expertice.

[RickStrahl]

Yeah me either. I cobbled the Core Runtime loader together from the sketchy MS documentation at the time.

I'll take a look at your repo later today and see what I can see. If you've had this in production and it's working it's getting more testing that way than it's gotten from me 😄 I'd settle for just being able to:

• load the runtime
• make some calls
• CLEAR ALL/RELEASE ALL etc.
• load again

Currently in my existing version the second reload will crash FoxPro on trying to reload the runtime which I suspect is the same issue that you were describing. When clearing in FoxPro, all memory of all the statics is wiped - so no way that I can see to detect that the runtime is already loaded or get back the global static values.

Clearly the Core loading works very differently than the NETFX loading.

Thanks for looking into this.

[whorchner]

The implementation runs now from Januari in production very stable (formdesk.com with a server farm). Even more stable than the framework. Pinning the clrhost to memory is the biggest win I think. I tried that also with the framework version, but somehow that crashes that version under load. Without the pinning, the core version also crashes under load. But the core version now does not have any issues with Vfp clearing memory.

[RickStrahl]

If the pinning is all that's needed that would be the easiest for sure. I've looked at your code, but I'm not sure where this would go in the existing implementation.

The original implementation does work - it's just as you point out, if anything clears memory, all the DLL gets completely unloaded and memory with it. Then a reload fails as the appdomain still exists and tries to create the same domain again would be my guess.

Anyway - let's see if I can get your code to run - that would work for me too.

I'm not clear however, how that code works with both .NET FX and Core - we can discuss on the other repo. Is there any reason that repo needs to be kept private? Might be helpful to have others take a look as well.

[RickStrahl]

So you hint that GetClrHostModuleHandle() with module pinning would likely fix the problems I was running in proved completely correct.

I added the module check on start up of the .NET Core load sequence and this fixed the issue where .NET Core was crashing after a RELEASE ALL (or similar) in VFP as that code wiped out all global state in CoreClrHost/wwIPstuff module.

The following does the trick:

void module_handle_function() noexcept
{
}


BOOL CoreClrLoad(char* runtimePath, char* errorMessage, DWORD* size)
 {

	// The GET_MODULE_HANDLE_EX_FLAG_PIN flag seems to prevent VFP from unloading and clearing memory.	
	HMODULE hm = NULL;
	void* address = module_handle_function;
	GetModuleHandleEx(
		GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_PIN,
		(LPCSTR)address,
		&hm
	);

It appears that NETFX can reload the runtime (or internally see it loaded and then abort), but .NET Core will try to load the runtime again and blow up due to null pointers.

This seems to fix the issue on my end.

Maybe you'd want to give the updated original code a try in your IIS environment and see if that fixes the instabilities you were seeing.

Sounds like your new code is working for you, but I've had no luck getting your code to work - I think it's due to not being able to locate the runtime and requiring runtime version.

IAC - many thanks. This at least fixes the most visible issue...

[whorchner]

The code my implementation is based on comes from the samples of Microsoft. It is Ms prevered way of connecting to .NET Core.
Did you see the comments at https://github.com/whorchner/wwDotNetBridge/issues/1 ?

---

The implementation needs the nethost.dll in the same directory as the ClrHost.dll. From this nethost.dll the ClrHostFxrWrapper::LoadExports() function exports the function get_hostfxr_path. I think I tried something with compiling it into the ClrHost.dll, but I could not get that to work, but I am not sure. But this way work for us.
I added the nethost.dll to the ForText directory and committed it into the repo.

[whorchner]

The ClrHostFxWrapper.cpp is the workhorse and most of it code from MS.

The issue with your implementation was (as I remember) that the .NET core runtime can only be loaded into a process once and there is no way of reconnecting to the already loaded runtime when the memory of VFP has been cleared. Pinning the clrhost.dll to memory what keeps the host handle pointer alive, maybe even when VFP gets unloaded en loaded again, might be a good solution. But for us it is not the most confortable way.

I suppose we can assume all requests can use the initial host handle from the clrhost.dll which is now pinned into memory for the lifetime of the process. But in a MS multi-threaded environment where things under load can get a bit unpredictable, the ability to reconnect to an already loaded runtime (which nethost and hostfx offer) feels more save and confident. The application has since never crashed due to a bridging with .net core issue. The current exception handling in the implementation never got triggered and might be overdone.

[RickStrahl]

I don't think so - the reference to the host handle is static and process specific. You can't load multiple instances regardless of what you do. While I agree that the new approach is probably preferred as mentioned I couldn't get that code to locate the runtimes and work reliably both with .NET FX and Core.

I'm sticking with the old code at this point will revisit when I have more time to look at the newer implementation when I can find some decent documentation on the MS site.