Software Geek

Also see: My fair and biased opinion on the recent upgrade…

I typically recommend that you build and test your assemblies against the same version of.NET that you will be running them against. That way, you’ll have correct references and avoid surprises from behavior differences between builds.

Older assembly, newer.NET

But, sometimes you don’t run against the same version that you built against. For example, the latest available CLR is the default when interop causes it to be loaded. Or, if the version of the CLR the assembly was built against is not available, the latest version can also be used instead. If there is a compatibility problem with that for your application, you can force the use of a preferred CLR version by using an app.config.

Compatibility

Yes, there are going to be behavior differences between versions - no way around it. It is the.NET team’s goal to be as backwards-compatible as realistically possible between versions. But, some changes are required - new features are added which sometimes require (hopefully minimal) behavior changes in other features. If we were required to never break any app, ever, we wouldn’t be able to fix any bugs or add any features for fear that someone, somewhere relied on the broken behavior in some strange way. As Dll Hell has shown in the past, new versions of components aren’t really compatible. The only guaranteed 100% compatible version is the same one you tested against.

V2+ assembly, older.NET

Say you see a BadImageFormatException for hresult 0x80131107 (CLDB_E_FILE_OLDVER) with message “Version […] is not a compatible version.” That means that you’ve tried to load an assembly built against a newer version of the CLR than was running.

Also see: Be my Support Group

Also see: Scott Guthrie presents at NDDNUG

Also see: Using Silverlight 2 on a production Web Server

Also see: Big in Japan

Also see: Presentations…

Also see: Playing Multiple Simultaneous Sounds in WPF

Also see: Snippet Compiler update

Also see: Turning bitboards from potential moves into legal moves, pawn moves, and conditional rules.

Also see: A first stab at BaseN encoding with a focus on general alphabet encoding.

Also see: Mix08 Session Overview: Building Great AJAX Applications from Scratch Using ASP.NET 3.5 and Visual Studio 2008

Also see: Java Concurrency, another series on its issues

Also see: Tagspace, Meet Claimspace

Also see: Blogging and Newspapers, a Lesson in How Not to Brand and Market

Also see: Presentations…

Also see: Aggregators rock!

Also see: Web Access for Visual Studio Team System

Also see: Be my Support Group

Also see: From C# to Java: Part 3

Also see: Startup, Shutdown and related matters

Also see: From C# to Java: Part 3

Also see: Microformats are like RFID tags for the Web

Also see: Updated Finalization and Hosting

Also see: Merry Christmas Indeed!

Also see: Scott Guthrie presents at NDDNUG

Also see: Web Services with Spring 2.5 and Apache CXF

Also see: Using Silverlight 2 on a production Web Server

Also see: Hello world!

This fails because new files can’t be opened on an older CLR that does not understand them. You will need to either use the v2 CLR to load the v2/v1 assemblies, or load only v1 assemblies on the v1 CLR. That’s just good practice, anyway. If you try to use an older.NET than you built against, a method you built against may not exist, etc.