New Assembly, Old .NET (and Vice-Versa)

re: New Assembly, Old .NET (and Vice-Versa)

Sam — Thu, 27 Jan 2005 06:01:00 GMT

Interesting post.

You mention it is a goal of the .NET team to maintain backwards compatibility as much as possible.

I cant help wondering why this is important?

"new versions of components aren't REALLY compatible"

If there is a risk, however small, that a companies application may not perform correctly when run against a later version of the framework then they are very likely to bundle an installer for the appropriate version of the runtime with their product and provide an app.config file.

Correct me if I’m wrong, but doesn't that mean there is little requirement for backwards compatibility with regard to execution of assemblies compiled against previous versions?

And then what about source code compatibility?

A situation would arise if a company decided to switch to a later version of .NET during development. In that case, the developers would be forced to modify their source code since it would not compile against the more recent framework "out of the box".

Personally, I would be perfectly happy to modify my code if it meant I could take advantage of a more powerful framework which was still as coherent as, or possibly more coherent than v1.0 with regard to content.

Or am I missing an important point here?

re: New Assembly, Old .NET (and Vice-Versa)

Paul Gunn — Thu, 27 Jan 2005 15:48:00 GMT

You mentioned the issue with interop loading the newest framework version.. This has been pretty problematic for me recently.

I have been on an installation project where we are writing custom action dlls in managed c++. The dll entry points have the same behavior as interop (picking the newest framework version) and this bit us as a result of some changes 2.0 made regarding how xmlserialization plays with assembly loading.

We found a workaround that works with both framework versions, but compatibility is still a concern. Obviously in this case we can't use a app.config file - since the app in question is msiexec.exe (the microsoft installation program).

Has there been any thought to having the framework version used in interop be based on the assembly being loaded for interop? I would imagine it quite common that the component writer may not have control over the originating Exe, nor should the consumer of the component really need to care what framework the component wants.

re: New Assembly, Old .NET (and Vice-Versa)

Suzanne — Thu, 27 Jan 2005 19:59:00 GMT

Sam: It's not that simple. For instance, there are cases where components built against different .NET versions need to run against the same .NET. The components may be add-ins, where the host has the option to choose the .NET version, but the individual add-ins would not. If there was a v1 add-in and a v2 add-in in the same process, running the v2 .NET, then we'd hope that the v2 .NET is backwards-compatible, or else the v1 add-in would be broken.

Regarding source code backwards-compatibility: yes, we do take steps to make that just work as well. But, again, there are times when it's not realistic to try to make it perfectly compatible. And, yes, it's not as breaking as a binary compatibility breaking change, as developers can update their sources when they recompile...unless they recompile at runtime.

re: New Assembly, Old .NET (and Vice-Versa)

Suzanne — Thu, 27 Jan 2005 20:21:00 GMT

Paul: Consider the add-in case from my last comment. With your suggestion, if the v1 add-in is loaded first, causing the v1 .NET to be loaded, then the v2 add-in is broken. The feature it requires may not exist in v1. Even if you somehow force the v2 add-in to be loaded first (which may not be an option for many apps, since they may not even know about the v2 add-in yet), then the v1 add-in still needs to deal with the v2 .NET.

That's why interop has chosen to just load the latest available .NET up front, and then that can be overridden by app.config. But, we do take compatibility problems seriously. If you run into them, especially with a beta, please give feedback in the appropriate beta forum. We do listen and try to take appropriate steps. (But, please don't email us directly. http://blogs.msdn.com/suzcook/archive/2003/12/05/57253.aspx )

re: New Assembly, Old .NET (and Vice-Versa)

Mark A. Richman — Tue, 19 Apr 2005 02:15:13 GMT

One oddity I noticed in playing with VS05b2 this weekend was the GAC behavior. I removed an older copy of the CTP, but it left some assemblies in the GAC. For example, Microsoft.VisualStudio.TextManager.Interop.8.0. VS05b2 installed the same assembly, same version (8.0.0.0), same public key token, same culture. The only difference was the timestamp of the assembly. I thought the GAC was supposed to protect against junk like that. What am I missing?

Thanks,
Mark

re: New Assembly, Old .NET (and Vice-Versa)

