Hello !

I have downloaded the latest wwdotnetbridge github code and am trying to load a .Net Core assembly following one of the examples in the repo. I'm getting the "Cannot load instance of clrhost" which I have seen with some of our customers.

Nothing was blocked, and I'm running my test prg right out of the examples folder. I did notice that I didn't have WWIPStuff.dll in that folder, so I added one I had from 2018.

All the assemblies and code I downloaded are from 7/3/2020.

I've checked all the usual culprits. I am the administrator on the Win 10 machine I'm testing this on.

Any help much appreciated!!

Thanks Gary

The error is being thrown because the value below = 0:

lnDispHandle = CoreClrCreateInstanceFrom(lcRuntimePath,lcVersion,@lcError,@lnSize)

lcVersion = 7.9.0.0 I have .Net Core 5.0 installed. The lcRuntimePath = C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\5.0.2

My question is what file is the above command trying to get a handle of?

Thanks

Check here:

Unable to load CLR Instance in wwDotnetBridge

The 'unblocking' should no longer be a problem with recent versions, but running from a network share will be unless you add the .config file.

+++ Rick ---

Hey Rick! It's good to see you - looking good.

I'm working directly out of the Examples folder that I downloaded from the Github repo. In that folder, there is a dotnetcore.prg that is throwing that error, although the other examples that use the standard wwdotnetbridge do not throw that error.

I compiled a project as an .exe and included a exe.config file for it, and I still get the error on CREATEOBJECT("WWDOTNETCOREBRIDGE"). I do not get the error when I do CREATEOBJECT("WWDOTNETBRIDGE").

The .dlls are not blocked and they are in the same folder. I am not working on a network share.

The error is being thrown because the below line returns 0:

lnDispHandle = CoreClrCreateInstanceFrom(lcRuntimePath,lcVersion,@lcError,@lnSize). The .netCore folder being looked at in the lcRuntimePath is v5.0.03.

Thanks for your help! Gary

Are you using the Open Source version? If so it doesn't include the .NET Core version yet. It's only in the Web COnnection and West Wind Client Tools versions at this point.

+++ Rick ---

I'm using what I downloaded off of the Github repo. It's about time I actually buy something again:) More than worth it. Thanks, will purchase Client Tools asap.

I appreciate that.

Unfortunately I just checked and I see the same problem you ran into. I'm looking into it, but having installed a new machine a few days ago I have to get my C++ compiler tools working again with an old Windows SDK - it's a bloody nightmare to get that installed.

Oddly I checked this just a few weeks ago and it was working fine, so not sure what would have broken in the interim other than Microsoft shifting around hosting APIs once again.

FWIW, if at all possible do not use .NET Core but use full framework instead. While the core stuff works it's a lot more 'experimental' at this point than the full framework stuff that's been in use for many years.

I'll see what I can find once I can get the compiler working... I think it'll be time to update to more recent SDKs that don't include support for XP and Vista... 😦

+++ Rick ---

So the client tools I just purchased won't work 😦

In any event I have to retrofit a legacy VFP app to talk to a .net Core SignalR client that I wrote. I wanted to just use .net Framework, but the hub for the SignalR is written in Core, and it doesn't allow the framework signalr client to work with it. It gives 405 errors. https://stackoverflow.com/questions/49152486/signalr-version-compatability-statuscode-405-method-not-allowed

It looks like I'm going to have to wrap the signalr client with a windows service and have it run in the background and exchange information between it and VFP using .json files via file watchers. Ouch.

If you have any ideas on how best to accomplish this another way, well, your tools and ideas have proven extremely useful to all my VFP/.Net efforts for well over a decade, maybe 2.

Thanks Rick

Gary

Also another important point:

Make sure you have the 32 bit version of the .NET Core Runtime installed. wwDotnetBridge can only work with 32 bit targeted components and the 32 bit .NET Core runtime since FoxPro is a 32 bit app.

.NET Core Downloads

Look for .NET 5.0 SDK | x86

Unfortunately I don't know of a good way to check for both 32 bit and 64 bit version. All the .NET Core tooling works only with whatever version was last installed. So dotnet --info tends to give the 64 bit version. You can tell which one based on the file locations either in Program Files or Program Files (x86).

+++ Rick ---

After some more poking around here's what I found:

The problem is with .NET Core 5.0 which apparently has changed the hosting APIs - it won't allow returning an IDispatch object in the same way as earlier versions did.

You can use .NET Core 3.1 and it will work.

I have an issue open on GitHub to see if there will be a workaround for NET 5.0.

• .NET Core Hosting Issue

+++ Rick ---

You can probably re-target or multi-target for .NET Core 3.1 and .NET Core 5 for your SignalR client and then you should be able to use it with wwDotnetBridge now.

The other option is: .NET Core objects can be instantiated as COM objects. Not sure how this works actually since the registration tools are no longer in Core, but I know that Core supports COM objects via the same old COM Class attributes. You can instantiate your object as COM and either call that or pass it through wwDotnetBridge and get access to the wwDotnetBridge features from the COM reference (if you need things beyond simple access).

+++ Rick ---

So after doing some more research and debugging I was able to get wwDotnetCoreBridge to work with .NET 5.0. It turns out it was due some new incompatibilities of deprecated configuration values in .NET Core 5.0 that caused the main class to not instantiate. That works now. Yay!

Updated archive with those changes can be found:

Web Connection Experimental Updates

Thanks for posting this. I haven't had a need to use .NET 5.0 (or Core 3.1) components yet, so your report at least pointed to a problem that needed addressing.

Going forward, the current approach of using a .NET Framework library with .NET Core is probably unsustainable as features of those platforms diverge, but for the moment it looks like most features of wwDotnetBridge work just fine in .NET Core.

+++ Rick ---

Thanks Rick! I will be working with this today and I'll keep you posted.