Why I think some people shouldn't use VSNET 2003.

23 Comments

• Then please help me in this situation, since I can't think of any real solution. How am I going to FORCE versioning onto developers using visual studio.net 2002? I can only tell them to use the assemblyBinding tags in their own config files otherwise it WILL NOT WORK.
  
  
  
  
  
  If this visualstudio.net 2002 user is not developing an executable but also a library (based on your library), he TOO has to tell HIS customers to include the assemblyBinding tags otherwise the code will NOT WORK.
  
  
  
  
  
  All versioning is focussed on UPWARDS compatibility. However no-one is talking about .NET 1.1 assemblies which are used in .NET 1.0 environments.
  

• *dang* wrong quote :)
  
  
  [quote]
  
  
  Adopter:
  
  
  
  
  
  This works both ways. If you’ve built a v1.1 component, there’s nothing to prevent a developer from referencing it from a v1.0 application. In this case, your v1.1 component finds itself running on the v1.0 Framework. This situation is more dangerous than the reverse, as there’s the potential that your component uses something that doesn’t even exist in v1.0. If this is the case, expect a “missing method” exception.
  
  
  [/quote]
  
  
  I tested this and this is not true (see error listed in the blog). My 1.1 assembly is not run against the .NET 1.0 install on the machine even though the .exe file is compiled on that same machine using csc v1.0.3705.288, thus .NET 1.0.
  

• If you have both frameworks installed, can you compile using the command line in the 1.0 environment?
  

• Yes you can, you can manually compile against whatever framework you want. An ISV can opt for that route as well, however this can be cumbersome also when the set of assemblies have dependencies etc so you have to write NAnt files to build manually. It's not an easy situation, and I think not a lot of ISV's have thought about this, I for one hadn't until I tested it this morning and discovered I made a mistake upgrading to VS.NET 2003, even if the editor is much better and very helpful.
  

• In VS.NET 2003 IDE, you can choose which framework to compile against.
  
  
  
  
  
  Project Properties -> Build -> Supported Runtimes -> Change
  
  
  

• [quote]
  
  
  In VS.NET 2003 IDE, you can choose which framework to compile against.
  
  
  
  
  
  Project Properties -> Build -> Supported Runtimes -> Change
  
  
  [/quote]
  
  
  Only for .exe projects, and also this adds assemblyBinding tags to the .config file of the .exe project. You can't set this information on f.e. C# class library projects. VS.NET is also not compiling with .NET 1.0 if you select it in that dialog, it will compile using .NET 1.1, it will only change your app.config file so the compiled .exe uses .NET 1.0 because all referenced system assemblies are redirected to .NET 1.0 versions. This works ok.
  
  
  
  
  
  THomas: thanks, can be a life saver in supporting multi-platform applications.
  

• again, I'm missing something here. .NET 1.0 is to DirectX 8.0 as .NET 1.1 is to DirectX 9.0. Get the drift? Just make the change and people will follow and soon enough no one will care about .NET 1.0, as they will all WANT to have 1.1 installed and running (and this includes those developers 'stuck' in VS.NET 2002 land)...
  

• Oh yeah, great selling argument: "You can use this software only with visual studio.net 2003. If you have still visual studio.net 2002, please upgrade.". :) I don't think that's gonna work.
  

• Frans: What about using a third-party IDE, such as SharpDevelop or C# Builder, to compile your release build?
  

• This is horendous advice. .NET fully supports Sxs versioning and assemblies. You need to figure out how to use it properly. See the Early & Adopter article, read about publisher policy files, etc but *don't* write riduclous stuff like "ISV'sL do NOT upgrate to Visual Studio .NET 2003!" Not only does it look bad for you but it looks bad for this site (of which many .NET people have been pointing out how much totally incorrect and bad advice is given out daily).
  

