The official source of product insight from the Visual Studio Engineering Team
Now that we have gone through some key concepts in the previous part in this series, before we go any further in terms of detailed technical concepts, it would be nice to have some “mental visual model” of how multi-targeting impacts almost all project related scenarios in Visual Studio 2010 and thus benefits the users.
Scott Guthrie’s excellent blog on multi-targeting support in Visual Studio 2010 covers many of these key benefits and scenarios. Please make sure you read that blog before you continue reading the rest of this series, as those help too in the “mental visual model” that I am aiming to establish with this part.
The key take away from Scott’s blog that I would like to highlight is that, because of the true multi-targeting support in Visual Studio 2010, being within the same IDE your project can target many different frameworks. This provides incredible productivity advantages in my opinion. So now - once you move your projects to Visual Studio 2010 - you can continue working with your projects that are targeted to frameworks earlier than .NET Framework v4.0 without doing anything!
I would like to add some more scenarios here to enhance the visuals and provide concrete visual examples that we can refer back to for the concepts as we encounter them in the rest of this series:
(All the example projects below are of the C# project type)
You will be able to create projects that target .NET Framework v2.0 in Visual Studio 2010
Once the project is created observe the ‘System’ assembly reference path in the Reference Properties window
The path in the Properties window refers to the ‘System’ assembly in .NET Framework v2.0 - to which the project is currently targeted. This ensures the developer is only able to use Types from this particular ‘System’ assembly in this project - as opposed to using Types from , say, .NET Framework v4.0’s ‘System’ assembly.
Now let’s launch the Add Reference Dialog for this project and go to the .NET tab
All the framework assemblies that are available to be referenced in this project come from .NET Framework v2.0; we can tell that by looking at the paths of the assemblies. The Add Reference dialog in Visual Studio 2010 is aware of the framework your project is currently targeted to and only shows assemblies that can be used in that Target Framework. This applies both to framework assemblies and framework extensions shown in the Add Reference dialog. Framework extension assemblies are third-party assemblies registered in the AssemblyFoldersEx. AssemblyFoldersEx will be covered in detail in a subsequent blog.
There is a common misconception that the assemblies shown in the Add Reference Dialog come from the GAC; this is not only incorrect but also somewhat of an oxymoron. The GAC is a ‘global’ assembly cache and therefore by definition not aware of a target framework boundary or presence of multiple target frameworks. Assemblies shown in the Add Reference dialog are always enumerated from the reference assembly paths of the target frameworks and never from the GAC. Reference assembly concepts will be covered in detail in a subsequent blog.
We can check the framework the project is currently targeted to, through its Properties page
We can also re-target the project to, say, .NET Framework v4.0 through the Properties page itself
After the re-targeting operation is complete, let’s go and check the Properties page again and confirm that the project is indeed now targeted to .NET Framework v4.0
Now let’s go and observe the ‘System’ assembly’s properties again in the re-targeted project
You can now see that the Path of the System assembly now comes from .NET Framework v4.0 and now suddenly the additional Types in this assembly is now available to the developer.
Now if we launch the Add Reference dialog we see that the v2.0 framework assemblies are no longer shown, what we see are the v4.0 framework assemblies – which we can again tell from their paths
The big picture that is emerging from all the examples above is that the whole design-time environment is being constrained and shaped by the target framework that the project is currently targeted to thus protecting the developer from any inadvertent type “leakage” of the types that are not really available in that framework at runtime.
Similarly users can also create projects that are targeted to the Silverlight framework-family and can work within the perimeters of that design time environment.
My hope with this visual tour, scenarios and user-benefit-examples in this blog and Scott’s blog is that as we continue on this journey and get into more detailed technical concepts the words there comes alive as you correlate those with these “mental visual models”.
This Visual Studio Managed Multi-Targeting series pertains to managed project systems and aims to provide a detailed round-up of all relevant/related topics.
Please feel free to use the comment stream to ask questions.
Previously, in this series:
Visual Studio Managed Multi-Targeting: Part 1: Concepts: Target Framework Moniker, Target Framework
Binu N. Chacko – Software Developer, Visual Studio Platform Team. Biography: Binu joined the Visual Studio team during the early stages of Visual Studio 2010. Prior to joining the Visual Studio team in early 2008; Binu spent eight years contributing to Windows XP, Windows 2003, Windows Vista, and System Center Configuration Manager 2007/R2 products – within Microsoft. Prior to that – outside/before Microsoft - he worked on helping deliver several versions of Canon’s premier Document Management System product. For Visual Studio 2010, Binu was a key contributor to the extensible multi-targeting core platform, solutions and the VB/C# project system core platform. Binu lives with his wife and the two joys of his life – his two sons – in Seattle, Washington; and loves cricket, soccer, theatre and movies.
Is it possible to use a single project to build for multiple targets ? (e.g build to 2.0, 3.5 and 4 versions).
Lior: not in the ordinary case. However, you could achieve this with some hand authored MSBuild script.
If you simply wanted to pick one, you could just pass /p:targetframeworkversion=XXX; or in VS, change the <TargetFrameworkVersion> property to have a Condition="'$(TargetFrameworkVersion) != ''" and set it as an environment variable.
If you want one build to build to several targets, one way could be to add a new target, hooked up in the simplest case by just naming it "AfterBuild" and putting it below the <Import> at the bottom, that used the <MSBuild> task on its own project "$(MSBuildProjectFullPath)" and passing a property for the other TFV.
Another way is to create two .csproj's, each with a different TFV property, but pull the body out into a shared <Import>ed file. The downside is that the VS editing experience would be poorer. To even get the sources to show up you would have to put this
to set "Visible" metadata on all "Compile" items.
Myself, I'd probably just make two projects, and make one pull in the other's sources using relative paths.
Obviously in the above post <azVisible> should be <Visible>..
So if you change the project to target a different runtime, the references to framework assemblies are automatically updated. What about third-party assemblies? Say I've purchased the ThirdParty library, and it ships with assemblies built for the 2.0 runtime and assemblies built for the 4.0 runtime. If my project targets the 2.0 runtime and references the 2.0-runtime ThirdParty.dll, and then I change my project to target the 4.0 runtime, will Visual Studio magically change my reference to use the 4.0-runtime ThirdParty.dll instead? If so, how does it find it?