Saminnet-Search Article Wiki Forum Piwigo SNS Cloud vtiger Sugar
saminnet info

Articles

ASP.net Multi Targeting

Visual Studio multi-targeting enables you to take advantage of the latest enhancements to Visual Studio without having to upgrade Web sites or Web services to the latest version of the .NET Framework. This lets you use Visual Studio to maintain and develop Web applications that use earlier versions of the .NET Framework.

Web projects can target the following versions of the .NET Framework:

  • .NET Frameworkツ4

  • .NET Framework 3.5 SP1

  • .NET Frameworkツ3.0

  • .NET Framework 2.0 SP1

This topic contains the following sections:

  • Scenarios

  • Multi-Targeting Features

  • Selecting the Target .NET Framework Version

  • Adding Items to a Web Project

  • Adding Custom Web Server Controls to a Web Page

  • IntelliSense

  • Adding References

  • Configuration Files

  • Compiling

  • Deployment

  • Additional Information

Visual Studio multi-targeting enables you to perform the following tasks:

  • Open and work on existing Web projects in Visual Studio that were created by using Visual Studio 2008 or Visual Studio 2005, without upgrading them to theツ.NET Frameworkツ4.ツ

  • Create new projects that you want to deploy in run-time environments that are configured with earlier versions of the .NET Framework.

Visual Studio multi-targeting includes the following features:

  • When you open a project in Visual Studio that targets an earlier version of the .NET Framework, Visual Studioツcan automatically upgrade it or leave it targeted for the earlier version.

  • When you create a new project, you can specify the version of the .NET Frameworkツthat you want to target.

  • You can change the version of the .NET Framework that an existing project is targeted for.

  • You can target different versions of the .NET Framework in different projects in the same solution.

  • When you change the version of the .NET Framework that a project targets, Visual Studioツcan make any required changes to references and to Web.config files.

In addition, when you work on a project that targets an earlier version of the .NET Framework, Visual Studio dynamically makes changes in the development environment, such as the following:

  • It filters items in the New Project dialog box, in the Add New Item dialog box, in the Add New Reference dialog box, and in the Add Service Reference dialog box to omit choices that are available only in later versions.

  • It filters custom Web server controls in the Toolbox to remove those that are available only in later versions, and to show the latest version when multiple controls are available for the targeted version.

  • It filters IntelliSense to omit language features that are available only in later versions.

  • It filters items in the Properties window to omit properties that are available only in later versions.

  • It filters menus to omit options that are available only in later versions.

  • It creates new Web pages and class files that have the appropriate default namespaces.

  • It creates new Web.config files that have the appropriate sections, elements, and attributes.

  • It compiles and builds with the appropriate version of the compiler and with the appropriate compiler options. The appropriate compiler is also used when you precompile a Web site (such as through the Deployment menu) and for dynamic compilation at run time.

    Note Note

    ASP.NET multi-targeting is designed to work with Visual Studio. If you use other tools to change the contents of files in an ASP.NET Web application, such as text editors, results are unpredictable.

If you want to target a version of the .NET Framework earlier than versionツ4, you must have the .NET Frameworkツ3.5 installed on the computer that you use for development.ツThis is true whether you are creating a new project or changing an existing project. You might need to install the .NET Frameworkツ3.5, because by default the .NET Frameworkツ3.5 is not installed with the .NET Frameworkツ4.

Note Note

You might also have to install the IISツ6 metabase. Visual Studio needs the IISツ6 metabase API in order to manage application pools for local IIS Web sites. (When you select or change the targeted version of the .NET Framework for a local IIS Web site, Visual Studio assigns the correct application pool and creates an application pool for that purpose if necessary.) By default, the IISツ6 metabase is not installed in Windows Vista or Windows 7. For more information, see How to: Upgrade an ASP.NET Web Application to ASP.NET 4.

When you create a new Web project in Visual Studio, you select the target framework from a drop-down list in the New Web Site dialog box or in the New Project dialog box.

When you open a Web project that has not been opened in Visual Studio before, you areツasked if you want to upgrade the site to the current version of the .NET Framework. If you click Yes, Visual Studio makes the required changes to the Web.config file.

If you click No, Visual Studio determines the targeted version of the .NET based on what it finds in the Visual Studio project file or in the Web.config file. For more information, see Additional Information at the end of this topic.

The target framework for existing projects can be changed. However, the normal direction in which to make a change would be from an earlier version to a later version.

Note Note

ツツツIf you change the target to an earlier version of the .NET Framework, Visual Studio might not be able to automatically make all the changes that would be required. You might have to make changes manually in order to run the project.

