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 (10)

  1. Now I agree with this. I think that the Express should still present the

    option to revert to older…

  2. Dan McKinley says:

    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.

  3. johnmont says:

    I’m not sure what the current plan for "big" VS.

  4. 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?

  5. peterpla says:

    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.

  6. mheller says:

    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.

  7. Surely this part:

    "…you’re confronted with a dialog box early on in creating your first project…"

    is unnecessary?  Even if VS Express were to support targetting older versions of the runtime, why on earth would you put that in the path the user goes through when creating their first project?

    Couldn’t you do something like support it, but not offer templates that do this as part of the initial install. Couldn’t downlevel support be something you install as an optional set of templates, maybe even a completely separate download?

    I think it’s handy for it to be possible, but it absolutely shouldn’t be something you might do by accident. For people who are sufficiently experienced with .NET to know that they actually want to target a downlevel runtime, I think it’s OK for that to be well off the beaten path so long as it’s possible and supported.

    Part of me is tempted to say that downlevel support is sufficiently obscure that there’s no need for an Express SKU to support it. However, I think that may change once Vista becomes widespread. The fact that we’ll finally have a client version of Windows with a built-in CLR out of the box is a hugely significant step forward. This will make the ability to target .NET 2.0 very important for a long time to come. (Unless the plan is to push out new versions of the framework in recommended updates and service packs.)

  8. WinForms should normally be supported till 2015 in theory…

  9. orcmid says:

    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.

  10. Kurtiss Hare says:

    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.