Explict .NET Runtime Version Specification

There are two main versions of the .NET Runtime in circulation today, with .NET 2.0 becoming more obsolete by the day.

.NET 2.0 Runtime
This version of the runtime includes .NET 2.0, 3.0 and 3.5. All of these versions use the same base 2.0 runtime with the 3.x versions adding additional libraries, but the underlying runtime version number is still 2.0. Version 2.0 is no longer installed by Windows 10, and most modern applications using .NET use a 4.0 version of the runtime.
.NET 4.x Runtime
This version of the runtime includes any version post 4.0 including 4.5.x, 4.6.x and 4.7.x. These runtimes are cumulative updates that add new features but are backwards compatible. Meaning 4.7.1 can run 4.0 (and 2.0) compiled applications, but the reverse may not always be true. A 4.7 compiled application might use new features that are not available in 4.0. The most common version of the runtime in circulation today is 4.7.x which is installed and updated by Windows 10.

Runtime Usage

Runtime version selection in wwDotnetBridge is determined by two things in order of precedence:

.NET Config file
If the application has a .config file that file can specify an explicit version of the .NET Runtime to use for all components. Regardless of which version you explicitly specify that setting overrides which version is loaded. The config version also determines the debuggable version of the runtime using the Visual Studio debugger.

<configuration>
 <startup>   
    <supportedRuntime version="v4.0.30319"/>
    <!-- supportedRuntime version="v2.0.50727"/ --->    
  </startup>
  <runtime>
      <loadFromRemoteSources enabled="true"/>
  </runtime>
</configuration>

wwDotnetBridge Version Designator
You can specify the .NET Version to use with wwDotnetBridge when you first load wwDotnetBridge using either InitializeDotnet() in your application's startup code, or via GetwwDotnetBridge() or CREATEOBJECT("wwDotnetBridge"). This setting may be ignored if the runtime is specified in the .config file.

For any new application that you build you should target .NET 4 ("V4"). There is no longer any reason to target .NET 2.0 since the most widely used version of .NET now is 4.7.

.NET 2.0 should only be used in special cases where running on XP and Vista where you know .NET 4.0 is not available. XP and Vista do not support versions newer than .NET 4.0 (no support for 4.5+).

Checking actual version used

You can always check the actual runtime that wwDotNetBridge has loaded with:

LOCAL loBridge as wwDotNetBridge
loBridge =GetwwDotnetBridge()  && cached version
? loBridge.GetDotnetversion()

to explicitly force the runtime version.

We recommend that you match the runtime you're trying to load in the .config file and the runtime version in the CreateObject call to match as there can be odd combinations that might produce unpredictable results.

We recommend you always:

Create a .config file for your EXE and set the SupportedRuntime
Specify the Runtime version you want to use in CREATEOBJECT("wwDotnetBridge","V4")

Note that .config files must be created for top level .EXE files:

YourApp.exe.config (Your compiled app)
VFP9.exe.config (VFP IDE Development)

Forcing your Application to use a Specific .NET Runtime Version

Only one version of the .NET runtime can run inside of a host process like your Application or the VFP IDE. So the first load of wwDotnetBridge will determine the runtime that gets loaded.

So, in order to force your entire application to run a specific version of the .NET runtime, you can explicitly create an instance of wwDotnetBridge on application startup and discard it - just to force the proper runtime you want your application to use to initially load.

For example, doing this:

loBridge = InitializeDotnet("V2")
loBridge = null

in your application's startup code forces the .NET 2.0 runtime to be loaded. Any subsequent loads now always use .NET 2.0 regardless of what you set the second parameter to.

GetwwDotnetBridge(): Cached loads

You can also use the GetwwDotnetBridge() function, which tries to automatically load the highest version of .NET installed on your system. Since .NET is backwards compatible, this should typically be able to run any code you might want to access even if it was originally compiled for a lower version of .NET. So a .NET 2.0 assembly generally runs perfectly fine on .NET 4.5 for example.

We recommend you always use .NET 4 if at all possible because going forward .NET 4 will be available on systems from Windows 7 forward. .NET 2.0 no longer ships by default with newer Windows versions.

For more detailed information on how wwDotnetBridge loads the .NET Runtime and various ways you can control the initial loading please check out this blog post:

wwDotnetBridge and .NET Versions