diegov — Mon, 01 Aug 2005 11:10:01 GMT

I don't know what is wrong, but I have seen related oddities, and I think it is worst than dll hell.
Even if I uninstall the 1.1 component of the GAC and add the 2.0 version, many times, with crossed fingers, at different times of the day, and with recompilation, I don't get to debug it anymore. Now I remmember mama said "avoid the GAC"... or was it Chris Sells?

WinFX SDK .NET Framework Version Incompatible with July CTP Version

Sam Gentile's Blog — Sat, 13 Aug 2005 16:44:46 GMT

re: New Assembly, Old .NET (and Vice-Versa)

VinceB — Fri, 28 Oct 2005 07:37:42 GMT

It all makes sense but what bothers me is the rather cryptic message. "Version [...] is not a compatible version." Tell me there is more for the user if we just return the error message for users. It's better than some. How about a little runtime help such as "This is most likely due to...for more information, refer to http://....".

Thanks for taking the time to mention the issue.

-VinceB

re: New Assembly, Old .NET (and Vice-Versa)

Mark Heaton — Mon, 06 Mar 2006 14:45:50 GMT

I have just run into the dreaded CLDB_E_FILE_OLDVER error message.

It would make life so much easier if we could use tools such as tlbimp to target a specific version of the framework.

As someone being kind and distributing my COM object with a .NET assembly I gain little advantage in forcing my users to upgrade to .NET 2.0 (Significantly larger code base, more testing etc. if they haven't already got it) when I don't require the framework for my core application which is written in C++.

I can just as simply target 1.1 and rely on the 2.0 framwork to work with my v1.1 targeted assembly.

re: New Assembly, Old .NET (and Vice-Versa)

Sriram — Thu, 09 Mar 2006 19:06:23 GMT

Is there a way for me to know which CLR was used to load a DLL while in Debug mode?

My scenario is 2.0 exe calls an 1.1 dll. I am sure that when the DLL is loaded, 1.1 CLR is loaded, but just wanted to confirm the same in debug mode by setting a break point in the DLL. Any way I can achieve it?

CLR 1.1 / CLR 2.0 Interoperability

Colin Neller — Tue, 14 Mar 2006 00:25:03 GMT

re: New Assembly, Old .NET (and Vice-Versa)

Marcus Arraya — Thu, 04 May 2006 19:11:30 GMT

I am trying to debug into a v1.1 assembly from VB6 and it was working fine before I installed framework v2.0 side-by-side v1.1. I cannot now attach to the VB6 process and have tried creating app.config files for the assemblies but still to no avail, I am using:

<startup>
<supportedRuntime version="v1.1.4322" />
</startup>

in the config file. The only way that it appears that I can go back to cross debugging in VB6 is to uninstall FW 2.0 - any ideas ?

Regards Marcus

re: New Assembly, Old .NET (and Vice-Versa)

Anders G — Mon, 29 May 2006 15:29:56 GMT

Marcus

I have the same problem. I suppose you build Class Libraries like we do, to be used from VB6.

Try to add
<startup>
<requiredRuntime version="v1.1.4322" />
</startup>
to your config file.

I worked for me, the problem is that we run the COM dlls in COM+, so I have to create a dllhost.exe.config file...

BR
Anders G

re: New Assembly, Old .NET (and Vice-Versa)

Clinton — Tue, 13 Jun 2006 19:34:01 GMT

This might seem a silly question but here i go.
i am having a problem with serialization between client in version 1.1 and server in version 2.0 Is it possible to tell the clr to use a specific assembly in clr version 1.1 (i.e. on the server side it should clr 1.1 for a particular assembly)

I have tried to startup tags to perform this operation but i receive a BadImageFormatException.

Colin Neller - CLR 1.1 / CLR 2.0 Interoperability

Colin Neller - CLR 1.1 / CLR 2.0 Interoperability — Mon, 11 Dec 2006 17:40:53 GMT

PingBack from http://www.colinneller.com/blog/CLR11CLR20Interoperability.aspx

re: New Assembly, Old .NET (and Vice-Versa)

Asif — Tue, 11 Aug 2009 07:07:55 GMT

Is the number of .net runtime enviornment=number of .net applications currently running?