Using .Net Framework 1.1 & 2 in the same assembly.
Let's assume that you have a control developed by VS2003 (.Net Framework 1.1) and you want to use it in a VS2005 project (.Net Framework 2.0 beta 2). What would happen (the default behavior) is that control would be executed by .Net Framework 2.0 along the other controls.
Now the question is how to redirect the execution of that control to .Net Framework 1.1?Bijan
[501 byte] By [
Bijan] at [2008-2-4]
We do this alot with the Managed direct Lib's. I think that becuase you referance the files in the project to a specific version it would use the runtime that the assemble was developed in.
if this is wrong can someone please correct me, as I am thinking that as I am developing applications in v2 that use the MDX libs that have been compiled in 1.1. I would have to make sure that the client has both frameworks installed.
Is there a specific reason why you'd want for the older control to execute on the 1.1 framework?
For 99% of code, 1.1 binaries should work on the 2.0 runtime without modification.
Most of the times that code breaks on 2.0 it's because developers relied on certain internal properties/behaviors (like the implementation of String.GetHashCode()) that changed. Microsoft has always noted that developers should not rely on the specific implementation of such functions.
--Oren
Bijan wrote: |
| Let's assume that you have a control developed by VS2003 (.Net Framework 1.1) and you want to use it in a VS2005 project (.Net Framework 2.0 beta 2). What would happen (the default behavior) is that control would be executed by .Net Framework 2.0 along the other controls. Now the question is how to redirect the execution of that control to .Net Framework 1.1?Bijan |
|
Bijan,
Assuming that the signatures of the types that you were calling in the framework libraries are the same (which they should be, for the most part), the libraries that are part of the framework will be the .NET framework libraries for THAT version of the framework. So, in your case, if you ran your .NET 1.1-compiled assembly in the context of the .NET 2.0 CLR, then the framework assemblies run (like System.Windows.Forms.dll) would be the 2.0 version. Any references to other assemblies outside of the framework would be for the version they were compiled against (if it is a GAC assembly, otherwise it is private, and the point is moot).
You can change this through the config file, but you really don't want to do that, as you would probably have a good number of side effects.
Hope this helps.
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
Actually the problem is with the changes that Microsoft has made in .NET Framework 2.0. To be more specific, let's say I have got some components from National Instruments (called "Measurement Studio") which basically are bunch of graphical components and they have compiled with .NET Framework 1.1 and work fine with VS2003. Now if you want to use them in VS2005 you will get an exception in the constructor of those components (inside of “System.ComponentModel.LicenseManager.Validate(Type type, Object instance)”). Why does it happen? Simply because of some changes inside LicenseManager of .NET Framework 2.0.
Now I guess if there is a way to execute those components by .NET Framework 1.1, it would solve the problem although I’m not sure, because when you create an object of a specified class/ component/control it would reside on the managed heap of .NET Framework 2.0 and probably it can not be controlled by .NET Framework 1.1 in any way.
Regarding the side by side execution, I should say (as far as I understood), it is about having two versions of .NET Framework in the same machine not in the same application/process. Also there some elements in the config files for specifying for the run time engine (1.0, 1.1 and 2.0) but I could not find anything to define that I want to run this assembly by .NET Framework 2.0 and the other one by .NET Framework 1.1 in one application.
Regards,
Bijan
Exception detail:
System.Security.Cryptography.CryptographicException was unhandled
Message="Length of the data to decrypt is invalid."
Source="mscorlib"
StackTrace:
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.Stream.System.IDisposable.Dispose()
at NationalInstruments.Restricted.LicenserHelper.Decrypt(String cypherText)
at NationalInstruments.Restricted.LicenseBase.a(String )
at NationalInstruments.Restricted.LicenseBase.RunTimeCheck(LicenseContext context, Type type)
at NationalInstruments.Restricted.LicenseProviderBase.GetLicense(LicenseContext context, Type type, Object instance, Boolean allowExceptions)
at System.ComponentModel.LicenseManager.ValidateInternalRecursive(LicenseContext context, Type type, Object instance, Boolean allowExceptions, License& license, String& licenseKey)
at System.ComponentModel.LicenseManager.ValidateInternal(Type type, Object instance, Boolean allowExceptions, License& license)
at System.ComponentModel.LicenseManager.Validate(Type type, Object instance)
at NationalInstruments.UI.WindowsForms.NumericEdit..ctor()
at WindowsApplication2.Form1.InitializeComponent() in I:\temp\WindowsApplication2\WindowsApplication2\Form1.Designer.cs:line 40
at WindowsApplication2.Form1..ctor() in I:\temp\WindowsApplication2\WindowsApplication2\Form1.cs:line 15
at WindowsApplication2.Program.Main() in I:\temp\WindowsApplication2\WindowsApplication2\Program.cs:line 16
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Bijan wrote: |
| Actually the problem is with the changes that Microsoft has made in .NET Framework 2.0. To be more specific, let's say I have got some components from National Instruments (called "Measurement Studio") which basically are bunch of graphical components and they have compiled with .NET Framework 1.1 and work fine with VS2003. Now if you want to use them in VS2005 you will get an exception in the constructor of those components (inside of “System.ComponentModel.LicenseManager.Validate(Type type, Object instance)”). Why does it happen? Simply because of some changes inside LicenseManager of .NET Framework 2.0. Now I guess if there is a way to execute those components by .NET Framework 1.1, it would solve the problem although I’m not sure, because when you create an object of a specified class/ component/control it would reside on the managed heap of .NET Framework 2.0 and probably it can not be controlled by .NET Framework 1.1 in any way. Regarding the side by side execution, I should say (as far as I understood), it is about having two versions of .NET Framework in the same machine not in the same application/process. Also there some elements in the config files for specifying for the run time engine (1.0, 1.1 and 2.0) but I could not find anything to define that I want to run this assembly by .NET Framework 2.0 and the other one by .NET Framework 1.1 in one application. Regards, Bijan Exception detail: System.Security.Cryptography.CryptographicException was unhandled Message="Length of the data to decrypt is invalid." Source="mscorlib" StackTrace: at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount) at System.Security.Cryptography.CryptoStream.FlushFinalBlock() at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing) at System.IO.Stream.Close() at System.IO.Stream.System.IDisposable.Dispose() at NationalInstruments.Restricted.LicenserHelper.Decrypt(String cypherText) at NationalInstruments.Restricted.LicenseBase.a(String ) at NationalInstruments.Restricted.LicenseBase.RunTimeCheck(LicenseContext context, Type type) at NationalInstruments.Restricted.LicenseProviderBase.GetLicense(LicenseContext context, Type type, Object instance, Boolean allowExceptions) at System.ComponentModel.LicenseManager.ValidateInternalRecursive(LicenseContext context, Type type, Object instance, Boolean allowExceptions, License& license, String& licenseKey) at System.ComponentModel.LicenseManager.ValidateInternal(Type type, Object instance, Boolean allowExceptions, License& license) at System.ComponentModel.LicenseManager.Validate(Type type, Object instance) at NationalInstruments.UI.WindowsForms.NumericEdit..ctor() at WindowsApplication2.Form1.InitializeComponent() in I:\temp\WindowsApplication2\WindowsApplication2\Form1.Designer.cs:line 40 at WindowsApplication2.Form1..ctor() in I:\temp\WindowsApplication2\WindowsApplication2\Form1.cs:line 15 at WindowsApplication2.Program.Main() in I:\temp\WindowsApplication2\WindowsApplication2\Program.cs:line 16 at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() |
|
Bijan,
The best solution here is to get the updated version of the component for .NET 2.0. From what you have seen, changes in the framework have caused it to break. While you could specify a different version of the framework assembly be used (through the use of the <bindingRedirect> element in the config file), I would strongly advise against this. The reason for this is that you would probably break a lot more than you would fix, as other framework libraries would depend on the new functionality that is exposed.
Also, you have the option of not using the component, or specifying in the config file for your app that you use the .NET 1.1 version of the runtime (so it won't break).
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
The reason behind this is that there can be only one version of the CLR in a Windows process. Since you've created a VS 2005 project, that will load v2.0 of the CLR (since v1.1 won't understand how to read the v2.0 assemblies). Once that version has been loaded, there is no way to get a second version into the process.
-Shawn