Microsoft Windows Communication Foundation (WCF) tools are designed to make it easier for you to create, deploy, and manage WCF applications. This section contains detailed information about the tools. Please note that the tools are not supported.
You can run all the tools from the command line.
ServiceModel Metadata Utility Tool (Svcutil.exe)
Generates service model code from metadata documents and metadata documents from service model code.
Find Private Key Tool (FindPrivateKey.exe)
Retrieves the private key from a specified store.
ServiceModel Registration Tool (ServiceModelReg.exe)
Manages the registration and un-registration of ServiceModel on a single machine.
COM+ Service Model Configuration Tool (ComSvcConfig.exe)
Configures COM+ interfaces to be exposed as Web services.
Configuration Editor Tool (SvcConfigEditor.exe)
Creates and modifies configuration settings for WCF services.
Service Trace Viewer Tool (SvcTraceViewer.exe)
Helps you view, group, and filter trace messages so that you can diagnose, repair, and verify issues with WCF services.
WS-AtomicTransaction Configuration Utility (wsatConfig.exe)
Configures basic WS-AtomicTransaction support settings using a command line tool.
Windows Communication Foundation Tools
WCF System Requirements
Windows Communication Foundation (WCF) is a communication infrastructure used to create distributed applications. The following lists the requirements that enable WCF to run.
System Requirements
WCF is installed by default on Windows Vista.
WCF can also be installed on Windows XP SP2, Windows Server 2003 R2, or Windows Server 2003 SP1.
Note The Message Queuing (MSMQ) functionality of WCF is only supported on Windows Vista, Windows Server 2003 R2, Windows Server 2003 SP1, and .
What specifications will Windows Communication Foundation support?
Windows Communication Foundation will support a broad range of Web services standards, including basic standards (XML, XSD, XPath, SOAP, WSDL) and advanced standards and specifications that comprise the WS-* architecture. These include WS-Addressing, WS-Policy, WS-Security, WS-Trust, WS-SecureConversation, WS-ReliableMessaging, WS-AtomicTransaction, WS-Coordination, WS-Policy, and MTOM.
How to Windows Communication Foundation address Service Oriented Architecture (SOA)?
Windows Communication Foundation (WPF) is the first programming model built from the ground up to provide implicit service-oriented application(SOA) development, enabling developers to work autonomously and build applications that are more version independent.
How will Windows Communication Foundation change the way developers build applications?
Windows Communication Foundation radically simplifies development of distributed applications in several ways. First, Windows Communication Foundation reduces complexity by unifying the silos that exist with today's distributed technology stacks (Enterprise Services, System.Messaging, .NET Remoting, ASMX, and WSE). This enables developers to compose distributed applications using the best features of each of today's stacks. Second, Windows Communication Foundation maximizes developer productivity through an attribute-based programming model. Finally, Windows Communication Foundation is the first development framework built from the ground up on the principle of service-orientation enabling developers to build loosely coupled applications that interoperate securely and reliably across platforms.
Interacting with 2D on 3D in WPF
Interacting with 2D placed on 3D is now possible in v1 of the Windows Presentation Foundation!
WPF3D Team Blog
Logical Tree in WPF
In WPF, you add content to elements using properties. For example, you add items to a ListBox control using its Items property. By doing this, you are placing items into the ItemCollection of the ListBox control. To add elements to a DockPanel, you use its Children property. Here, you are adding elements to the UIElementCollection of the DockPanel.
Element Trees in WPF
Overview Base Elements
A high percentage of classes in Windows Presentation Foundation (WPF) are derived from four classes which are commonly referred to in the SDK documentation as the base element classes. These are UIElement, FrameworkElement, ContentElement, and FrameworkContentElement.
UIElement
UIElement is a base class for WPF core level implementations building on Windows Presentation Foundation (WPF) elements and basic presentation characteristics.
FrameworkElement
Provides a WPF framework-level set of properties, events, and methods for Windows Presentation Foundation (WPF) elements. This class represents the provided WPF framework-level implementation built on the WPF core-level APIs defined by UIElement.
ContentElement
Provides a WPF core-level base class for content elements. Content elements are designed for flow-style presentation, using an intuitive markup-oriented layout model and a deliberately simple object model.
FrameworkContent
ElementFrameworkContentElement is the WPF framework-level implementation of the ContentElement base class. FrameworkContentElement adds support for additional input APIs (including tooltips and context menus), storyboards, data context for databinding, styles support, and logical tree helper APIs.
Base Element APIs in WPF Classes
Visual provides a rendering framework by efining independent rectangular screen regions. In practice, UIElement is for elements that will support a larger object model, are intended to render and layout into regions that can be described as rectangular screen regions, and where the content model is deliberately more open, to allow ifferent combinations of elements. ContentElement does not derive from Visual; its model is that a ContentElement would be consumed by something else, such as a reader or viewer that would then interpret the elements and produce the complete Visual for Windows Presentation oundation (WPF) to consume. Certain UIElement classes are intended to be content hosts: they provide the hosting and rendering for one or more ContentElement classes (DocumentViewer is an example of such a class). ContentElement is used as base class for elements with somewhat smaller object models and that more address the text, information, or document content that might be hosted within a UIElement.
XAML Syntax Terminology
Object element syntax is the XAML markup syntax that instantiates a common language runtime (CLR) class or struct by declaring an XML element. This syntax resembles the element syntax of other markup languages such as HTML. Object element syntax begins with a left angle bracket (<), followed immediately by the type name of the class or struct being instantiated. Zero or more spaces can follow the type name, and zero or more attributes may also be declared on the object element, with one or more spaces separating each attribute name="value" pair. Finally, one of the following must be true:
The element and tag must be closed by a forward slash (/) followed immediately by a right angle bracket (>).
The opening tag must be completed by a right angle bracket (>). Other object elements, property elements, or inner text, can follow the opening tag. Exactly what content may be contained here is typically constrained by the object model of the element; see Content Syntax section in this topic. The equivalent closing tag for the object element must also exist, in proper nesting and balance with other opening and closing tag pairs.
For example, the following example is object element syntax that instantiates a new instance of the button class, and also specifies a Name attribute and a value for that attribute:
The following example is object element syntax that also includes Extensible Application Markup Language (XAML) content property syntax. The inner text contained within will be used to set the TextBox Extensible Application Markup Language (XAML) content property,
Types of WPF Applications
is essentially the equivalent of a .NET Windows Forms project with all the perks of the WPF API.
. .NET Framework 3.0 XAML Browser Application—The .NET Framework 3.0 XAML Browser
Application (XBAP) is the WPF version of an ASP.NET web application, with a limited amount
of WPF namespaces and functionality available to it, because of the browser’s security access
limitations on the client.
. .NET Framework 3.0 Service Library Project—The .NET Framework 3.0 Service Library is a
Windows Communication Foundation project type and is not held within its sibling WPF platform.
. .NET Framework 3.0 Custom Control Library Project—The .NET Framework 3.0 Custom Control Library is a project designed to output a reusable control that can be redistributed to a .NET application in the form of a dynamic-link library (DLL) .NET assembly.
WPF Required Installations
To create .NET Framework 3.0 applications—that is, applications that use WPF—you must have the following installed:
. Visual Studio 2005
. Windows SDK
. .NET Framework 3.0 Development Tools, or the "Orcas" release of Visual Studio 2005
. Windows Vista or Windows XP (with the .NET Framework 3.0)
Declaring a Window in XAML
<!-- Window1.xaml -->
<window class="HelloApp.Window1" x="http://schemas.microsoft.com/winfx/xaml/2005" xmlns="http://schemas.microsoft.com/winfx/avalon/2005" text="Hello">
<button name="button" width="200" height="25" click="button_Click">Click Hello!>/button>
</window>
Example Hello Program , WPF
// Hello.cs
using System;
using System.Windows; // the root WPF namespace
namespace MyFirstAvalonApp
{
class MyApp {
[STAThread]
static void Main( ) {
// the WPF message box
MessageBox.Show("Hello, Avalon");
}
}
}
Introducing .NET Framework 3.0
Key components of .NET Framework 3.0 include:
. Windows Presentation Foundation (WPF)—The graphical subsystem for all things related to
the UI
. Windows Communication Foundation (WCF)—The messaging subsystem of .NET Framework 3.0, securing program communication through a single API
. Windows Workflow Foundation (WF)—Provides workflow services for applications built to run on Windows.
Evolution of the Windows API
The Windows API exposes the core set of functionality provided by the Windows operating system for use in applications. Primarily designed for C/C++ development, the Windows API has been the most direct mechanism with which an application can interact with Windows.
The Windows API comprises the following functional groups:
. Base Services—Provides access to the core resources of the computer, such as memory, filesystems, devices, processes, and threads
. Common Control Library—A collection of common control windows used throughout the Windows operating system, providing the distinctive Windows look and feel
. Common Dialog Box Library—A collection of dialog boxes used to execute common tasks,
including file opening, saving, and printing
. Graphics Device Interface (GDI)—Provides the facilities for an application to generate graphical output to displays, printers, and other devices
. Network Services—Provides access to various networking capabilities of the Windows operating system, including RPC and NetBIOS
. User Interface (UI)—Provides the mechanism for managing windows and controls in an application and input from devices such as the mouse and keyboard
. Windows Shell—The container that organizes and presents the entire Windows UI, including the desktop, taskbar, and Windows Explorer
Through these services, developers have had significant flexibility in creating powerful applications for the Windows operating system. However, this flexibility also bore the responsibility of handling lowlevel and often tedious operations.
With each new release of the Windows operating system, additions and updates to the Windows API were almost always included. Yet with each release, Microsoft strived to support backwards compatibility. Thus, many functions included in the original Windows API still exist today in Windows XP and Windows Server 2003.
Introducing XAML
XAML (pronounced "Zamel") stands for eXtensible Application Markup Language. It is Microsoft's new declarative language for defining application user interfaces. XAML provides an easily extensible and localizable syntax for defining user interfaces separated from application logic, similar to the objectoriented technique for developing n-tier applications with a MVC (Model-View-Controller) architecture.
XAML was created by Microsoft expressly for the purpose of interfacing with its .NET Framework on its Windows Vista (formerly codenamed "Longhorn") operating system through the WinFX (codename "Avalon") presentation subsystem runtime environment. XAML gives developers the ability to control the layout of all .NET user-interface elements such as text, buttons, graphics, and listboxes, using XML .Because XAML is XML-based, your code must be well-formed XML. Every XAML tag corresponds directly to a .NET Framework class whose properties are controlled through the use of XML attributes.
For example, the "button" tag corresponds directly to the System.Windows.Controls.Button class.
XAML elements represent a Common Language Runtime (CLR) class, the runtime engine for
Microsoft's .NET framework. The CLR is similar to the Java Virtual Machine (JVM), except that the JVM can only run Java language programs, while the CLR can run applications written in a number of .NET languages, such as C#, J#, and VB.NET.
Because XAML elements represent CLR objects (this book focuses on those in the Windows Presentation Foundation [WPF]), anything that can be done with XAML can also be accomplished with procedural code. There are some things, however, that can be done by manipulating the object model programmatically that are not accessible through XAML. Properties that are read-only are not exposed through XAML; only those properties that are public and have both a get and a set method are accessible to XAML developers.
Events and handlers can also be specified by XAML attributes, and the necessary code behind the handlers, codebehind, can be written in .NET-supported languages—currently C# and VB.NET. This code can be inlined in the XAML file or placed in the codebehind file, similar to what is done with ASP.NET code. If procedural code is embedded in a XAML page, you must compile the application before you can run it; if there is no procedural code in the XAML page, you can display it on a Windows
Vista system by double-clicking the page file (just as you would with HTML pages). On Windows XP, however, the XAML pages must be "compiled" into an executable application before they can be displayed or loaded into a browser.
XAML is similar to other markup languages designed for rendering in web browsers, such as XHTML and HTML, and uses mechanisms similar to Cascading Style Sheets (CSS) for designating properties of XAML elements . Just as HTML objects are parsed to build out a Document Object Model (DOM) tree, XAML elements are parsed to build out an ElementTree .
XAML is inherently object-oriented since its elements represent CLR classes. This means that an element derived from another XAML element inherits the attributes of its parent. For example, a System.Windows.Controls.Button derives from System.Windows.Controls.ButtonBase, which derives from System.Windows.Controls.ContentControl, which derives from System.Windows.FrameworkElement, which derives from System.Windows.UIElement.
Therefore, the Button element has very few attributes of its own but still boasts a lengthy list of attributes that it has inherited from classes above it in the hierarchy, such as Width and Height. It is necessary to understand the nature of inheritance in order to take advantage of XAML and its ability to be extended.
Custom controls can be created for XAML by creating subclasses in one of the supported .NET languages (C# or VB.NET), for example, and then exposing the class to XAML developers for use in user-interface design.
Some XAML elements require children and attributes to be of a specific type, usually one of the base classes. Because of the nature of object-oriented programming, any element requiring that its children be of type UIElement can be declared as an element derived from UIElement. The Brush object is a very common attribute type for XAML elements, yet an instance of Brush is rarely used as an attribute.
Instead, one of Brush's subclasses, such as SolidColorBrush or LinearGradientBrush, is often used.
The nature of object-oriented programming allows an attribute to be broadly defined as a base class and lets the designer choose which specialized subclass will be used.
Overview XAML
When Microsoft releases Windows Vista, the new operating system will support applications that employ graphics now used by computer games-clear, stunning and active. The cornerstone for building these new user interfaces is XAML ("Zammel"), the XML-based markup language that works with Windows Presentation Foundation (WPF), Vista's new graphics subsystem.
An acronym for Extensible Application Markup Language, XAML offers a wealth of new controls and elements with exciting capabilities, including animation and rendering of 3D graphics. Windows developers are already jazzed by the possibilities of using XAML for fixed and flow format documents like PDF and HTML, 2D and 3D vector-based graphics, form development, animation, audio and video, transparent layering, and a lot more. Many feel that XAML will eliminate the need for multiple file formats or plug-ins (read: Flash), while lowering development costs and reducing time to market.
Are there any differences with WPF on Windows Vista versus earlier versions of Windows?
WPF doesn't expose any Windows Vista–specific APIs. But two interesting implicit features were unable to be supported on earlier versions of Windows:
· 3D objects only get anti-aliasing on Windows Vista or later
· Non-rectangular or translucent windows only get hardware acceleration on Windows Vista or later And of course, WPF controls have different default themes to match their host operating system (Aero on Windows Vista versus Luna or Classic on earlier systems).
One significant improvement in Windows Vista that helps WPF applications is a new driver model that helps with resource contention. It virtualizes and schedules GPU
resources, making your system perform better when multiple GPU-intensive programs are running. Running multiple WPF or DirectX applications might bog down a
Windows XP system, but shouldn't cause performance issues on a Windows Vista system.
When should I use WPF instead of Adobe Flash?
For creating rich web content, Flash is currently the most popular option because of its ubiquity. You can put Flashbased content on a website with confidence that the overwhelming majority of visitors already have the necessary player installed. (And if they don't, it's a very quick download.)
WPF applications can also run within a web browser. WPF has the advantage of better development tools and programming model, a richer feature set, robust control reuse, broad programming language support, and full access to the underlying platform (when security permits). But viewing such content requires Windows and the .NET Framework 3.0 (installed by default on Windows Vista or later).
When should I use WPF instead of Windows Forms?
WPF is clearly more suitable for applications with rich media, but some people have said that Windows Forms is the best choice for business applications with traditional
user interfaces. I think this belief is based on beta versions of WPF in which many standard controls didn't exist (such as TreeView, ListView, and OpenFileDialog) and a
visual designer didn't exist, making traditional Windows application development in WPF harder than in Windows Forms.
Although Windows Forms still has useful controls that WPF lacks (such as DataGridView and PropertyGrid) and at the time of writing has a larger set of third-party controls in the marketplace, WPF has compelling features even for traditional user interfaces
So unless running on Windows 98 is important (which is still supported by Windows Forms 2.0 but not by WPF), I would recommend WPF over Windows Forms for a broad
range of applications—especially after Visual Studio "Orcas" is released. But Windows Forms isn't going away anytime soon; there just won't be major enhancements
made to it after version 2.0 was released in 2005. Microsoft is clearly investing in WPF—not Windows Forms—as the future presentation platform.
When should I use WPF instead of DirectX? (Is DirectX dead?)
DirectX is definitely not dead and is still more appropriate than WPF for advanced developers writing hard-core "twitch games" or applications with complex 3D models
where you need maximum performance. That said, it's easy to write a naive DirectX application that performs far worse than a similar WPF application.
DirectX is a low-level interface to the graphics hardware that exposes all of the quirks of whatever GPU a particular computer has. DirectX can be thought of as assembly language in the world of graphics: You can do anything the GPU supports, but it's up to you (the application author) to support all the hardware variations. This is onerous, but such low-level hardware access enables skilled developers to make their own tradeoffs between fine-grained quality and speed. In addition, DirectX will undoubtedly expose cutting-edge features of GPUs as they emerge more quickly than they will appear in WPF.
In contrast, WPF provides a high-level abstraction that takes a description of your scene and figures out the best way to render it, given the hardware resources available. Internally, this might involve using Shader Model 3.0, or the fixed-function pipeline, or software. (Don't worry if you're not familiar with these terms, but take it as a sign that you should be using WPF!) The downside of choosing DirectX over WPF is a potentially astronomical increase in development cost. A
large part of this cost is the requirement to test your application on each driver/GPU combination you intend to support. One of the major benefits of building on top of WPF is that Microsoft has already done this testing for you! You can instead focus your testing on low-end hardware for measuring performance. The fact that WPF applications can even leverage the client GPU over Remote Desktop or in a partial-trust environment is also a compelling differentiator.
Does WPF enable me to do something that I couldn't have previously done?
Technically, the answer is "No," just like C# and the .NET Framework don't enable you to do something that you couldn't have done in assembly code. It's just a question of how much work you're willing to do to get the desired results! If you were to attempt to build a WPF-equivalent application from scratch without WPF, you'd not only have to worry about the drawing of pixels on the screen and interaction with input devices, but you'd also need to do a ton of additional work to get the accessibility and localization support that's built in to WPF, the special
handling of Remote Desktop built in to WPF so that remote applications can be rendered on the client to avoid a variety of performance issues, and so on. (Note that the optimized Remote Desktop experience only works when the server is running Windows Vista or later and the client has WPF installed.) So, I think most people would agree that the answer is "Yes" after you factor time and money into the equation!
Overview of Windows Presentation Foundation
Windows Presentation Foundation, also known as WPF, is the next-generation graphics platform on which both Windows- and web-based applications can be built to run on Windows Vista, the latest evolutionary release of the Windows operating system. WPF provides the foundation for introducing an elegant and high fidelity User Experience (UX) by juxtaposition of user interface, application logic, documents, and media content.
Programming Windows Presentation Foundation features:
· Scores of C# and XAML examples that show you what it takes to get a WPF application up andrunning, from a simple "Hello, Avalon" program to a tic-tac-toe game
· Insightful discussions of the powerful new programming styles that WPF brings to Windows development, especially its new model for controls
. A color insert to better illustrate WPF support for 3-D, color, and other graphics effects
· A tutorial on XAML, the new HTML-like markup language for declaring Windows UI
· An explanation and comparison of the features that support interoperability with Windows
Forms and other Windows legacy applications