For information about how to change the target Framework version of an existing project, see Additional Information at the end of this topic.

Visual Studio filters item templates that are displayed in the Add New Item dialog box based on the currently targeted version of the .NET Framework.

When you add an existing item to a project, Visual Studio does not verify that references for that item match the currently targeted version of the .NET Framework. No warnings are generated. However, if those references cannot be resolved in the project, you might see warnings or errors when you build and run the project.

Visual Studioツhidesツcustom Web server controls in the Toolbox that do not apply to the currently targeted version of the .NET Framework. If multiple versions of a custom Web server control are installed, Visual Studio hides all but the most current version. To see all versions, you can right-click the Toolbox and select Show All.

Note Note

This Toolbox behavior applies only to compiled custom controls, not to user controls (.ascx files) or to built-in ASP.NET controls.

The Toolbox multi-targeting behavior assumes that custom Web server controls for a specific version of the .NET Framework can be used in projects for that version or for later versions. For instance, it assumes that .NET Frameworkツ2.0 controls can be used in projects that target the .NET Frameworkツ2.0, theツ.NET Frameworkツ3.0, or the .NET Frameworkツ4.

Visual Studio provides IntelliSense for C#, Visual Basic, and ASP.NET markup that is adapted to the features of the targeted version. JScript IntelliSense is independent of the .NET Framework version that the project is targeting.

When you open the Add Reference dialog box, Visual Studioツdisplays all available assemblies but disables those that are for a later version of the .NET Frameworkツthan the version that is targeted. If you hold the mouse pointer over a disabled assembly, a tooltip explains why it is disabled.

You might add a user assembly reference to your project that in turn references system assemblies that are not part of the target framework. In that case, Visual Studio displays a warning. If you ignore this warning, run-time errors might result.

If you add a reference manually (by modifying project files directly without using the Add Reference dialog box), Visual Studio does not check the reference. If you add a reference that is not appropriate for the targeted framework version, you might see warnings or errors at design time, build time, or run time.

For information about adding service references, see Additional Information at the end of this topic.

In projects that target the .NET Frameworkツ4 or later versions, the compilation element of the Web.config file contains a targetFrameworkツattribute, as shown in the following example:

<configuration>
  <configSections>...</configSections>
  <appSettings/>
  <connectionStrings/>
  <system.web>
    <compilation debug="false" 
        targetFramework="4.0">
    ...
    </compilation>
  </system.web>
  ...
</configuration>

Visual Studio automatically inserts the targetFramework attribute when you upgrade a project to the .NET Frameworkツ4. It removes the attribute when you change a project's target from the .NET Frameworkツ4 to an earlier version.ツ

The Visual Studio design-time environment makes sure that you use only language and framework features that are available in the targeted version of the .NET Framework. If you edit the files of a Web project outside of Visual Studio and introduce code that refers to language or .NET Frameworkツfeatures that are not available in the targeted version, the compilation system will report an error when the project is compiled.ツFor information about specific exceptional situations which might result in compile errors before or after deployment, see Additional Information at the end of this topic.

When a Web site runs under IIS, the scriptmap (in IISツ6) or application pool (in IISツ7) must specify the targeted version of the .NET Framework. For more information, see How to: Deploy Web Projects Targeted for Earlier Versions of the .NET Framework.

The Copy Web Site tool in Visual Studio does not check the version of the .NET Framework that is running on a remote server. This tool cannot notify you if you copy a Web site project to a target server that does not contain the targeted version of the .NET Framework. In that case, the Web site might not run or might report run-time errors.

ASP.NETツ4 applications that are configured as children of applications that run earlier versions of ASP.NET also might not run. For information about how to fix this, see the section "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" in the document ASP.NET 4 Beta 2 Breaking Changes on the ASP.NET Web site.

For more information about Web project deployment, see Web Deployment Overview for Visual Studio and ASP.NET.

This section provides details about some of the issues discussed earlier in this topic.

When a Web project that was created by an earlier version of Visual Studio is opened in Visual Studio 2010 for the first time, you can choose not to upgrade the project to ASP.NETツ4. If you do that, the target version of the .NET Frameworkツis determined by using the following criteria:

  • If the project was created or updated by a version of Visual Studio that supports multi-targeting, and if you open the project by using the Visual Studio project file, Visual Studio uses the information that is stored in the project file.

  • If the previous criterion does not apply and if one of the following is found, Visual Studio targets the .NET Frameworkツ3.5:

    • A compilers section in the Web.config file that maps to a compiler version of "v3.5" for C# or for Visual Basic.

    • References to .NET Frameworkツ3.5 assemblies.

  • If the previous criteria do not apply and references to .NET Frameworkツ3.0 assemblies are found, Visual Studio targets the .NET Frameworkツ3.0.

  • If the Web site does not meet any of the previous criteria, Visual Studio targets the .NET Frameworkツ2.0.

    Note Note

    A Web application project includes Visual Studio project files. These files are converted to the Visual Studio format even if you choose not to target an earlier version of the .NET Framework. For more information, see How to: Upgrade an ASP.NET Web Application to ASP.NET 4.

