The reference source server for debugging into framework code is underway with propagating a new release of source code for Orcas SP1. The following components should already be available for debugging into updated source.
An installable download should be available after all of the components have been updated on the server.
There are still no assigned times yet, but I noticed that the PDC schedule builder is working better and is starting to have a lot more data so you can use it to track the sessions that you're interested in seeing. There also aren't any level indicators yet, but I noticed that quite a few of the sessions are tagged with notes such as Introductory, Intermediate, Advanced, and Expert. I have no idea if they are based on data from the presenter or if they were picked just based on the session titles but they serve as a rough guide.
And finally, I don't know how the holiday Monday will affect the monthly session update. If it comes out tonight, I'll do an update on it tomorrow. Otherwise, I'll have it on Tuesday at the earliest as I'll be taking Monday off.
I was working on some services with recursive data structures when I noticed that there were a few cases where I would get crashes while trying to generate proxy classes. The problems seemed to be around types that were a sequence of instances of themselves. That looks like this:
<xs:schema xmlns:tns="http://test" targetNamespace="http://test" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="CircularList"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="CircularList" nillable="true" type="tns:CircularList" /> </xs:sequence> </xs:complexType> <xs:element name="CircularList" nillable="true" type="tns:CircularList" /></xs:schema>
When using message contracts I was able to fix the problem by moving the minOccurs and maxOccurs from the element to the containing sequence. This didn't change the meaning of the type when I examined the proxy.
With data contracts, trying the same fix caused proxy generation to go into an infinite loop rather than crash, but that's not much of an improvement. The data contract serializer worked best when I defined an intermediate type to represent the sequence rather than directly including the list type in itself.
These all look like bugs with schema analysis.
Next time: Waiting for Ready Channels
Robert Bell wrote an article a few weeks ago discussing how to achieve interoperability between a Silverlight application and a Java application. In the article Robert covers interoperability when building SOAP services, REST services, and RSS services. Note that this description is targeted at the Beta 2 release of Silverlight 2, so there may be a few more features and tricks at your disposal in the final release.
How can I find the pipe object on the system created by a named pipe binding?
The simplest way to find the named pipe is to use a tool like Process Explorer to examine your running executable. If you look inside a client or service that has the named pipe open, then you'll see a file handle that looks like this:
\Device\NamedPipe\f422aed9-6058-4bab-90b1-fe856bdcbd80
The unique identifier at the end will be different on your machine, and in fact, will be different every time you run the program. The named pipe handle may only exist while you've got the pipe open, so it's typically easier to find the pipe from the listener side than the client side.
If you're not sure that the named pipe you're looking at is the pipe created by WCF, then you can typically tell by the security properties since WCF has a particular configuration it uses. For a WCF named pipe, everyone will have permission to Synchronize, Query State, or Modify State on the pipe, while Network users will specifically be denied access to the pipe.
Next time: Avoiding Infinite Schema Chains
I frequently get asked how to add a header to every outgoing request so I wrote up a quick reusable approach. This adds some extension methods to the IContextChannel class for working with auto-added headers. The headers are stored between calls in an IExtension.
public static class AutoHeaderExtension{ class AutoHeaderContextExtension : Dictionary<XName, MessageHeader>, IExtension<IContextChannel> { public void Attach(IContextChannel owner) { } public void Detach(IContextChannel owner) { } } public static void AddAutoHeader(this IContextChannel proxy, string name, string ns, object value) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension == null) { extension = new AutoHeaderContextExtension(); proxy.Extensions.Add(extension); } extension[XName.Get(name, ns)] = MessageHeader.CreateHeader(name, ns, value); } public static IEnumerable<MessageHeader> GetAutoHeaders(this IContextChannel proxy) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension == null) { return Enumerable.Empty<MessageHeader>(); } return extension.Values; } public static void RemoveAutoHeader(this IContextChannel proxy, string name, string ns) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension != null) { extension.Remove(XName.Get(name, ns)); } }}
If you combine that with a message inspector that adds the headers on to each message, then you get a collection of headers that are added to every outgoing request.
public class AutoHeaderMessageInspectorBehavior : IEndpointBehavior{ class AutoHeaderMessageInspector : IClientMessageInspector { public void AfterReceiveReply(ref Message reply, object correlationState) { } public object BeforeSendRequest(ref Message request, IClientChannel channel) { foreach (MessageHeader header in channel.GetAutoHeaders()) { request.Headers.Add(header); } return null; } } public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { clientRuntime.MessageInspectors.Add(new AutoHeaderMessageInspector()); } public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { } public void Validate(ServiceEndpoint endpoint) { }}
Here's an example using this extension.
[ServiceContract]public interface IService{ [OperationContract(Action="*")] void Test();}public class Service : IService{ public void Test() { Console.WriteLine(OperationContext.Current.RequestContext.RequestMessage); }}class Program{ static void Main(string[] args) { string address = "http://localhost:8000/"; Binding binding = new BasicHttpBinding(); ServiceHost host = new ServiceHost(typeof(Service), new Uri(address)); host.AddServiceEndpoint(typeof(IService), binding, ""); host.Open(); ChannelFactory<IService> factory = new ChannelFactory<IService>(binding); factory.Endpoint.Behaviors.Add(new AutoHeaderMessageInspectorBehavior()); factory.Open(); IService proxy = factory.CreateChannel(new EndpointAddress(address)); proxy.Test(); ((IContextChannel)proxy).AddAutoHeader("TestHeader1", "http://test", "test1"); proxy.Test(); ((IContextChannel)proxy).AddAutoHeader("TestHeader2", "http://test", "test2"); proxy.Test(); proxy.Test(); ((IContextChannel)proxy).RemoveAutoHeader("TestHeader1", "http://test"); proxy.Test(); factory.Close(); host.Close(); Console.ReadLine(); }}
Next time: Pipe Properties
Patrick Smacchia has done some analysis on SP1 using the NDepend tool to compare different versions of assemblies. This is an interesting way to understand the large, standalone changes that we did, such as the new syndication features, but there's no easy way to distinguish whether individual changes in methods are due to fixing bugs, improving performance, or adding new features. For example, some of the serialization changes are easy to spot because they touch many methods with distinguishing names while other changes are more subtle. The work on performance is almost invisible unless you know where to look.
If there's interest, I may try to put together a list of notable WCF changes for SP1 in a few days that goes into more detail than the release announcement did.
Brad Abrams and Krzysztof Cwalina have got an early access version of the Framework Design Guidelines, 2nd Edition available for purchase, along with preordering for the final version. The Framework Design Guidelines cover the common idioms and patterns that should be followed when using or writing libraries for the .NET Framework. The 2nd Edition primarily focuses on adding coverage of features that are new in Orcas, although some of the original material is updated with new annotations as well. The final version is expected to be out by the end of the year.
How do I deliver content from a WCF service as part of a web page?
Web page content in this case typically refers to HTML, images, or other data that is directly consumed by the web browser rather than an application running in the web browser. There are a few things you need to do to make your web service serve up content in a way that's indistinguishable from an ordinary web server. I'll serve up a static image at a fixed location for this example but you can get as fancy as you'd like.
The first thing you need is the right contract. The initial page load is ordinarily retrieved using the HTTP GET verb rather than the HTTP POST verb assumed by web services. I'll set that up as part of my contract using the WebGet attribute to set the verb and a URI template to set the address.
[ServiceContract]public interface IService{ [OperationContract] [WebGet(UriTemplate = "/image")] Stream GetImage();}
The second thing you need is the right content type. Although web browsers can try to autodetect content, you should specify the content type if it is known. This allows the web browser to process the content correctly inline.
public class Service : IService{ public Stream GetImage() { WebOperationContext.Current.OutgoingResponse.ContentType = "image/jpeg"; return new FileStream("c:\\test.jpg", FileMode.Open, FileAccess.Read); }}
Finally, you may notice that while I've done everything needed in the service implementation to enable streaming, content can only be streamed if the binding supports this as well. When using WebServiceHost, the default bindings do not support streamed content. This may be hard to spot because the typical files are small and a test program running on the same machine completes the transfers before streaming would make a difference.
I've wrapped the service implementation in this example to intentionally slow down the transfer to make the difference more apparent. The following code demonstrates enabling streaming on the binding. You can change the transfer mode back to Buffered to observe the difference. Streaming requires support in the receiving application as well to make a difference. Using a large, progressive encoded image will demonstrate this.
using System;using System.IO;using System.ServiceModel;using System.ServiceModel.Web;using System.Threading;public class SlowStream : Stream{ Stream innerStream; public SlowStream(Stream innerStream) { this.innerStream = innerStream; } public override bool CanRead { get { return innerStream.CanRead; } } public override bool CanSeek { get { return false; } } public override bool CanWrite { get { return false; } } public override void Flush() { throw new NotImplementedException(); } public override long Length { get { return innerStream.Length; } } public override long Position { get { return innerStream.Position; } set { throw new NotImplementedException(); } } public override int Read(byte[] buffer, int offset, int count) { Thread.Sleep(100); return innerStream.Read(buffer, offset, count > 1024 ? 1024 : count); } public override long Seek(long offset, SeekOrigin origin) { throw new NotImplementedException(); } public override void SetLength(long value) { throw new NotImplementedException(); } public override void Write(byte[] buffer, int offset, int count) { throw new NotImplementedException(); }}[ServiceContract]public interface IService{ [OperationContract] [WebGet(UriTemplate = "/image")] Stream GetImage();}public class Service : IService{ public Stream GetImage() { WebOperationContext.Current.OutgoingResponse.ContentType = "image/jpeg"; return new SlowStream(new FileStream("c:\\test.jpg", FileMode.Open, FileAccess.Read)); }}class Program{ static void Main(string[] args) { string address = "http://localhost:8000/"; WebServiceHost host = new WebServiceHost(typeof(Service), new Uri(address)); WebHttpBinding binding = new WebHttpBinding(); binding.TransferMode = TransferMode.StreamedResponse; host.AddServiceEndpoint(typeof(IService), binding, ""); host.Open(); Console.ReadLine(); }}
Next time: AutoHeader Extension
When using a typed contract, incoming messages on the server are shredded on your behalf to be turned into method calls and parameters. Ordinarily, the particular method call selected for an application messages will have the same parameterized contract as the message. This allows the transformation between messages and parameters to be made with a high degree of fidelity. However, operations also permit fault responses in addition to the normal application response.
The parameterized fault contract is going to look nothing like the standard application contract. Therefore, there's really no transformation that will take you from the fault message to the same parameterized contract in a way that makes any sense. The response that comes back from the server is unrepresentable using the standard data structure that the application is expecting to receive for an application response. This is why with a typed contract fault messages have to be expressed as an exceptional condition. Exceptions tend to transform the message with a much lower fidelity to the original content.
With an untyped contract, incoming messages on the server are not shredded on your behalf but rather preserved in their entirety. You can think about this as performing the transformation between messages and parameters with perfect fidelity since the parameter is equal to the message. Similarly, any message response, whether it's a fault response or a normal application response, is also going to be representable with perfect fidelity. Both types of responses have the same format with an untyped contract so the application can handle them equally well. This is why with an untyped contract fault messages are preserved as messages. One of the major reasons for using untyped contracts is to have great fidelity with the wire. It wouldn't make sense to force the application to lose that fidelity for a certain class of messages.
If you choose to in your application though, you can still run the same exception machinery. For details, read some of the past articles on creating and consuming faults.
Next time: Streaming Web Content
One last bit of Orcas news for this week. PluralSight will be providing a weekly screencast throughout the year on using WF and WCF. They're focusing on the capabilities of Orcas but will be starting from the basics so you don't need to have any background going into these. The first screencast is by Aaron Skonnard and covers contracts and creating services.
With Orcas SP1 having come out, the training kit has been updated for SP1 as well, along with new and updated labs and presentations in several of the area. The training kit collects together different presentations, hands on labs, demos, and whitepapers that cover the features in Orcas.
The first service pack for .NET Framework 3.5 came out yesterday, primarily focusing on fixing bugs and performance issues. There are some new features, notably around improving the support for REST based services and around serialization.
Here are some known issues related to WCF in this release.
Authentication failure when Windows authentication is used over certain transports
WCF now specifies a default domain target name in Windows authentication scenarios. When upgrading, the client may see an authentication failure when the following conditions exist:
An example of the authentication failure is "System.ComponentModel.Win32Exception The target principal name is incorrect"
To resolve this issue:
The client must override the default domain target name by specifying the Service Principal Name of the server in the SpnEndpointIdentity class, or User Principal Name in the UpnEndpointIdentity class, and then passing the identity to the EndpointAddress. If the client uses Https and requires X509CertificateEndpointIdentity, the client must still specify the SpnEndpointIdentity or UpnEndpointIdentity. The X509CertificateEndpointIdentity enables validation of thumbprints. The client can work around the loss of validation by registering for the System.Net.ServicePointManager.ServerCertificateValidationCallback and performing thumbprint validation manually.
Breaking changes in the SspiNegotiatedOverTransport authentication mode
When WSHttpBinding, WS2007HttpBinding, or NetTcpBinding is used with SecurityMode = TransportWithMessageCredential and a client credential type of Windows, clients that previously authenticated to a service by using NTLM will now fail to authenticate, with the following error:
"System.ComponentModel.Win32Exception: Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'host/<hostname>'. If the server is running in a service account (Network Service for example), specify the account's ServicePrincipalName as the identity in the EndpointAddress for the server. If the server is running in a user account, specify the account's UserPrincipalName as the identity in the EndpointAddress for the server."
The error appears when the service is running on an account that has an identity other than 'host/<hostname>'. This issue also applies to CustomBindings, which specify the SspiNegotiatedOverTransport authentication mode.
If possible, clients should be updated by using a UPN or SPN endpoint identity that specifies the identity of the service so that Kerberos authentication occurs. The following configuration snippet shows how to do this in the UPN case; the SPN case is similar, but the <servicePrincipalName> element is used instead.
<system.serviceModel> <client> <endpoint> <identity> <userPrincipalName value="user@domain" /> </identity> </endpoint> </client></system.serviceModel>
Additionally, clients that use NetTcpBinding or CustomBindings, with SspiNegotiatedOverTransport specified in the stack over SslStreamSecurityBindingElement, must specify a custom IdentityVerifier in the code to perform the CN check of the service's certificate. The following code snippets show how to do this and provide a starting point for IdentityVerifier implementations.
NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.TransportWithMessageCredential);CustomBinding customBinding = new CustomBinding(tcpBinding.CreateBindingElements());SslStreamSecurityBindingElement ssl = customBinding.Elements.Find<SslStreamSecurityBindingElement>();ssl.IdentityVerifier = new DnsIdentityVerifier(new DnsEndpointIdentity("DNS.name.of.service.certificate"));
public class DnsIdentityVerifier : IdentityVerifier{ DnsEndpointIdentity _expectedIdentity; public DnsIdentityVerifier(DnsEndpointIdentity expectedIdentity) { _expectedIdentity = expectedIdentity; } public override bool CheckAccess(EndpointIdentity identity, AuthorizationContext authContext) { List<Claim> dnsClaims = new List<Claim>(); foreach (ClaimSet claimSet in authContext.ClaimSets) { foreach (Claim claim in claimSet) { if (ClaimTypes.Dns == claim.ClaimType) { dnsClaims.Add(claim); } } } if (1 != dnsClaims.Count) { throw new InvalidOperationException(String.Format("Found {0} DNS claims in authorization context.", dnsClaims.Count)); } return String.Equals((string)_expectedIdentity.IdentityClaim.Resource, (string)dnsClaims[0].Resource, StringComparison.OrdinalIgnoreCase); } public override bool TryGetIdentity(EndpointAddress reference, out EndpointIdentity identity) { identity = _expectedIdentity; return true; }}
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
There are online resources from this year's TechEd conferences available through MSDN. A limited number of keynote and breakout sessions are on the site, but you do get other videos such as interviews, panel discussions, lunch sessions, and the like that go beyond slide shows.
How do I force propagation of changes to information about a certificate revocation list after an update?
A service is going to have several kinds of caching around the information that links the certificate to revocation information.
The first kind of caching is based on the revocation mode of the certificate. A revocation mode of NoCheck disables checking on the certificate while a revocation mode of Offline directs checking to use a cached certificate revocation list. A revocation mode of Online gets the freshest data.
The second kind of caching is at the service process. Information is stored in memory as long as the process continues to run to reduce the number of active checks required. This memory cache is cleared when the process restarts.
The third kind of caching is at the machine. Information is cached by the machine for a limited time to again reduce the number of active checks required. The machine cache can be viewed by running "certutil -urlcache" and the same command is used to delete or force updating of specific cache entries.
Next time: Getting Rid of Namespaces
If you've been following along, I have mentioned the WCF security guide project being worked on in the patterns and practices team a few times now. After months of drafts and betas, the complete guide is now ready for official release.
The WCF security guide is available as a free download.
It's bad practice to use system types when defining an operation contract. A system type is often a complex composition of primitive types that has no direct analog in other implementations. By using a system type, you bind your service to the particular implementation used by that type, which effectively ends any chance of having an easily interoperable service.
For example, a contract containing an IPAddress seems innocuous.
[OperationContract]string LookupHostName(IPAddress address);
However, that reference translates into a significantly sized chunk of metadata for defining the IPAddress type.
<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/System.Net" elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/System.Net" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="http://schemas.datacontract.org/2004/07/System.Net.Sockets" /> <xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays" /> <xs:complexType name="IPAddress"> <xs:sequence> <xs:element name="m_Address" type="xs:long" /> <xs:element xmlns:q1="http://schemas.datacontract.org/2004/07/System.Net.Sockets" name="m_Family" type="q1:AddressFamily" /> <xs:element name="m_HashCode" type="xs:int" /> <xs:element xmlns:q2="http://schemas.microsoft.com/2003/10/Serialization/Arrays" name="m_Numbers" nillable="true" type="q2:ArrayOfunsignedShort" /> <xs:element name="m_ScopeId" type="xs:long" /> </xs:sequence> </xs:complexType> <xs:element name="IPAddress" nillable="true" type="tns:IPAddress" /></xs:schema>
Notice the inclusion of System.Net.Sockets.AddressFamily. This schema is only the tip of the iceberg. It continues on and becomes much, much worse.
Nevertheless, there are times when you can accept putting interoperability aside and have a reason to bind your service to a system type. The metadata still leaves you with the problem of generating a working proxy. Although some system types are recognized and filtered out, other types slip through and will lead to compilation errors due to conflicting type definitions.
The standard referencing mechanism of svcutil works with system types as well as your types. You just need to find and point svcutil at the appropriate dll so that it can compute the types to exclude. Since IPAddress is defined in system.dll, if you wanted to resolve a conflict, you could use /r:%windir%\microsoft.net\framework\v2.0.50727\system.dll as a svcutil option to prevent duplicate type generation.
Next time: Certificate Revocation Cache
Fifty new PDC sessions showed up on Friday, including several touching on WCF and WF. Here is a selection along with some of the previously available sessions.
"Oslo:" Managing Software + Services Applications
Increasingly, applications will consist of services that run both on-premises and in the cloud. Learn how Microsoft is simplifying the deployment and management of Software + Services applications.
Hosting Workflows and Services in "Oslo"
"Oslo" builds on Windows Workflow (WF) and Windows Communication Foundation (WCF) to provide a feature-rich middle-tier execution and deployment environment. Learn about the architecture of "Oslo" and the features that simplify deployment, management, and troubleshooting of workflows and services.
"Oslo:" Customizing and Extending the Visual Design Experience
"Oslo" provides visual tools for writing data-driven applications and services. Learn how to provide a great experience over domain-specific schemas, and explore the basic user model, data-driven viewer construction, user-defined queries, and custom commands. See how the design experience itself is an "Oslo" application and is driven by content stored in the "Oslo" repository.
A Lap around "Oslo"
"Oslo" is the family of new technologies that enable data-driven development and execution of services and applications. Come and learn how to capture all aspects of an application schematized in the "Oslo" repository and use "Oslo" directly to drive the execution of deployed applications.
"Oslo:" The Language
"Oslo" provides a language for creating schemas, queries, views, and values. Learn the key features of the language, including its type system, instance construction, and query. Understand supporting runtime features such as dynamic construction and compilation, SQL generation, and deployment. Learn to author content for the "Oslo" repository and understand how to programmatically construct and process the content.
"Oslo:" Repository and Schemas
"Oslo" uses schematized data stored in the "Oslo" repository to drive the development and execution of applications and services. Tour the schemas and see how user-defined content can be created and related to them. Learn how to utilize platform schemas, such as worflow, services, and hosting. Also, learn how to extend the repository and how to use repository-extended SQL database services to support critical lifecycle capabilities such as versioning, security, and deployment.
Workflow Services: Orchestrating Services and Business Processes
See how simple it is to use cloud-based workflow to perform complex orchestration across on-premises and cloud services. Also, learn how to run processes in the cloud while simplifying your system and increasing reliability in a distributed environment.
Extending Windows Workflow Foundation v.Next with Custom Activities
Windows Workflow Foundation (WF) coordinates and manages individual units of work, encapsulated into activities. The next version of WF comes with a library of activities, including Database and PowerShell. Learn how to extend this library by encapsulating your own APIs with custom activities. See how to compose those basic activities into higher level units using rules, flowchart, or state machine control flow styles. Learn how to extend beyond WF control styles by building your own. Learn how to customize and re-host the workflow authoring experience using the new WF designer framework.
Workflow Services
This session covers significant enhancements in Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) to deal with the ever increasing complexity of communication patterns. Learn how to use WCF to correlate messages to service instances using transport, context, and application payloads. Learn to use the new WF messaging activities to model rich protocols and how to use WCF as a rich default host for your workflows and expand the reach of WF with features like distributed compensation. See how service definition in XAML completes the union of WF and WCF with a unified authoring experience that dramatically simplifies configuration and is fully integrated with Microsoft Internet Information Services activation and deployment.
Windows Workflow Foundation: Futures
The next version of Windows Workflow Foundation provides a rich platform for declarative programming. Learn about the new data flow model, rich composition model, and control flow styles, including: parallel execution, state machine, and flowchart. See how easy it is to build workflows with the new Microsoft Visual Studio workflow designer and the new activities library, including activities for SharePoint and PowerShell. Hear how Workflow Foundation integrates with other declarative frameworks like Windows Presentation Foundation and Windows Communication Foundation.
The complete list of sessions is available at the PDC website.
I hate the default search service that comes with http://blogs.msdn.com. It never seems to pick out relevant articles or find what I'm looking for. I've put a quick replacement in the news section to try out. Let me know if you think it's worth having and I'll pitch the current search box to put this in.
The translation service is more of a toy. Again, let me know if you think it's worth keeping or is a waste of space.