Multitargeting and Express

When Visual Studio "Orcas" ships, we have a question we need to answer: which version(s) of the .NET Framework/WinFX should it target? Having a single tool that can target various runtimes has been something I've been a strong advocate of for years, but my experience with the Express products has softened my passion. Why? Because not only is multitargeting (the term we use for enabling developers to choose which version of the runtime the tool targets) very hard to implement (thereby sapping feature teams from work on other features) but it is also something that can be extremely confusing.

Just imagine that you're new to .NET (as nearly 2/3 of Express users are) and you're confronted with a dialog box early on in creating your first project that asks you to select the version of the .NET Framework or WinFX you want to target. For most, the choice would either be the default or "Game Over."

I'm actually advocating that whatever "big" VS chooses to do, that Express only offer the latest version of the runtime to be targeted. That we either forgo entirely with the concept or hide any tool UI for multitargeting. This would help reduce concept count considerably. Of course, if you wanted to dig around in some config files, you could make Express do whatever you wanted, but the UI concept count would be kept low.

Thoughts?

Comments

• Anonymous
  May 09, 2006
  
  
  Now I agree with this. I think that the Express should still present the
  option to revert to older...
• Anonymous
  May 09, 2006
  My opinion is that the "big" VS absolutely needs to be able to target older runtimes. Including 1.1 in this would be fantastic for me.
  
  My use case is that one of my projects is an Excel addin with managed code. There appears to be a set of AppPatch registry keys that prevent Excel 2000 and XP from EVER loading CLR 2.0. (2003 works, after an Office Update.) I can't stop supporting those versions, so I'll be targeting 1.1 for some time.
  
  I agree with you that targeting older runtimes might be confusing. I've seen people be confused by far less. So it makes sense to make it harder to find in Express or leave it out altogether.
• Anonymous
  May 09, 2006
  I'm not sure what the current plan for "big" VS.
• Anonymous
  May 09, 2006
  If I was a beginner would I care which .NET framework to target?
  
  How about targeting the latest version of the .NET Framework by default with the possibility to override the targetted framework in the Project properties or something.
  
  By the way are you thinking about targetting different frameworks project-based or solution-based?
• Anonymous
  May 09, 2006
  This approach (follow "big" VS) is fine, especially if the earlier Express versions are available in case someone wants to target an earlier (down-level) version of .NET.  There is precendent for this approach from other MS products; Media Player comes to mind.
• Anonymous
  May 09, 2006
  I'm not quite sure what you're asking. Let's be concrete here. Are you thinking that you might drop WinForms support from C# Express "Orcas" and only support WPF? Or are you thinking that you might drop .NET 1.0 and 1.1 and 2.0 support and only support 3.0? Or would it be both?
  
  If you think about it, lower concept count for pure first-time users might need to balance against increasing continuity of knowledge (carryover) for beginners with a little bit of previous experience and hobbyists. Carryover shouldn't be a factor for the .NET version question, but it is very much a factor for the WinForm/WPF question.
• Anonymous
  May 09, 2006
  The comment has been removed
• Anonymous
  May 09, 2006
  WinForms should normally be supported till 2015 in theory...
• Anonymous
  May 09, 2006
  I think there is a continuity issue. I'm not sure how it works for the .NET languages (VC#, VB 2005, etc.), but there are continuity nightmares experienced by some users of VC++ 2005 Express Edition.  I can't tell, from the angst that shows up on the MSDN Forum, how prevelant this is, but I wouldn't be surprised that it hangs up many more novices than come to the Forums (considering there are some fraction of the 5 million downloads that are for VC++ EE).
  
  There are some dramatic cases with VC++ EE:
  
  1. The requirement for .NET 2.0 in order to run the managed C++/CLI (or semi-managed?) code trips up a lot of neophytes.  Since one of the big payoffs for accomplishing something is being able to share an application with friends and family, stumbling over this is a discouraging problem.  
  
  2. The absence of some way to simply get the MFC libraries and headers (and templates, ideally) leaves a giant gap for newcomers who want to make native Win32 applications for whatever reason, leaves newcomers to rely on Petzold and the Platform SDK.  This is not working very well, as far as I can tell.  Ditto for ATL.  This is a giant barrier for newcomers.
  
  3. The lack of guidance and support for deployment is painful.  The side-by-side requirements and new manifest-packaging is a mystery that makes it worse.
  
  Of course, if newbies want to stay in the console-application world and only use standard libraries, static libraries, and simple EXEs everything works fine, including most textbooks, after a little preparation.  But somehow I don't think that's the appeal of using VC++ instead of some other good quality C/C++ compiler and basic IDE.
  
  I support the minimal concept approach, and having a small package.  I would hope there are ways to fill in the gaps for those who want to work in the Windows GUI application world.  If emphasis shifts to the WinFX set, I would hope that the WinForms and earlier cases would remain usable, even if they have to be obtained as supplemental packages available for download.  Modularization strikes me as preferable to creating chasms and barriers.
• Anonymous
  May 14, 2006
  Why not have Orcas target all available platforms quietly and simultaneously?  If there's a problem with one build, don't even alert the developer, so long as one of the available versions is chugging along fine.  If they are attempting to run the build, choose the latest version.  If they dig into the file system, they would see:
  
  release/bin/1.1/MyAssembly.exe
  release/bin/2.0/MyAssembly.exe
  
  or some equivalent hierarchy.  I agree fundamentally that this is not a choice an amateur developer will want to have to make, so my thought is to present them with the most convenient scenario possible.