The location of the list of target .NET Framework versions that you can choose from depends on the type of Web project. The list can be in one of the following locations:

  • For C# Web application projects, the list is in the Application tab of the project properties dialog box.

    Application tab of project properties dialog box
  • For Visual Basic Web application projects, the list is in the Advanced Compiler Settings dialog box, which you can reach by clicking the Advanced Compiler Options button on the Compile tab of the project properties dialog box.

    Advanced Compiler Settings dialog box
  • For all Web site projects, the list is in the Property Pages dialog box.

    Property Pages dialog box

When you change the target framework, Visual Studio might require you to close and re-open the project.

The list from which you select the version of the .NET Framework might include options that refer to subsets of the .NET Framework. These subsets are called profiles. A profile must include the System.Web assembly in order to be suitable for Web development. If you select a profile that is inappropriate for a Web application project, an error might occur when the Web site is compiled or when it is run.

Note Note

If you change the target to an earlier version of the .NET Framework, Visual Studio might not be able to automatically make all the changes that would be required. You might have to make changes manually in order to run the project.

The Add Service Reference dialog box is available only in Web sites that target the .NET Frameworkツ3.5 or later versions, and in Web application projects that target the .NET Frameworkツ3.0 or later versions.

If you want to add a service reference to a Web site that targets the .NET Frameworkツ3.0, you can add the service reference to a class library project. You can then reference the class library project from the Web site project.

Note Note

Class libraries cannot be added to a project in Visual Web Developer Express.

If you manually add the targetFramework attribute to the Web.config file of a Web application that targets earlier versions of the .NET Framework, an error will result.

Adding the targetFramework attribute to the root Web.config file instead of to each application Web.config is not recommended, for the following reasons:

  • There is no benefit to putting the targetFramework attribute in the root Web.config, because Visual Studio manages the targetFramework attribute.

  • The multi-targeting feature of Visual Studio will not work correctly if you put the targetFramework attribute in the root Web.config file of a development server.

Visual Studio relies on information in the Web.config file to determine which version of the .NET Framework is targeted. Therefore, some errors can arise that do not apply to Web application projects. This is because for Web application projects, the target version that is stored in the Visual Studio project file is used for compiling.

The following scenarios for Web site projects might result in unexpected results:

  • In a Web site project that targets the .NET Framework 4.5 or later versions, the targetFramework attribute is removed.

    Visual Studio compiles the project as if it were targeting the .NET Frameworkツ3.0. If the Web site uses features that are not available in the .NET Frameworkツ3.0, compile errors will result.

  • In a Web site project that targets the .NET Frameworkツ2.0, references to .NET Frameworkツ3.0 features are added by using a tool other than Visual Studio, such as a text editor.

    Visual Studio compiles the project as if it were targeting the .NET Frameworkツ3.0. Therefore, there is no compile error that warns about the use of .NET Frameworkツ3.0 features. But if the Web site is deployed to a server that does not have the .NET Frameworkツ3.0 installed, errors might result.

  • A Web site project that targets the .NET Frameworkツ2.0 or the .NET Frameworkツ3.0 is deployed to a server that does not have the .NET Frameworkツ3.5 installed, and markup in .aspx pages refers to control properties that are new in the .NET Frameworkツ3.5.

    In order to target versions of the .NET Framework earlier than versionツ4, the computer that runs Visual Studio must have the .NET Frameworkツ3.5 installed. Therefore, when the Web site is tested in Visual Studio, references to properties that are defined in the .NET Frameworkツ3.5 will result in behavior that would be expected for the .NET Frameworkツ3.5. However, if the Web site is deployed to a server that does not have the .NET Frameworkツ3.5 installed, these properties will not be recognized, and they might be treated as expando attributes.

  • An IIS Web site project that targets a .NET Framework version earlier than the .NET Frameworkツ4 is nested in IIS within an IIS Web application that targets the .NET Frameworkツ4.

    Web.config files inherit settings from files that are higher in the IIS application hierarchy. The .NET Frameworkツ4 is backward compatible. Therefore, a nested application that targets the .NET Frameworkツ4 can inherit settings from Web.config files that are for earlier versions. But versions of the .NET Framework are not forward compatible. Therefore, earlier versions cannot inherit settings from later versions.

