VFP and .NET Interop
wwDotNetBridge strange issue with CLR version.
Gravatar is a globally recognized avatar based on your email address. wwDotNetBridge strange issue with CLR version.
  AlanBourke
  All
  Jul 5, 2017 @ 04:50am

I am leveraging a .NET 4.5.2 assembly via wwDotNetBridge. On this particular PC an odd problem seems to be happening with the detection and loading of the most up-to-date .NET version. The machine in question has CLR 2.0 SP2 and CLR 4.7 installed.

The problem is that wwDotNetBridge seems to be loading CLR 2.0 no matter what I do.

The VFP code is in essence:

Do wwDotNetBridge
this.oBridge = GetwwDotnetBridge()			&& Passing "V4" doesn't work either.
llDotNetBridgeLoaded = Iif(Vartype(this.oBridge) = "O", .t., .f.)
If llDotNetBridgeLoaded
    && At this point this.oBridge.GetDotnetVersion() will return '2.0.50727.8669'
endif

If I step into GetwwDotnetBridge() it picks up CLR 4 correctly all the way through, e.g.

GetWwDotNetBridge() -> GetHighestDotnetVersion() returns "v4.0.30319"

then __DOTNETBRIDGE doesn't exist yet so is created with lcVersion = "V4.0.30319".

The Init() of the wwDotNetBridge class sets cClrVersion to "V4.0.30319"

and then into the Load() of the wwDotNetBridge class.

So presumably wwDotNetBridge.Load() is loading the wrong CLR somehow because the subsequent call to GetDotNetVersion is returning '2.0.50727.8669'

What could this be?

Gravatar is a globally recognized avatar based on your email address. re: wwDotNetBridge strange issue with CLR version.
  Rick Strahl
  AlanBourke
  Jul 5, 2017 @ 12:49pm

Alan,

Not quite sure I understand what you're saying. The CLR should only load once - it can only load once and whatever version loads first is the version that is available throughout the rest of the VFP app's lifetime.

The .NET Framework internal detection of the latest version broke with .NET 4.5 and later - that no longer works. The ww tools try to read the latest version by actually looking at the install locations and that's how that works now, but that also isn't 100% reliable (although I don't remember why exactly at the moment).

Anyway - at this point I highly recommend that you explicitly specify the version number on startup using InitializeDotnetVersion(). Also make sure you have the latest version of wwDotnetBridge (6+) as I've changed the default to .NET 4.0 if nothing is specified. Looking at the code i see that GetwwDotnetBridge() still uses GetHighestDotnetVersion() but it really shouldn't. That's coming out - thanks for pointing that out.

Version 6.12 introduced:

which is meant to explicitly set the .NET version used in the FoxPro host context. Use it at the beginning of the application to load a specific version that your application expects.

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: wwDotNetBridge strange issue with CLR version.
  AlanBourke
  Rick Strahl
  Jul 6, 2017 @ 03:22am

Thanks. I did have a really old copy of wwDotNetBridge so I've updated that in line with your suggestions.

This is an add-on to an existing product and it seems that another component outside my control is getting V2 of .NET loaded before me. So I may have to make my bit COM-callable instead to get around this.

Gravatar is a globally recognized avatar based on your email address. re: wwDotNetBridge strange issue with CLR version.
  Rick Strahl
  AlanBourke
  Jul 6, 2017 @ 02:29pm

Well you won't be able to load multiple runtimes into FoxPro either way. You can try forcing the runtime with a .config file entry:

<?xml version="1.0"?>
<configuration>
  <startup>   
     <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.2" />
  </startup>
  <runtime>
       <loadFromRemoteSources enabled="true"/>
  </runtime>  
</configuration>

But that may still not work if the application explicitly sets the version to 2.0 before you.

FWIW, you can still use wwDotnetBridge with COM Interop COM Registered instances (ie. using CREATEOBJECT()) - the problem you're butting up against is the runtime loading itself.

If you control the component you can potentially just compile it for .NET 2.0 - and it will work fine in 4.x, but that will make it run on 2.0 whereas a 4.x compiled component will not run on 2.0 (you get an Assembly Load Error).

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: wwDotNetBridge strange issue with CLR version.
  AlanBourke
  Rick Strahl
  Jul 7, 2017 @ 09:32am

Thanks.

Mine is not a majorly complicated assembly (just wraps SmtpClient really) so it didn't take much to add the COM attributes and test it. Seems to work OK so I'll just do it that way. Not sure why this other thing is still .NET 2.0 in this day and age but I have no control over it!

Gravatar is a globally recognized avatar based on your email address. re: wwDotNetBridge strange issue with CLR version.
  Rick Strahl
  AlanBourke
  Jul 8, 2017 @ 12:51pm

The attributes aren't the problem - registering on client machines is since it's not just COM registration, but also .NET Interop registration with RegAsm.

I guess it's a unique problem where you don't control the runtime loaded and they're using an old runtime version.

FWIW, West Wind Client Tools includes a wrapper around SmtpClient in the wwSmtp class (Mode = 0).

+++ Rick ---

© 1996-2024