Calling .NET 2.0 assemblies in .NET 1.1

views:

430

answers:

+2 Q:

Calling .NET 2.0 assemblies in .NET 1.1

Recently I developed a internal framework in .NET 2.0 version, which is basically classes and helpers.

The problem is I have some .NET 1.1 sites and applications and would like to use my framework from them. I know that I can't call .NET 2.0 in .NET 1.1, but I have an idea.

If I create another 2.0 project with ComVisible and reference some of my 2.0 assemblies, then recreate my needed functions only referencing these classes, and in .NET 1.1 call this new ComVisible assembly; could I then use 2.0 assemblies in .NET 1.1?

If this works basically I can use it in .NET 1.1, Java Reflection, etc.

Or am I wasting my time?

+1 A:

I don't see why you'd want to go through all of this effort. There are only two possibilities - either:

The servers/workstations running those sites/applications have the .NET Framework 2.0 installed, in which case you might as well just re-target those sites/applications to .NET 2.0 and rebuild/redeploy them (which should take all of 10 minutes), or
The servers/workstations do not have the .NET Framework 2.0 installed, in which case all your COM effort is for naught because the 2.0 assemblies themselves won't be able to run without the Framework.

I recently re-targeted a whole bunch of "legacy" 2.0 apps to 3.5 as in #1 without a single problem. I know that there were a tiny handful of breaking changes from 1.1 to 2.0, but they are so few in number that it would almost certainly take less time to search for those than it would take to deal with all that COM craziness.

Aaronaught 2010-01-07 21:03:11

But 3.5 is a extenion of 2.0, don't have any problems in migration. From 1.1 to 2.0 very functions is deprecated or dsignatures changed. And 2.0 is not "legacy" is major release.

pho3nix 2010-01-08 16:42:05

I don't quite understand your comment. .NET 3.5 is a new Framework version, different compiler and everything, it is not an extension of 2.0 any more so than 2.0 is an extension of 1.1. Some 1.1 features were deprecated in 2.0, but that does not prevent you from using them in the interim, and method signatures were definitely preserved. As far as the "legacy" comment goes, given that .NET 4.0 is almost final, I think it's safe to say that 2.0 is "legacy"; 1.1 is "ancient."

Aaronaught 2010-01-08 17:26:32

@Aaronaught: Actually .NET 2.0 is a major release of the framework, with a different CLR than .NET 1.1, so it's practically a different framework with some API changes from 1.1 (and 1.0 obviously). On the other hand, .NET 3.0 and 3.5 are just a new set of assemblies (and compiler) that use the same CLR than .NET 2.0.Check out: http://stackoverflow.com/questions/212896/how-do-the-net-framework-clr-and-visual-studio-version-numbers-relate-to-each-o

alexphi 2010-01-08 18:35:26

Fair enough, but technically 1.0 and 1.1 were different CLR versions too, and that was classified as a point release. My point was that it's extremely unlikely for a 2.0 re-target to break anything; at the very least, why not try it and see? If it doesn't compile, then just roll back.

Aaronaught 2010-01-08 19:28:43

@Aaronaught: Retargeting (i.e. recompiling ) for 2.0 is certainly possible, but there are more than a few breaking changes from 1.1 => 2.0 (see http://msdn.microsoft.com/en-us/netframework/aa570326.aspx), some of which can be rather nasty (might only be detected at runtime). Upgrading is certainly the right thing to do, but some time must be taken to investigate whether any of the issues affect your code.

jeroenh 2010-01-08 22:31:26

ansaurus

tags:

views:

answers:

Calling .NET 2.0 assemblies in .NET 1.1

related questions