Monday, August 11, 2008 - Posts

• Visual Studio 2008 and .NET Framework 3.5 SP1 RTM Today!

  Today, we’re proud to announce the availability of the “gold” bits of VS 2008 SP1 and .NET 3.5 SP1 . We think this is a great update to our VS2008 and 3.5 releases that is well worth checking out. I blogged about the new features for Service developers back in May when we shipped the beta, so I won’t repeat them all here… but here is a recap of some of the highlights: On the Web front, we’ve built on the support for REST and AtomPub with enhancements to UriTemplate and support for AtomPub ServiceDocuments, respectively. And of course we’ve built Data Services (also known as “Astoria”) – a WCF service that exposes any SQL database (or LINQ provider) as a set of AtomPub resources. Finally, we’ve enhanced our support for partial trust scenarios with the ability to write to the event log, which helps debugging and diagnosability. The DataContractSerializer has some nice enhancements, including support for “POCO” (plain-old C# objects) contracts, which allows using this serializer without requiring you to decorate members [DataMember]. This is more than just a convenience – sometimes you don’t control the class you are trying to serialize (for example, it gets generated by a tool which doesn’t slap on the [DataMember] attribute), and this feature now makes it possible to use the DataContractSerializer with those types. We also added support for serializing object graphs in a way that is more interoperable with JAX-WS, and support for ADO.NET Entity Framework types in DataContracts. There’s also some good perf work in this release. If you’re running in IIS7 integrated mode, we’ve seen 5-10X scalability increases for WCF services via a new asynchronous implementation of our HttpHandler/Module (more details on Wenlong's blog ). Also, the Workflow designer can handle significantly bigger workflows and loads up much faster. Finally, we have some nice improvements in our tools. Our Test Client now runs standalone (in addition to running inside Visual Studio). We also added support for a bunch of new types including Nullable types, Dictionaries, MessageContracts, and XmlSerializer contracts. The tool also supports WS-RM sessions and allows you to customize the config file for the tool itself, so you can save some common customizations instead of having to recreate them. The support for XmlSerializer-style contracts opens up some interesting new scenarios for the tool… My favorite is pointing it at a public web service to discover its contract, and use the tool kind of Read More... Posted Monday, August 11, 2008 3:46 PM from OhmBlog | 1 Comments Filed under: Indigo AKA WCF;Web Services/XML;Workflow

• Getting Rid of Namespaces

  How do I write a contract for a wrapped message in the default namespace? I've written a quick sample to demonstrate what happens when you write the contract without taking any namespaces into account. [ServiceContract] public interface IService { [OperationContract] [WebInvoke(BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "/" )] void ProcessRequest( string data); } public class Service : IService { public void ProcessRequest( string data) { Console.WriteLine(OperationContext.Current.RequestContext.RequestMessage); } } class Program { static void Main( string [] args) { string address = "http://localhost:8000/" ; WebServiceHost host = new WebServiceHost( typeof (Service), new Uri(address)); host.Open(); ChannelFactory<IService> factory = new ChannelFactory<IService>( new WebHttpBinding()); factory.Open(); IService proxy = factory.CreateChannel( new EndpointAddress(address)); using ( new OperationContextScope((IContextChannel)proxy)) { OperationContext.Current.OutgoingMessageHeaders.To = new Uri(address); proxy.ProcessRequest( "data" ); } factory.Close(); host.Close(); Console.ReadLine(); } } Running the sample reveals that the message wrapper gets an unpleasant namespace instead of the default namespace. < ProcessRequest xmlns ="http://tempuri.org/" > < data > data </ data > </ ProcessRequest > By looking at the metadata, you could figure out where this namespace was coming from using the custom namespace sample I published earlier. In this case the problem is with the operation wrapper, which comes from the service contract. Setting the service contract to have a namespace of "" gets us the desired default namespace. Next time: Using Faults with Untyped Messages Read More... Posted Monday, August 11, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Service Model, Contracts