Running on version of .NET older than build version

  • Thread starter Thread starter C Card
  • Start date Start date
C

C Card

I am creating a managed DLL in C++ using VS.NET 2005 and .NET 2.0 that
I hope can be used by applications created for older versions of .NET.
I have a feeling this is not possible, and I hope someone can either
confirm it is not possible or perhaps suggest what I might be doing
wrong that prevents it from working.

The DLL works with an application built using VS.NET 2005 under .NET
2.0 (i.e., when the application and DLL were built with the same
environment).

If I try to build a VB.NET application (which uses the DLL) using the
first (circa 2001) VS.NET version and .NET 1.1, the compiler complains
that the DLL has a bad manifest and that the version is unsupported.

If I try to use the DLL in an application previously built using .NET
1.1, BadImageFormatException is raised when the DLL is loaded.

A Microsoft document titled, "How to: Use an Application Configuration
File to Target a .NET Framework Version" states "You can configure an
application to run on the version on which it was created or on a
later version" (version is referring to .NET version). It also states
that "An application created with the .NET Framework version 2.0 can
target only version 2.0." From my experiments, it would seem that
these statements are also true if "DLL" is substituted for
"application."

C. Card
 
Hi C!
A Microsoft document titled, "How to: Use an Application Configuration
File to Target a .NET Framework Version" states "You can configure an
application to run on the version on which it was created or on a
later version" (version is referring to .NET version). It also states
that "An application created with the .NET Framework version 2.0 can
target only version 2.0." From my experiments, it would seem that
these statements are also true if "DLL" is substituted for
"application."
Click to expand...

If would be better to substitute "application" with "assembly".

If you want to develop with VS2005 and want to target .NET 1.1 you can
use MSBee...
http://msdn.microsoft.com/vstudio/downloads/tools/msbee/default.aspx

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Hi C!


If would be better to substitute "application" with "assembly".

If you want to develop with VS2005 and want to target .NET 1.1 you can
use MSBee...
http://msdn.microsoft.com/vstudio/downloads/tools/msbee/default.aspx
Click to expand...

Except that my assembly/DLL is written in C++ (as was stated in my
original post), and C++ projects are not supported by MSBee (from the
MSBee documentation): "Visual Studio 2005 C++ project files have not
been updated for MSBuild. Hence, you cannot import the necessary
MSBee .targets file."

C. Card
 
Hi C,

C Card said:
I am creating a managed DLL in C++ using VS.NET 2005 and .NET 2.0 that
I hope can be used by applications created for older versions of .NET.
Click to expand...
The DLL works with an application built using VS.NET 2005 under .NET
2.0 (i.e., when the application and DLL were built with the same
environment).

If I try to build a VB.NET application (which uses the DLL) using the
first (circa 2001) VS.NET version and .NET 1.1, the compiler complains
that the DLL has a bad manifest and that the version is unsupported.

If I try to use the DLL in an application previously built using .NET
1.1, BadImageFormatException is raised when the DLL is loaded.

A Microsoft document titled, "How to: Use an Application Configuration
File to Target a .NET Framework Version" states "You can configure an
application to run on the version on which it was created or on a
later version" (version is referring to .NET version). It also states
that "An application created with the .NET Framework version 2.0 can
target only version 2.0." From my experiments, it would seem that
these statements are also true if "DLL" is substituted for
"application."
Click to expand...

Configuration files only work with executables, so foo.dll.config will not
be taken into account when it comes to loading a framework version.
Actually that would not make much sense as one process can only load
one framework version. So that decision has to be made when the
executable is loaded. Assemblies loaded after that stage have to use
the framework version which is already loaded.

So the point is that you must be able to control the host application
which uses your managed C++ dll. So try to create a config file
for your .Net 1.1 exe to force it to use .Net 2.0.

Regards,
SvenC
 
Back
Top