MSDN Magazine - February 2008 - (Page 123) What’s New for WCF in Visual Studio 2008 JuVal loWy isual Studio® 2008 and the underlying Microsoft® .NET Framework 3.5 offer new tools and support for Windows® Communication Foundation (WCF). They don’t change the basic capabilities of WCF 1.0 (released with the .NET Framework 3.0); rather, they extend and complete it. Visual Studio 2008 automates manual WCF tasks, which includes updating proxy references, and eliminates repetitive tasks such as creating simple host projects. Visual Studio also addresses some tough problems such as cross-targeting and data contract type sharing. In this column I’ll walk through the new features, point out their advantages, and explain any pitfalls and workarounds. Although I’ll use C# project settings here, everything applies to Visual Basic® as well unless I state otherwise. V .NET Framework Cross-Targeting Previous Visual Studio releases always targeted the version of the .NET Framework they shipped with. For example, Visual Studio 2005 can only generate assemblies that target the .NET Framework 2.0. This practice did not reflect the reality most developers face. Typically, developers need to maintain old versions of their applications written for previous versions of .NET while at the same time using the new version of Visual Studio on the application’s next version. Moreover, this practice meant that developers who were maintaining applications written for previous .NET Framework versions could not benefit from productivity enhancements, such as the code refactoring support introduced in Visual Studio 2005. The problem was that there was no cross-targeting of .NET Framework versions. You either had to have multiple versions of Visual Studio installed or compensate with separate testing and deployment builds. Visual Studio 2008 tries to address this by providing adequate (albeit imperfect) support for targeting multiple versions of the .NET Framework. Since the .NET Framework 3.0 and the .NET Framework 3.5 actually use the same CLR version as the .NET Framework 2.0, and the only differences are in new referenced assemblies, Visual Studio can still target the same runtime yet provide cross-targeting for This column is based on a prerelease version of Visual Studio 2008 and the .NET Framework 3.5. All information herein is subject to change. the .NET Framework versions 2.0, 3.0, and 3.5 (where the .NET Framework version number corresponds to release numbers, not runtime versions—that is still the CLR 2.0). In Visual Studio 2008, the Application pane of the project Properties contains a new combobox called Target Framework that allows you to target the .NET Framework versions 2.0, 3.0, and 3.5 (see Figure 1). The Target Framework With previous releases of value is only in effect at Visual Studio, you either had development time; it has to have multiple versions no effect at run time (your assembly still targets the installed or compensate .NET 2.0 CLR). The value with separate testing and you choose represents the deployment builds. oldest version of the .NET Framework your assembly can be built against. New projects are configured by default to target .NET Framework 3.5. It gets a bit more complicated when adding references; if you downgrade the Target Framework version while referencing higher-version assemblies, Visual Studio 2008 will prompt you, fault the reference, and fail the build. Visual Studio Figure 1 Target Framework Property in Visual Studio 2008 february2008 123
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.