Visual Studio makes sure that only features that are relevant to the targeted .NET Frameworkツversion are used in a Web site project. When the Web site project is deployed to a production server and is dynamically compiled, ASP.NET uses the assemblies that are in the GAC for the CLR version that is associated with the Web application's IIS application pool. Therefore, unexpected results can occur during dynamic compilation if the Web application is associated with the wrong CLR version.

The assemblies that are used for dynamic compilation might be for a later .NET Framework version than the version that the Web application targets. The GAC contains only the most current assemblies for each version of the CLR that is installed on a computer. Therefore, the compiler uses the most current version of the .NET Frameworkツthat is installed on the computer for the selected version of the CLR. For example, the .NET Frameworkツ2.0, the .NET Frameworkツ3.0, and the .NET Frameworkツ3.5ツall use the .NET Frameworkツ2.0 CLR. If a computer has the .NET Frameworkツ3.5 installed, and if a Web application uses an application pool that is associated with the .NET Frameworkツ2.0 CLR, ASP.NET uses the .NET Frameworkツ3.5 assemblies.

The aspnet_compiler.exe and aspnet_merge.exe tools can be used from the command-line directly or within a build environment. When you compile a Web site by using one of these tools, you must use one of the following versions:

  • The version that is provided with the .NET Frameworkツ2.0. This version is for Web sites that target the .NET Frameworkツ2.0, the .NET Frameworkツ3.0, or the .NET Frameworkツ3.5. The sites must be deployed in an application pool that is associated with the targeted version of the .NET Framework.

  • The version that is provided with the .NET Frameworkツ4. This version is for Web sites that target the .NET Frameworkツ4 and later versions of the .NET Framework. This version of the tool will create assemblies that work only with the .NET Frameworkツ4 CLR even if the Web.config file lacks the targetFramework attribute.

    You can use this version to compile an application whose Web.config file indicates that it targets one of the earlier versions, which is useful if you intend to deploy the application to an application pool that is associated with the .NET Frameworkツ4.

For more information about the command-line compiler and dynamic compilation, see the following topics:

The Visual Studio environment always runs the latest version of the .NET Framework, even when the project targets an earlier .NET Framework version. To provide multi-targeting functionality, Visual Studio filters metadata about types to make sure that projects that target earlier versions do not use classes or members that were introduced in .NET Framework versions later than the target. Because of this filtering, IntelliSense, property windows, and so on present information that is appropriate to the targeted version.

If a custom Web server control must determine at design time whether a class or members of a class exist, the code should use the TypeDescriptor class instead of using reflection. This makes sure that the code finds only classes or members that are available in the version of the .NET Framework that is targeted in the project where the control is used. The use of reflection will circumvent the type-filtering mechanisms that Visual Studio uses for a given .NET Framework target.

Only the latest version of a custom control is typically shown in the Toolbox. If you want earlier versions to remain accessible in the Toolbox, and if the control's assembly is deployed to the Bin folder rather than to the GAC, make sure that the assembly names for each version of the control are different.

When a control is dragged from the Toolbox to a Web page, the assembly is copied to the Bin folder. Therefore, if the site already has instances of an earlier version of the custom Web server control, and if the latest version is then dragged onto a page, the new version will overwrite the earlier versions of the control in the Web site's Bin folder. Because Visual Studio already has the older version in memory, copying over the assembly in the Bin folder might cause errors.

For more information about how to make sure that custom Web server controls work correctly with ASP.NET multi-targeting, see Web Custom Control Behavior and Authoring on the Visual Web Developer team blog.

You should make sure that any code that is generated through build providers and expression builders works with different versions of the .NET Framework. Build providersツand expression builders should check theツBuildManager.TargetFramework propertyツto determine which .NET Framework version a project targets, and generate only code that is valid for the targeted version.

Comments   

 
0 #1 Guest 2020-01-09 16:37
I have bbeen surfing online more than 2 hours today, yett I never found
any interesting article like yours. It's pfetty worth enough for me.

In mmy view, if all web owners andd bloggers made good content as you did, the internet
will be much more useful than ever before.

Also visit my page: john crestani
super affiliate system
Quote
 

TweetTweet Share on LinkedInShare on LinkedIn Share on Google+Google+ Submit to RedditReddit Publish on WordPress WordPress Send emailSend email