Gerard – The app.config will work for you.

– Trevor

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.

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

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