• You can’t **compile** against either framework version, but that you can use the <supportedRuntime> and/or <bindingRedirect> elements to run in either environment, assuming you don’t have dependencies. When we say compile against X, what we are really saying is that the compiler stamps the X version in the assembly metadata for the referenced version, which is the one the CLR tries to load unless redirected in the config files. Any code compiled in 2003 will target by default 1.1, but can be redirected using the configuration files. If you want to redirect to 1.1 from 1.0, you use the <supportedRuntime> element. And, if you want to go from 1.1 to 1.0, you use a slew of <bindingRedirect> elements. All of the VS.NET 2003 UI (C# and VB) to target runtimes creates the config files, but still stamps 1.1 versions in the assembly metadata. So, if you want to target 1.0 with code you wrote in 1.1, just add a section to the app config file. If you're an ISV, you probably have a setup process. Why can't you write this into your setup? Seems to be no big deal to me. What other software platform let's you upgrade without recompiling in a cleaner way?
  

• Sam: the early & adopter article is not mentioning class libraries. If you are selling class libraries, you are falling into this pitfall. It is NOT ridiculus advice, since I *AM* now in this situation and I *CANT* fix it, unless I go back to visual studio.net 2002 or compile the sourcecode by hand for 1.0, or supply the assemblyBinding tags and *HOPE* my customers are going to include it in their config files.
  
  
  
  
  
  Do you know a solution then? I don't. You can say "It's horendous advice", but what are my options? I'm delivering a set of class assemblies to customers, who can (and probably will) use Visual Studio.NET 2002. I *CANT* compile these with .NET 1.1 because these will give them serious errors, unless they include the assemblyBinding tags in their config files. I've tested this today. I lost a complete day to test what I can do, and didn't find a solution. Therefor I posted this article.
  
  
  
  
  
  If people are OFFENDED by this, I'm sorry, but it's the clear hard reality for SOME ISV's.
  
  
  
  
  
  I also do not see why it would look bad for me. I warn other people to think twice before they move to vs.net 2003.
  
  
  
  
  
  So Sam, as an invitation, please offer me a solution so I can fix this properly. I don't see one. Requiring customers to buy visual studio.NET 2003 is ridiculus in itself, and I can't do much more. A customer with solely visual studio.net 2002 is not focussed to include redirects for .net 1.0, because he never had to. *THATS* the issue. Who is paying the bill for all the supporthours my people have to give customers because they can't run the code they bought? Should I do something to my code to make this easier? If I can, please tell me. I don't know what.
  

• when I said "this site", I meant "dotnetweblogs as exhibited by the main feed" fyi
  

• Stephen: if I was selling solely a .exe, it wouldn't have been a problem. The problem is with the class libraries. I can't supply them with a .config file (I wish I could).
  
  
  
  
  
  It would have been really great if a class library compiled with vs.net 2003 and run by an application build with .net 1.0 would immediately use .net 1.0 assemblies. That would solve the problem. However this is NOT the case. Of course a customer can add the assemblyBinding tags, it's the solution that worked, however a customer has to add them. I didn't KNOW that. It's not mentioned anywhere that you have to add these tags to a .net 1.0 (!) application's .config file to make its class libraries (which are probably compiled with 1.1) use .NET 1.0 assemblies.
  
  
  
  
  
  Because this is extra support trouble, extra trouble in codebases, it's wiser to keep the code in vs.net 2002, because this will keep you out of the trouble. I predict this issue will cause trouble for some ISV's. Now everyone is selling 1.0 versions, but this will change.
  

• I am not going to do this with you. While I appreciate your fustration, bloggers here need to learn *not* to make grand denouncements of something. You didn't say "some". You said "ISVS: do NOT upgrade." So all ISVs should not upgrade? Surely *most* ISVs are not exhibiting this problem. Having a blog that is public conveys a responsibility for being accurate as well as posting content free of rants or grand pro/denoucnements. You get the lecture today because there is just so much of this going on in general on this site, and prominent .NET people and bloggers are starting to complain. 'Nuff Said.
  

• Last post from me on this. Apparently, you still don't get the difference on "some" versus "all" and "giving good advice" versus saysing "ISVS: Do NOT." Do I have to spell this out any more clearer? I checked every word of what I wrote with Scott, and spoke to him and he was fine with it. Complaints is refering to not just *this* site but the high number of incorrect .NET information that shows up on the *dotnetweblogs main* feed from a number of blogs on dotnetwegblogs. Scott and I recieve complaints on it. I gave you good advice on how you could have blogged it and how to make a blog successful. You chose to ignore everything I wrote. It's your choice. This is all I am going to say on this.
  

• I have been stuck having to compile my NUnitAddin project with VS.NET 2002 to ensure compatablilty with both. Yes I might be able to add redirects to devenv.exe.config but I don't think users would be very impressed. I have heard it is possible to compile against the 1.0 assemblies in VS.NET 2003. It would just take a while to manually change them all. I've just written a snippit of code to change all assemblies in a solution to be the 1.0 versions. If you've got NUnitAddin installed you can use 'Test With... VS.NET' on the following method. Put this code in the solution you wish to convert...
  
  
  
  
  
  using System;
  
  
  using System.IO;
  
  
  using System.Reflection;
  
  
  using System.Diagnostics;
  
  
  using EnvDTE;
  
  
  using Microsoft.Office.Core;
  
  
  using VSLangProj;
  
  
  
  
  
  public class SolutionConvert
  
  
  {
  
  
  public static _DTE DTE
  
  
  {
  
  
  get { return (_DTE)AppDomain.CurrentDomain.GetData("DTE"); }
  
  
  }
  
  
  
  
  
  public void BuildWith_v1_0_3705()
  
  
  {
  
  
  foreach(Project project in DTE.Solution)
  
  
  {
  
  
  VSProject proj = project.Object as VSProject;
  
  
  foreach(Reference reference in proj.References)
  
  
  {
  
  
  string assemblyPath = reference.Path;
  
  
  string assemblyFileName = Path.GetFileName(assemblyPath);
  
  
  string frameworkDirectory = Path.GetDirectoryName(assemblyPath);
  
  
  string frameworkVersion = Path.GetFileName(frameworkDirectory);
  
  
  
  
  
  string newFrameworkVersion = "v1.0.3705";
  
  
  string newFrameworkDirectory = Path.Combine(Path.GetDirectoryName(frameworkDirectory), newFrameworkVersion);
  
  
  string newAssemblyPath = Path.Combine(newFrameworkDirectory, assemblyFileName);
  
  
  
  
  
  if(frameworkVersion != newFrameworkVersion && File.Exists(newAssemblyPath))
  
  
  {
  
  
  Debug.WriteLine(assemblyPath + " -> " + newAssemblyPath);
  
  
  reference.Remove();
  
  
  proj.
  

• .References.Add(newAssemblyPath);
  
  
  }
  
  
  else
  
  
  {
  
  
  Debug.WriteLine(assemblyPath);
  
  
  }
  
  
  }
  
  
  }
  
  
  }
  
  
  }
  
  
  

• First, it's pretty easy to create separate VS 2002 and VS 2003 project files that point at the same source. Then you can work in VS 2003, and do your final build in 2002 (or you can set up a batch/makefile to do a command line compile).
  
  
  
  
  
  Also, if you build an assembly from VS 2003, you can reference that assembly from a VS 2002 application just fine. You do not need binding redirects or policy files in this case. These come into play if you have a strong named component, and you want to replace it with a newer version (and you want everything redirected to the newer one).
  

• Or, you can maintain 2 downloads and EDUCATE your developers on which one to use.....
  

• Scott Swigart: did you try it? Of course you can reference it from vs.net 2002. It even compiles ok. It starts up even, but when you call a method in a class library build with vs.net 2003 from a .NET 1.0 application, AND that class library uses an assembly of .NET to do something (in short: something useful), it will crash with an exception that it can't load the right assembly (the 1.1 version) so your call will not succeed. I tried it, it fails.
  
  
  
  
  
  Robert: maintaining 2 versions is nice, but what if I upgrade my own class library? Then I have to maintain 4 versions. Perhaps even 6 after another upgrade. I'll look into this, it might be the only solution which will not be a burden for my customers, if I implement it right in my generator.
  

• Frans, I think what you are saying essentially true, but only for Component vendors. If someone is writing a general app, then Visual Studio 2003 is preferable. I've posted some more details on my blog.
  

• Mike: that's why I'm talking about libraries :). General app developers are also able to target 1.0 in vs.net 2003 by the .config generator in vs.net 2003 which adds redirect tags in the .config file, for .exe projects. :)