I was trying out something and was desperate to get it working because i thought it could open up a whole new possibility of ways to work on Framework 1.2 without Whidbey but still with a great IDE ( not Notepad or Textpad ;) )! What else would the IDE be other than VS.NET ! But what i found out after trying this experiment was rather very interesting and frustrating. First check out this entry that talks about Testing compatibility for Whidbey/Everett and talks about the lack of forward compatibility.
Someone sent a question recently to an internal alias so I thought I would share. The question was what will happen when a C# V1 component consumes a C# V2 component that exposes a generic class. First some background information, there are two types of compatibility, backward compatibility and forward compatibility.
- Backward compatibility refers to a future version of a product, like Whidbey, supporting already existing functionality like something found in .
- Forward compatibility refers to an older product, like Everett, being able to support a new feature like generics.
As you can imagine, it's easier to add backward compatibility since it is a known thing. Designing for forward compatibility can be more difficult as it is an unknown thing. The goal of C# Whidbey is geared more towards backward compatibility so that if you write a component today for version 1.x, your component will "just work" in C# Whidbey.
I decided to test what forward compatibility will work with the current Tech preview for a VS Whidbey component to be used in VS 2003. To test forward compatibility, I created a simple generic class with two static methods. The first method returns a generic collection, the second returns a non-generic collection.
via Dan Fernandez
A pretty informative entry but there are certain loose ends i think.
Now this is what i tried out -> Create a new VS.NET 2003 C# project and then de-reference all the System assemblies pointing to V1.1 and then refer the corresponding V1.2 assemblies. Compile the application. The application will compile without error from inside VS.NET, if all the methods and types that you are using are declared in the V1.2 assemblies ( till now fair enough ! ). Now Run the application. Since it compiled without any errors or even a warning, you would have got excited right now and would expect the beast to run and then show you 'Hello world' ! Aha .. There's the gotcha of the day... Eventhough the application is referencing only V1.2 assemblies, the mscorlib.dll which contains the base definitions are only those corresponding to what VS.NET 2003 uses ( V1.1 ). ahem., is there a way up your sleeves to specify the mscorlib.dll version while compiling ?
Eventhough Dan said that it throws an exception at run-time, he doesn't describe it completely. Here's the deal. It appears as though, the managed version of the framework on which VS.NET was built seems to be the default version for all applications built using that VS.NET IDE. I cannot see any other reasoning behind this one. So what happens is that, when the code loads, there is some runtime fault occurring because of version mismatch and the application fails to run. I reflected upon my compiled application, and the version of the mscorlib.dll alone was old but all the new references were properly set in the metadata of the assembly.
Another interesting fact is that, when i referenced the V1.2 assemblies, the VS.NET shadow copied *all* the assemblies ( System.*.dll ) into the local bin directory. hmm pretty interestingly weird behaviour i would say ;)
Now my only question is that why did you relate or rather link the mscorlib.dll version even before i set my refs and compiled it because that's how it seems to have happened ??! Why is your VS.NET IDE linked so closely with the version of the framework with which it ships ?!?! If it weren't for that simple restriction, today i could have been working with generics on my machine with just the V1.2 Framework installed and then using a single VS.NET IDE ... All the further updates could have happened to that single IDE and my working experience could have become better and better everyday. Unfortunately, that's not how things seem to work :( does it ? I have now ended up with VS.NET 2002, VS.NET 2003 along with framework versions 1.0, 1.1 and 1.2... Should i install Whidbey on top of this to create and try out code in generics, anonymous methods and other cool futuristic stuff ??! Why do you guys do this ? It feels thrilling to realize that the IDE that i work on is a managed product of the framework that i'm programming on; but you could have atleast let the dependencies be loaded independently while compiling applications in the IDE. Why is compilation linked and not made independent of the version of IDE ?!
Is there some other good reason behind all this ( and am i the only one babbling like this ?? ) What will Orcas bring then ?? Do i have to install another version of VS.NET again then ?
What do you think about all this ? Should your IDE be framework version dependent or independent of it so that all updates happen to that single IDE and enhances it further and further.
- Consistent UI experience
- No change in Project and solution files formats
- Addins targeted at a single IDE rather than one for each of the versions ...
- A single update can enable the IDE to work with a newer version of the framework
- Saves a hell of a lot of disk space on the computer ( Definitely a billion times better than having 4-5 versions of VS.NET on computer to work on different version of the framework dont you think ?? )
Well ?!?