Version 4.0 of the .NET Framework introduced a new runtime activation policy, which enables an application to activate multiple versions of the common language runtime (CLR) in the same process. (See here for more information.)
Because of this support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies, such as the NMath Kernel assembly, which is written in C++\CLI and uses the Intel Math Kernel Library internally.
When using NMath in .NET 4.0 applications, the NMath Kernel fails to load, because it was built against an earlier version of .NET and includes unmanaged code. The error is:
System.TypeInitializationException : The type initializer for 'CenterSpace.NMath.Core.NMathKernel' threw an exception. ----> CenterSpace.NMath.Core.KernelLoadException : Could not load kernel assembly NMathKernelx86
There are two solutions:
- Activate the v2.0 runtime activation policy by adding the following lines to your app.config when using runtime v4.0:
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup> </configuration>See here for more information on the <startup> element.
- Request assemblies for .NET 3.5 from Centerspace Technical Support. (see below for correction)
In the next release of NMath, the shipping assemblies will be built against .NET 3.5. (Assemblies for .NET 2.0 will remain available upon request.) << see below for correction
Ken
Update
This issue can only be solved with the application config change or with assemblies built with .NET 4.0.
If you are widely deploying your application, you should probably target .NET 3.5 or earlier. In this case, the application config is the best solution.
If you know your application will be run within .NET 4.0 or later and don’t wish to make the application config change, please contact us at support@centerspace.net. We can send you NMath assemblies built and tested with .NET 4.0.
Since we don’t use any .NET 3.5 features and it’s too early to target .NET 4.0 with a class library, we will be targeting .NET 2.0 in the next release (expected in June, 2010).
Update #2
We have released new versions of our products today that are built using Visual Studio 2010 and target .NET 3.5 (client profile) or greater. The issue above no longer exists. Please contact sales@centerspace.net for your upgrade.
This is confusing:
“2.Request assemblies for .NET 3.5” in a post about .Net 4?
..do .Net4 assemblies = .Net 3.5 ?
I see what you mean, Joe. Right now, NMath is built using .NET 2.0. This provides maximum flexibility as these assemblies can be run with .NET 2.0, .NET 3.0, .NET 3.5 or .NET 4.0 runtimes. This particular bug can appear with a .NET 2.0 assembly running in a .NET 4.0 runtime. Since NMath is switching to .NET 3.5 compilation in the next release, the problem will go away. Does that make sense?
– Trevor
And yet .Net 3.5 has been out for how long?? And .Net 4.0 to ISVs for how long?? It only becomes a “next release” item now??
As library developers we have to be especially careful not to be in front of our customers or our customers’ customers. Some of our customers are banks, for example, which are very cautious about operating system and framework updates. By following behind the crowd, we maximize the distribution of any applications created using NMath.
But is there a trade-off in performance or usability? Not as much as you would think. Our libraries use Intel’s Math Kernel Library (MKL) for the native execution of low-level math calculations. These run just fine in .NET 2.0, .NET 3.5 and .NET 4.0 (with the above limitation). The performance is comparable. In addition, we ship VS 2005 and VS 2008 solution and project files. (We use VS 2008 or 2010 inside CenterSpace).
Having said that, it is time to switch to .NET 3.5. We look forward to exploring the capabilities of parallel extensions, for example.
For those customers with conservative IT policies, we will continue to sell and support our .NET 2.0-built libraries for the time-being.
– Trevor
Trevor – understand your reasoning, however, I have the following question.
We are upgrading our project to .NET 4.
The only external component that we use that isn’t built against 4.0 is nmath core and stats.
Our product is a “shrink-wrap” download and install application – where we minimise the downloadable installation filesize but need to put all pre-requisite installs such as .net framework runtime in the setup so that non-IT Joe can install with ease. Hence – when we ship our upgraded product, we will be just containing .NET 4 runtime redistributable and the binaries required for our application.
To contain anything more, would cause issues with various countries with slow internet pipes.
Up until this point we have remained at .NET 2.0, because the runtime distributables for .net 3.5 sp1 was 231 MB in size. However – .NET 4 redistributable dotNetFx40_Client_x86_x64.exe is 41 Mb (because Microsoft finally realised a 231 MB download was sometimes crazy) – to achieve this – it doesn’t contain the old runtimes (or support them).
End result = end-user is not guaranteed to have the .NET 2.0 installed on their machine.
Are either of the two solutions you provided above going to work for our scenario? (i.e. when neither 2.0 or 3.5 frameworks are installed?)
Cheers,
Gerard.
Gerard – The app.config will work for you.
– Trevor