{"id":2073,"date":"2010-05-19T13:04:00","date_gmt":"2010-05-19T13:04:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2010\/05\/19\/visual-studio-managed-multi-targeting-part-1-concepts-target-framework-moniker-target-framework\/"},"modified":"2019-02-14T15:39:26","modified_gmt":"2019-02-14T23:39:26","slug":"visual-studio-managed-multi-targeting-part-1-concepts-target-framework-moniker-target-framework","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/visual-studio-managed-multi-targeting-part-1-concepts-target-framework-moniker-target-framework\/","title":{"rendered":"Visual Studio Managed Multi-Targeting: Part 1: Concepts: Target Framework Moniker, Target Framework"},"content":{"rendered":"

In prior versions of Visual Studio, before Visual Studio 2010, the projects could only target .NET Framework versions v2.0, v3.0 and v3.5 therefore it was, mostly, sufficient to identify a framework only with its version.<\/span><\/span><\/span><\/p>\n

This is changing with Visual Studio 2010 – now projects will be able to target not only current versions of the .NET Framework, but they will also be able to target future versions of the .NET Framework and even target other framework-families like Silverlight. In other words Visual Studio 2010 supports true multi-targeting and truly extensible multi-targeting.<\/span><\/span><\/span><\/p>\n

Now suddenly the version itself is not sufficient to describe a Target Framework; we need a new kind of moniker to describe\/identify frameworks in the extensible multi-targeting world.<\/span><\/span><\/span><\/p>\n

Enter the Target Framework Moniker.<\/span><\/span><\/span><\/p>\n

Target Framework Moniker <\/span><\/span><\/span><\/b><\/p>\n

A Target Framework Moniker is a textual representation of a moniker that uniquely identifies a Target Framework.<\/span><\/span><\/span><\/p>\n

It generally takes the form:<\/span><\/span><\/span><\/p>\n

<Target Framework Identifier<\/span><\/i>>,Version=v<Target Framework Version<\/span><\/i>>,Profile=<Target Framework Profile<\/span><\/i>><\/span><\/span><\/span><\/p>\n

Examples are:<\/span><\/span><\/span><\/p>\n

\n
    \n
  • \n

    .NETFramework,Version=v4.0 <\/span><\/span><\/span><\/span><\/p>\n<\/li>\n

  • \n

    .NETFramework,Version=v4.0,Profile=Client <\/span><\/span><\/span><\/p>\n<\/li>\n

  • \n

    Silverlight,Version=v3.0<\/span><\/span><\/span><\/p>\n<\/li>\n<\/ul>\n<\/div>\n

    Thus the Target Framework Moniker has at the most 3 components; the Identifier, Version and a Profile.<\/span><\/span><\/span><\/p>\n

    The Identifier and the Version are mandatory while the Profile is optional.  <\/span><\/span><\/span><\/p>\n

    Target Framework Identifier<\/b>: is the identifier for the framework-family of the Target Framework; examples of the framework-families are .NETFramework, Silverlight etc.<\/span><\/span><\/span><\/p>\n

    Target Framework Version<\/b>: is the text representation of the numeric version of the Target Framework e.g. .NET Framework framework-family has versions v2.0, v3.0, v3.5, v4.0 or maybe in the future say v4.5. <\/span><\/span><\/span><\/p>\n

    \n

    A slight but important digression to clear up a common source of confusion; there is often uncertainty and confusion around the version numbers of Visual Studio, .NET Framework and CLR and especially the latter two. There is also often confusion about their relationships.<\/span><\/span><\/span><\/p>\n

    Visual Studio, .NET Framework and CLR have all their own independent versioning schemes e.g. Visual Studio 2003, 2005, 2008 and now 2010; .NET Framework v2.0, v3.0, v3.5 and now v4.0; CLR 2.0 and now 4.0<\/span><\/span><\/span><\/p>\n

    Visual Studio is always built using the latest version (at the time of its release) of .NET Framework and CLR. A particular version of .NET Framework is built on a particular version of the CLR.<\/span><\/span><\/span><\/p>\n

    E.g. Visual Studio 2010 is built on .NET Framework v4.0 and CLR 4.0. .NET Framework v3.5 is built on CLR 2.0.<\/span><\/span><\/span><\/p>\n

    Projects within Visual Studio 2010, directly, always target a particular version of the framework-family e.g. .NET Framework; projects never directly target a particular version of the underlying runtime for that framework-family e.g. CLR which is the underlying runtime for .NET Framework. <\/span><\/span><\/span><\/p>\n

    The following table, hopefully, makes the above discussion clear:<\/span><\/span><\/span><\/p>\n\n\n\n\n\n\n\n\n\n
    .NET Framework Version<\/span><\/span><\/span><\/strong><\/td>\nIs built on CLR version<\/span><\/span><\/span><\/strong><\/td>\n<\/tr>\n
    v2.0<\/span><\/span><\/span><\/td>\n2.0<\/span><\/span><\/span><\/td>\n<\/tr>\n
    v3.0<\/span><\/span><\/span><\/td>\n2.0<\/span><\/span><\/span><\/td>\n<\/tr>\n
    v3.5<\/span><\/span><\/span><\/td>\n2.0<\/span><\/span><\/span><\/td>\n<\/tr>\n
    v4.0<\/span><\/span><\/span><\/td>\n4.0<\/span><\/span><\/span><\/td>\n<\/tr>\n
    vFutureVersion<\/span><\/span><\/span><\/td>\n4.0<\/span><\/span><\/span><\/td>\n<\/tr>\n
    vAnotherFutureVersion<\/span><\/span><\/span><\/td>\nCLRFutureVersion<\/span><\/span><\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    <\/span><\/span><\/span><\/p>\n\n\n\n\n\n
    Projects in Visual Studio version<\/span><\/span><\/span><\/strong><\/td>\nCan target<\/span><\/span><\/span><\/strong><\/td>\n<\/tr>\n
    Visual Studio 2008<\/span><\/span><\/span><\/td>\n.NET Framework v2.0\/v3.0\/v3.5<\/span><\/span><\/span><\/td>\n<\/tr>\n
    Visual Studio 2010<\/span><\/span><\/span><\/td>\n\n

    .NET Framework v2.0\/v3.0\/v3.5\/ v4.0\/vNext<\/span><\/span><\/span><\/p>\n

    Silverlight v3.0\/v4.0<\/span><\/span><\/span><\/p>\n

    AnotherFrameworkFamily vXXX<\/span><\/span><\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    A key take away from all the above – if you want to pick one – is that Visual Studio projects always, directly, target a framework-family (e.g. .NET Framework) version and not the underlying runtime (e.g. CLR) version.<\/span><\/span><\/span><\/p>\n<\/blockquote>\n

    Coming back,<\/span><\/span><\/p>\n

    The third and optional component of the Target Framework Moniker is the Profile.<\/span><\/span><\/p>\n

    Target Framework Profile: <\/b>To understand profiles we need to understand Target Frameworks better and also understand full\/base Target Frameworks better. Therefore we shall discuss this in detail later in this blog. Meanwhile, in brief, the Profile is a targetable framework that is a subset of a Full Framework. For example, the Profile .NETFramework,Version=v4.0,Profile=Client<\/span> (Display name: .Net Framework 4 Client Profile<\/span>) is a subset of the full\/base .NETFramework,Version=v4.0<\/span> (Display name: .Net Framework 4<\/span>) Target Framework.<\/span><\/span><\/p>\n

    The Target Framework Moniker is a key to deduce the disk layout of the Target Framework’s Reference Assemblies. This will be discussed in a subsequent blog. <\/span><\/span><\/p>\n

    Just to provide some visuals, here are some of the areas you may encounter the Target Framework Moniker:<\/span><\/span><\/p>\n

    While creating a new project:<\/span><\/span><\/p>\n

    <\/span><\/p>\n

    On the VB\/C# project properties page:<\/span><\/span><\/p>\n

    <\/span><\/p>\n

    Please note that Visual Studio 2010 only shows the .NET Framework framework-family in the “New Project Dialog” and this is by design. But you can still open projects targeted to other framework-families like Silverlight in Visual Studio 2010. When you create a Silverlight project it actually targets the Silverlight framework-family.<\/span><\/span><\/p>\n

    What you see in the visuals above are the display names of the Target Framework. The display name is different from the Target Framework Moniker itself and is a display only string provided by the Target Framework Provider in the RedistList\/FrameworkList.xml. The RedistList will be discussed later in a subsequent blog about Reference Assemblies.<\/span><\/span><\/p>\n

    Target Framework<\/span><\/span><\/b><\/p>\n

    Even though the general concept of a Target Framework is probably generally understood by now – it is time to dive into the precise details of the Target Framework concept.<\/span><\/span><\/p>\n

    Target Framework is the design time manifestation of a runtime framework. For example Target Framework .Net Framework 4<\/span> represented by the moniker .NETFramework,Version=v4.0<\/span> is the design time manifestation of the corresponding runtime framework.<\/span><\/span><\/p>\n

    Target Frameworks are a design time concept. The corresponding runtime framework needs to be installed for the project’s output application\/module to run.<\/span><\/span><\/p>\n

    Target Framework is used by Visual Studio (and other tools like Expression Blend) and build environments to provide a design time environment to the project so that the executable\/module produced\/built there-forth is guaranteed to run on the corresponding runtime framework on any machine.<\/span><\/span><\/p>\n

    It helps a developer by preventing them from using a Type from a framework, in their project, which is not a runtime prerequisite for their project output binary.<\/span><\/span><\/p>\n

    Target Framework consists of a set of reference assemblies and supporting files on disk laid-out in a specified directory structure. Reference assemblies are the only source of static metadata and type information for a Target Framework. Reference assemblies and their layout will be discussed in detail in a subsequent blog in this series.<\/span><\/span><\/p>\n

    In general Target Framework refers to the Full\/Base Framework <\/b>e.g. <\/b>.NETFramework,Version=v4.0<\/span>. When targeted to the Full Framework the project can use the full surface area in that framework.<\/span><\/span><\/p>\n

    Some key Framework deployment scenarios may not require all the Types\/surface-area in the Full Framework and therefore the framework provider may provide a Profile Framework<\/b> instead e.g. .NETFramework,Version=v4.0,Profile=ServerCore<\/span>. The Profile only exposes a subset of the surface area of the parent Full Framework e.g. .NETFramework,Version=v4.0<\/span>; this subset may be a reduction in the number of assemblies, or in the number of Types in the assembly, or even a reduction in the members of a Type. Profile cannot add any new surface area – it is always a subset\/reduction. Profiles are the preferred delivery mechanism for “parts of a Full Framework”. The Profile framework is available to be targeted by a project, independently, just like any other Full Framework.<\/span><\/span><\/p>\n

    Consider this user story to understand Target Frameworks better:<\/span><\/span><\/p>\n

    \n

    Mark is a .NET developer. His development machine currently has Visual Studio 2010 and the .NET Framework v4.0. He develops web based inventory management software for a major distribution company. This software runs on a highly secured Windows Server 2008 machine and requires only .Net Framework v4.0 installed to run. In the course of using his development machine he finds he needs to install a new version of his company’s document management application which requires .NET Framework v4.1. The v4.1 framework included changes\/additions to System.web<\/span>. Now Mark’s Visual Studio project needs the v4.0 System.Web<\/span> assembly (or only Type metadata from the said assembly) in order to make sure that additions in the v4.1 System.Web<\/span> is not inadvertently included in his project. Without the v4.0 Target Framework Mark’s project\/application may inadvertently use v4.1 types, which will cause the application to fail when deployed.<\/span><\/span><\/span><\/p>\n<\/blockquote>\n

    To re-iterate the crux of the user story above – without the concept of the Target Frameworks and separate Target Frameworks for v4.0 and v4.1, the above developer may have inadvertently used Types from the v4.1 assembly thus rendering their application incapable of running on a machine with only v4.0 installed which is their only runtime pre-requisite. Issues like this can only be caught via deployment testing late in the product cycle.<\/span><\/span><\/p>\n

    <\/span><\/span><\/b><\/p>\n

    Conclusion<\/span><\/span><\/b><\/p>\n

    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. <\/span><\/span><\/p>\n

    Please feel free to use the comment stream to ask questions.<\/span><\/span><\/p>\n

    <\/span><\/span><\/b><\/p>\n

    Binu N. Chacko<\/b> – Software Developer, Visual Studio Platform Team.
    Biography: <\/b>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.<\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

    In prior versions of Visual Studio, before Visual Studio 2010, the projects could only target .NET Framework versions v2.0, v3.0 and v3.5 therefore it was, mostly, sufficient to identify a framework only with its version. This is changing with Visual Studio 2010 – now projects will be able to target not only current versions of […]<\/p>\n","protected":false},"author":13,"featured_media":255385,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[155],"tags":[1383,13],"class_list":["post-2073","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-visual-studio","tag-c","tag-visual-studio-2010"],"acf":[],"blog_post_summary":"

    In prior versions of Visual Studio, before Visual Studio 2010, the projects could only target .NET Framework versions v2.0, v3.0 and v3.5 therefore it was, mostly, sufficient to identify a framework only with its version. This is changing with Visual Studio 2010 – now projects will be able to target not only current versions of […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/2073","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/comments?post=2073"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/2073\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media\/255385"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media?parent=2073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/categories?post=2073"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/tags?post=2073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}