Earlier this week a new preview for the ASP.NET Model-View-Controller framework showed up on the web. For those of you that haven't heard of MVC before, it's a framework on top of the existing ASP.NET runtime that modernizes the ASP.NET development experience a bit in terms of separating display and application logic as well as making test-driven development of ASP.NET applications easier.
You can get the preview now as well as a variety of other resources.
The basis of a channel stack is that there is a series of objects that share a common interface for communication. This leaves message encoders with something of a problem as the primitive operations for encoding and decoding messages are different than the primitive operations for sending and receiving messages. Message encoders avoid this problem by being contained within a channel rather than acting as a peer in the channel stack. However, this is different than the model used for bindings, which make the message encoding binding element a peer of the other channel binding elements.
To make things harder, bindings use a "no lookahead" construction process where constructing an object cannot speculate about future construction by looking into the unprocessed information in the binding. That results in a subtle dance between a message encoder and a channel that wants to use a message encoder.
During the construction process, a binding gives you only a context for storing computed information and the ability to initiate the next phase of the construction process. When we go to build a message encoder, it's not possible to actually build anything because the channel that will hold the message encoder doesn't exist yet. The message encoder doesn't know how or why it is going to be used. Instead, what a message encoding binding element does to build is add itself to the BindingParameters in the context. The message encoding binding element then initiates the next phase of the construction process. At some point in the future, a channel may look at the context to see if it contains a previously saved binding element, which can now be built. The delay in instantiation is what allows channels to have a different order for physical containment than the logical order of the binding elements.
Next time: Quotas for Copying Messages
The PDC 2008 conference registration site is now up and running. PDC is running this year from October 27th to 30th in Los Angeles, putting the countdown clock right now at a little over 152 days. There's already a preliminary session list available although at this point they'd probably have to be pulling the sessions out of thin air. I'd expect a real session list to come out in a few months that you can use to plan what you want to see.
How do I get access to the service instance from inside of a service operation?
Assuming that you're executing somewhere that a service operation is meaningful, you'll have access to the service operation context OperationContext.Current. From the service operation context you can get the service instance context and from the instance context you can ask it to GetServiceInstance.
How does the context know how to give you a service instance?
Early on in the execution of the operation, the service operation context was created. Shortly thereafter, a service instance context was created or one was reused if we happened to have it lying around and the service instance context was attached to the service operation context. The service instance context had attached to it an IInstanceProvider, which is the extensibility point for managing instances. There are a variety of instance providers for different uses that come with the system. An instance provider is able to cough up an instance based on a service instance context and optionally the message that is being processed.
Next time: Building with Encoders
There's more than one way to work with workflow, which is why Windows Workflow Foundation and BizTalk Server are both tools for programming workflow applications. If you've ever wondered why there are two workflow products and which one to use, then read Kent Brown's article on choosing the right workflow tool to clear up your confusion. Or, don't read the article and remain confused. It's up to you.
I rarely need to set up machines often enough to remember the setup instructions and finding the documentation for setup sadly never seems to help. Lately I've been referring to the appendix on setup in Michele Bustamante's Learning WCF book when I need to install SQL, configure IIS, or work with certificates. Michele's setup instructions were only supposed to cover the samples in the book but I've found them to be better than the other resources that I've got on hand.
Next time: Finding the Service Instance
When I talked about some of the enhancements in Orcas, I left out a performance improvement for services that use a large number of known types. There are various ways of defining the known types for a service operation, and all of the known type collections are aggregated together for use the first time that an unknown type needs to become a known type. The performance of that first call grew increasingly worse rather quickly as the number of known types increased, although the performance of successive calls was not affected.
This slowdown was fixed in Orcas (you don't need Orcas SP1 to get it). If you are seeing a pattern of slow first calls that is improved by not declaring known types, then you may want to see if installing Orcas makes your first call faster.
Next time: Common Setup Tasks
FaultException supports both an untyped variant, for when you don't have any particularly interesting detail to provide, and a typed variant, for when you do. Don't use a subclass of Exception as the type of a typed FaultException. Here's why.
When you use a typed FaultException, you are creating a fault contract between the client and service about data that gets exchanged and a common type system that the two share. By using a CLR exception type, you are unnecessarily forcing that common type system to reflect details of the CLR type system. That type dependency will make it more complicated in the future to move your services and clients to other platforms and possibly even to other versions of the framework. When moving to another version of the framework, you may change the exception profile of your application and start receiving exception types that are more specific or different than the exception types that you received before for a particular error. If you pass those exceptions through to the client, then those platform implementation details are now leaked across the service boundary. Finally, there's no guarantee that the interesting information in a CLR exception will be preserved across the boundary. Most of the interesting contents of exceptions are not serializable.
Instead of creating a FaultException with a subclass of Exception, you should define a fault contract that is meaningful for your application or business user. This fault contract can be crafted according to the needs of your service and will remain independent of any particular platform or technology choices that you may need to make later.
Next time: Faster Known Types in Orcas
I've previously talked about using WSDL extensions to provide custom modifications to the WSDL import and export process. Making modifications to an existing WSDL document or to the existing WSDL processing is a great way to make small changes when the default behavior almost gets you to where you want. However, you may have noticed that these mechanisms are a little cumbersome for providing a complete overhaul of metadata; that's because a WSDL extension is primarily a hook to supply user extensibility before or after certain steps in the WSDL import or export process.
When making large-scale modifications, another tool in your toolbox is to entirely jump out of the built-in WSDL processing. The ExternalMetadataLocation property on the ServiceMetadataBehavior is one of the ways that you can opt out of the standard process. By supplying an external metadata location, you provide to clients a reference to an independent location for retrieving metadata. You might base the contents of that external metadata on the metadata files normally generated by the service (the disco.exe tool in the Windows SDK is a good way to generate all of those metadata files at once) or you might go completely wild and make the external metadata have no relationship at all to the normally generated metadata files.
Next time: Avoid Exceptions in Faults
I noticed the other day that O'Reilly has a new book format for prerelease software that relies on planning for and making incremental updates as the software is developed. After the software is released, the prerelease book and all of its updates are cleaned up and turned back into a book with standard formatting. It looks like a Silverlight 2 book is being used as the test subject.
I think this approach is interesting as a response to how quickly software is developed and then obsoleted these days. Additionally, software is being developed with increasing amounts of transparency. Customers get early builds and trickles of information long before the official release date, and often while the software is still very malleable. By the time software is stable enough to write a real book about it, you've already missed the best window for publication for that release.
In the past I've written about overriding ApplyConfiguration on a service to take control of the configuration process. There is a similar technique that you can use for client proxies although getting started is not quite as obvious. I'll talk today about the typed proxies generated by constructing a ChannelFactory<T>. When you're using ChannelFactory<T>, you are midway between the tool-based automatic proxy generation and the channel-based manual proxy construction. Everything here also applies to the base ChannelFactory if you don't need the supplied type parameter.
On ChannelFactory there are two interesting methods that you can override in subclasses.
protected virtual void ApplyConfiguration(string configurationName);protected abstract ServiceEndpoint CreateDescription();
ApplyConfiguration is similar in spirit to the ApplyConfiguration on a service but has a little bit of a different interaction with CreateDescription. All of the heavy lifting for building the endpoint (the address, binding, and contract) is done in CreateDescription. All that is done in ApplyConfiguration is to load behaviors for the client proxy from configuration.
Since ApplyConfiguration is not as interesting on the client, there are going to be more cases where you need to override both ApplyConfiguration and CreateDescription. If you only need to fix up the generated proxy, then you may be able to use the base implementation for both ApplyConfiguration and CreateDescription, and apply your changes to the description in an override of ApplyConfiguration. If you want to make more extensive changes to the configuration or client proxy generation process, then you're less likely to be able to use the base implementation of ApplyConfiguration and may need to override CreateDescription as well.
Next time: Pointing to External Metadata
Extensibility in configuration allows you to call out to types that you define for things such as behaviors, bindings, and channels. These type references are to fully qualified assemblies using information such as the assembly name, file path, code version, and so on. However, in a configuration file these references are ultimately represented as text and that text must be turned into object references at runtime. Because this process requires the machine to be appropriately configured, the process of binding and loading an assembly can sometimes fail.
In the Windows SDK there is a tool called the Fusion Log Viewer (fuslogvw.exe) that can help you diagnose errors binding and loading an assembly. By default logging is disabled, but you can specify logging either for failures or for all events in the case that an assembly is being loaded but it's not the copy of the assembly that you expected. You'll need administrative permission to change the logging settings but there are no permissions or changes to your application needed to take advantage of this feature.
Next time: Customizing Proxy Configuration
Yesterday, a beta version of the first service pack for .Net Framework 3.5 was released including fixes and new features for WCF. The new features are primarily around serialization and tooling although there are enhancements scattered throughout many features.
All of the files are available for public download.
In addition to not being compatible with the previously released Silverlight SDK, there are two known issues for the beta.
HTTP POX is not composable with One-way
The OneWayBindingElement class is designed to create client-side channels that expect null messages as responses; otherwise, it fails with a ProtocolException error. Standard message encoders return messages that have a non-empty message body. However, in a POX/REST scenario, you may want to process messages based solely on the contents of HTTP headers (for example, 200 for success; otherwise, failure), rather than the message body. Because message encoders do not let you return null messages based on HTTP headers in these scenarios, it is not possible to use OneWay contracts on the client side.
To resolve this issue:
In the channel stack configuration, add a filter channel between OneWayBindingElement and HttpTransportBindingElement that checks the HTTP response status code. If the code indicates success, it returns null; otherwise, it returns the original response message. The final configuration appears as follows, with a custom binding element that filters the responses. CustomBinding binding = new CustomBinding( new OneWayBindingElement(), new MyMessageFilterByHttpHeaders(), new TextMessageEncodingBindingElement(), new HttpTransportBindingElement() ); binding.Elements.Find<MessageEncodingBindingElement>().MessageVersion = MessageVersion.None;
Windows XP issue when AllowNtlm is set to false
In WCF, if you specify the clientCredentialtype property as Windows and negotiate the client credentials, you can enable NTLM to be used as a negotiation package. The default behavior for WSHttpBinding and WS2007WttpBinding is to negotiate Windows client credentials. You can control this behavior in WCF by modifying the allowNtlm property. In the .config file, put the clientCredentials tag in an endpointBehavior tag. In the code, set a property on WindowsClientCredentials. There is a behavior change in SP1 that affects WCF running on all versions of Windows later than Windows XP. When allowNtlm is set to false, WCF in .NET Framework versions 3.0 and 3.5 would instruct spnego to use Kerberos as the negotiation package. The behavior change in SP1 excludes NTLM by passing additional information to the negotiation layer. This change enables additional sspi packages to be negotiated if they are available and supported by future versions of Windows. However, this functionality is not available in Windows XP, and users who set the AllowNtlm to false will experience problems.
Set SecureConversation to false when you set AllowNtlm to false.
When debugging a WCF project in Visual Studio the WCF Service Host starts up to host my service. How do I stop this from happening so that I can use my own service host?
One of the new tools in Orcas is the WCF Service Host that allows you to automatically host and test a service that you've implemented. The WCF Service Host comes along with some of the specialized WCF project templates in Visual Studio, such as WCF Service Library and Syndication Service Library.
If you've picked one of these project templates, then I don't know of a good way of disabling the service host. This should be fixed in SP1 by adding some user interface to toggle the service host on and off. In the meantime, you can perform some surgery on the project file to work around this. If you look inside the actual csproj file for your project, then you'll see a PropertyGroup section that defines the project.
<PropertyGroup> <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform> <ProductVersion>9.0.21022</ProductVersion> <SchemaVersion>2.0</SchemaVersion> <ProjectGuid>{3CC71D2E-7EC2-46B5-B985-F889B65E3DCD}</ProjectGuid> <OutputType>Library</OutputType> <AppDesignerFolder>Properties</AppDesignerFolder> <RootNamespace>WcfServiceLibrary1</RootNamespace> <AssemblyName>WcfServiceLibrary1</AssemblyName> <ProjectTypeGuids>{3D9AD99F-2412-4246-B90B-4EAA41C64699};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> <StartArguments>/client:"WcfTestClient.exe"</StartArguments> <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> </PropertyGroup>
The ProjectTypeGuids list is what controls these special features of projects. Removing the {3D9AD99F-2412-4246-B90B-4EAA41C64699} entry from the list will disable automatic service hosting.
Next time: Debugging Type Loading
What's the difference between the Name and ConfigurationName on service contracts and behaviors?
The Name property sets the name of the service in metadata while the ConfigurationName property sets the name of the service in configuration. Metadata is the part of the service description that is transmitted to others when they interrogate your service. Configuration is the purely local settings for controlling the service.
Since Name is more commonly used, I'll just run through a quick example focusing on setting ConfigurationName instead. Here I've got a service contract and implementation setting both the Name and ConfigurationName properties.
[ServiceContract(Name="NotIService", ConfigurationName="IService")]public interface IMyService{ [OperationContract] void DoNothing();}[ServiceBehavior(Name = "NotService", ConfigurationName = "Service")]public class MyService : IMyService{ public void DoNothing() { }}
In my app.config file, the way I'd refer to that service and service endpoint is by the ConfigurationName.
<service name="Service"> <endpoint address="http://localhost:8000/" binding="basicHttpBinding" bindingConfiguration="myBindingConfiguration" contract="IService"/></service>
On the other hand, everywhere in the metadata, generated proxy, and even the generated proxy configuration file the service will appear as NotIService and NotService.
Next time: Disabling the Visual Studio Service Host
I haven't had nearly as much time as I wanted to write about our efforts porting WCF to the Silverlight platform or tell you about what we've managed to build. I'm still planning to do feature highlight posts along the way but your best source of day-to-day information is going to be the WCF Silverlight team blog.
I have a data contract that contains a collection type but the generated proxy appears as an array. How can I make the proxy use a collection type as well?
I've talked in the past about how the representation of a type in metadata is decoupled from the CLR representation of a type in the service. For example, if I have a data contract that uses a List:
[DataContract]class Data{ [DataMember] public List<string> data;}
Then, the metadata representation of this data contract is actually described as an array because arrays are the only primitive type for collections in schema.
<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/" elementformdefault="qualified" targetnamespace="http://schemas.datacontract.org/2004/07/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays"> <xs:complexType name="Data"> <xs:sequence> <xs:element xmlns:q1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" minoccurs="0" name="data" nillable="true" type="q1:ArrayOfstring"> </xs:element> </xs:sequence> <xs:element name="Data" nillable="true" type="tns:Data"></xs:element></xs:complexType></xs:import></xs:schema>
However, just as the metadata representation isn't coupled to the service, the metadata representation also isn't coupled to the client. You can on the client generate proxies with any type for this collection that similarly can be serialized or deserialized to an array. The mechanism for doing this with svcutil.exe is the /ct switch.
The /ct switch, which stands for collectionType, allows you to give a qualified type name that is used for collection data types when generating a proxy.
As an example, to get back to the original collection class used by the server, the proxy would need to be constructed using /ct:System.Collections.Generic.List`1 as the option passed to svcutil.exe. However, you could leave the proxy using arrays or provide a different collection class such as /ct:System.Collections.ObjectModel.Collection`1 and with any of these configurations the proxy would be able to exchange messages with the server.
Next time: Setting the Configuration Name
After the first announcement for the WCF Security Guidance Project, the amount of content has grown tremendously. Here's a summary of what's new over the last month.
Seven new application scenarios:
More than eighty annotated guidelines.
Six new how-to guides:
Answers to more than one hundred security questions.
Why does a data contract with private or internal members generate a proxy with public fields?
The obvious answer is that the representation for data contracts doesn't contain information about member visibility but that just leads to the question of why the information isn't preserved by the representation.
If we take a data contract that contains both public and private members,
[DataContract]class Data{ [DataMember] public int i; [DataMember] private string s;}
Then, the type representation used to generate a proxy is based on an XML schema.
<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/" elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="Data"> <xs:sequence> <xs:element minOccurs="0" name="i" type="xs:int" /> <xs:element minOccurs="0" name="s" nillable="true" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:element name="Data" nillable="true" type="tns:Data" /></xs:schema>
A schema is a type system that is independent of the type system used by the proxy and has no concept of member visibility. However, by saying that a member is part of the data contract, you've effectively said that that member is as intrinsically part of the data as any other public facing member. Member visibility is a facet of information hiding to suppress details that are not needed by other parts of the system, but a data member by definition is needed by other parts of the system. Therefore, regardless of how one of the parties has chosen to represent that data, it's more likely than not that the other side will need to manipulate that data to uphold the contract.
Next time: Generating Types with Lists
Today wraps up the series on detailed messaging changes in Orcas. You can get the whole series here as well as the previous high-level overview of new Orcas features I did.
Now, let's go on with the list. I've got one last feature to cover and then some of the more notable bug fixes that were reported by customers. If you need one of the bug fixes, you can get them by either installing Orcas or the .NET framework 3.0 service pack.
Next time: Private Data Members
At their user conference in San Francisco yesterday, TIBCO announced two integration initiatives to bring the TIBCO and Microsoft platforms closer together.