The .NET Endpoint

WCF Interoperability Highlighted at PDC and ApacheCon

KentBrown — Sat, 21 Nov 2009 04:12:52 GMT

At PDC this week we had a booth to showcase the interoperability that WCF gives you through its support for the WS-* protocols. In particular, we highlighted an Apache incubator project called Stonehenge.

At Stonehenge we work together with a growing list of WS-* vendors (WSO2, Sun, SpringSource, and soon Progress) to build samples and prove out interoperability between the stacks.

At the PDC booth we had a demo of the soon to be released ’M2’ version of the StockTrader Sample application. Check out the Channel 9 video here.

We also talked about Stonehenge at the ApachecCon conference in Oakland a couple of weeks ago where Apache celebrated their 10 year anniversary. If you are in the mood for some geek entertainment you might want to see this from the Lightening Talks.

If you are doing cross-platform interop with WCF, I would encourage you to get involved in Stonehenge. You can contribute by suggesting important test scenarios and/or helping build and test one of the samples. To get started go to the project wiki: Apache Stonehenge and subscribe to the dev email list.

To learn about other interop activities at PDC check out the Interoperability Team Blog.

Claims-based security with Windows Identity Foundation (WIF) and WCF

KentBrown — Sat, 21 Nov 2009 00:57:20 GMT

There is a great article in MSDN Magazine this month by Michele Bustamante on using WIF to implement claims-based security in WCF Services: http://msdn.microsoft.com/en-us/magazine/ee335707.aspx.

It’s gets to the right level of detail to make it crystal clear. Spend all weekend reading the docs, or spend an hour with Michele’s article? Hmmm… easy choice!

The WCF services ecosystem

.NET Connected Framework Team — Thu, 19 Nov 2009 00:15:00 GMT

At PDC, Microsoft announced the rebranding of ADO.NET Data Services as WCF Data Services and of .NET RIA Services as WCF RIA Services. This is not just a product marketing decision – it is also a technical commitment to provide a coherent and unified services story on .NET.

The current implementations of ADO.NET Data Services (previously known as Codename ‘Astoria’) and .NET RIA Services (previously known as Codename ‘Alexandria’) are based on WCF. In fact, they are WCF services. Moving forward, future releases will align the technologies to allow features of the technologies to be used in a mix and match manner as appropriate. We are currently in early stages of investigation around potential areas of deeper integration such enabling WCF RIA services to support an appropriate subset of ADO.NET Data Service’s Open Data protocol (OData); enabling validation features that are currently only available in WCF RIA Services in other flavors of WCF services as well etc.

By unifying these services offerings on top of WCF, we are maximizing developer knowledge transfer and skill reuse in the short term and the long term. For the WCF RIA Services developer, the developer does not need to know all aspects of WCF to get their service up and running. However, if they want to add a WCF behavior or take advantage of the rich extensibility of WCF to their WCF RIA Service, they can choose to do so in a fashion that takes advantage of the unified communications programming model that is WCF.

Thus, as a result of this alignment, .NET will offer several different flavors of WCF services (listed below) that you can choose from based on your particular needs. The important thing to remember is these options will all build on the underlying WCF architecture. As such these are not binary choices – providing the .NET service developer with a choice among three different entry points into a single distributed programming framework, rather than a choice among three different programming options. We expect many applications will leverage multiple models for building out their applications and their developer's knowledge will easily transfer from one model to the other.

· WCF Core Services – Allows full flexibility for building operation-centric services. This includes industry standard interop, as well as channel and host plug-ability. Use this for operation-based services which need to do things such as interop with Java, be consumed by multiple clients, flow transactions, use message based security, perform advanced messaging patterns like duplex, use transports or channels in addition to HTTP, or host in processes outside of IIS.

· WCF WebHttp/AJAX Services – Is best when you are exposing operation-centric HTTP services to be deployed at web scale or are building a RESTful service and want full control over the URI/format/protocol.

· WCF Data Services – Including a rich implementation of OData for .NET, Data Services are best when you are exposing your data model and associated logic through a RESTful interface

· WCF Workflow Services – Is best for long running, durable operations or where the specification and enforcement of operation sequencing is important

· WCF RIA Services – is best for building an end-to-end Silverlight application

If you want to learn more about the different WCF services at PDC please check out the following sessions:

FT13 What’s New for Windows Communication Foundation
FT55 Developing REST Applications with the .NET Framework
CL06 Networking and Web Services in Silverlight
CL07 Mastering Microsoft .NET RIA Services
CL21 Building Amazing Business Applications with Microsoft Silverlight and Microsoft .NET RIA Services
FT10 Evolving ADO.NET Entity Framework in .NET 4 and Beyond
FT12 ADO.NET Data Services: What’s new with the RESTful data services framework

Thanks, and looking forward to your feedback!

New Web Services features in Silverlight 4 Beta

.NET Connected Framework Team — Wed, 18 Nov 2009 18:50:00 GMT

Cross-posted from the Silverlight Web Services Team Blog.

This morning at PDC ’09 ScottGu just announced the availability of Silverlight 4 Beta. Later on today I am going on to present the latest improvements around networking and web services and I’ll link to the full talk as soon as it is available online. In this post I’ll provide a quick summary of today’s announcements, with more detail to follow.

On the high level, we are announcing an exciting alignment between the different web services stacks in Silverlight. ADO.NET Data Services and .NET RIA Services are being rebranded as WCF Data Services and WCF RIA Services to reflect the fact that both technologies are being built out as programming models on top of WCF. In a way, this is not really major news; to you as a developer, pretty much everything stays the same, and you can continue using your favorite technology, whether it is straight WCF, or WCF RIA Services or WCF Data Services.

RIA Services and Data Services give you productive patterns for specific kinds of services and applications, hiding away some of the complexity of using WCF directly. The power of WCF is still there for you under the covers, if you need to modify some setting to your liking.

Specifically within the core WCF model, Silverlight 4 Beta has support for a brand new binding: NetTcp. This binding lets Silverlight talk to WCF services using a high-performance TCP pipe, using a duplex message pattern. In Silverlight, the binding is built on top of the sockets support that’s already there since Silverlight 2, so we inherit the security requirements of the Silverlight sockets API. More specifically, the service needs to be hosted in a given port range (4502 – 4534) and needs to expose a policy responder on port 943. One more thing to be aware of is that the security support and the streamed programming model for NetTcp available in WCF on the desktop framework are not available in Silverlight 4 Beta.

We’ll have a lot more content for you coming up soon, including the code from my talk today. If you want to get your hands dirty right away, go get the Silverlight 4 Beta, and then try the steps this how-to in our MSDN documentation, which has already been updated and show usage for NetTcp.

More information:

Thanks, and looking forward to your feedback!
Yavor Georgiev
Program Manager, Silverlight

Developing and Managing Services with Windows Server AppFabric

Cliff Simpkins — Tue, 17 Nov 2009 19:30:00 GMT

Today at PDC we are excited to introduce the Windows Server AppFabric Beta 1. AppFabric evolves the existing application server capabilities of Windows Server to make it easier to build, scale and manage Web and composite applications that run on Internet Information Services (IIS).

For Web applications, AppFabric provides caching capabilities to provide high-speed access, scale, and high availability to application data These capabilities are based on the technology previously code named “Velocity.”

For composite applications, AppFabric makes it easier to build and manage services built using Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF). These capabilities are based on the technology previously code named “Dublin.”

This first post provides an introduction to developing and managing WF services with AppFabric. Download the Beta 1 release at http://msdn.microsoft.com/appfabric.

Introduction to AppFabric

The benefits of having service-based applications, often referred to as SOA, to create systems based on autonomous services have been articulated in several MSDN articles. WCF is the technology that enables this, and in turn has been integrated with other Microsoft developer technologies such as ADO.NET Data Services, WCF rich Internet applications (RIA) services and WCF REST services. In .NET Framework 4, WCF has been deeply integrated with an improved WF runtime enabling you to build WCF services that are implemented with WF.

Whatever technology that you use to build and compose services together, you face challenges based on these questions:. “When building server applications what features of the platform can I take advantage of that light up my application and enable me to focus more on the business?” “Having built this application, where is the best place to test this, to run this in production, and how do I manage it?”

This post focuses on how Windows Server AppFabric, combined with the .NET Framework 4, addresses these challenges, with particular emphasis on WF services.

Developing WF Services

Depending on the architecture of your application, typically you build services focused on the middle tier. For example, ADO.NET Data Services are suited for the data access tier and can be composed together with other services in the middle tier. For an overview of WF services in .NET 4, read the Aaron’s overview of WCF in .NET 4 on MSDN. In the middle tier, WF services are an ideal technology, since they are strongly focused on using declarative approaches for composing services for your business. For additional reading on WCF Services, David Chappell’s ‘The Workflow Way’ provides an excellent introduction to the topic.

The key values that WF Services bring to service authoring are:

Long-running applications that wait for external input for activation such as messages, thereby using resources efficiently.
A single or sequential flow control programming model while handling the complexity of multiple async I/O calls. For example, by using a parallel activity in your WF Service you can coordinate multiple calls to other services allowing the WF runtime to take care of all the async message calls and marshaling the data back to your service.
Coordination of messages to workflow instances with the use of message correlation. WF Services in .NET Framework 4 provide content-based correlation that enables you to query the content of a message for unique information to identify the specific workflow instance the message relates to. This enables long-running scenarios being able to activate a specific workflow instance when clients send messages.
Consistent WCF and WF instrumentation integrated with Event Tracing for Windows (ETW). The WCF and WF runtimes now both emit ETW events for tracing and tracking to provide detailed monitoring and diagnostics. Using ETW provides greater performance, thereby having less impact on your applications.
An expressive set of workflow activities for authoring business process. Here the Flowchart activity is extremely powerful by enabling you to more closely match the typically graphical representation of a business process drawn using Visio, for example, with the implementation of the business in code using the Flowchart.
A simple extensibility model for workflow activities, enabling you to define your own library of business domain activities. These can be included into the Workflow Designer in Visual Studio 2010, enabling developers to more quickly build business WF services.

Hosting and Managing Services

Regardless of the technology used to build your service, where and how you run your services introduces a number of options. Today you can host your services in a process created by the Windows Process Activation service (WAS) in IIS, a Windows service or a self-hosted executable. This provides a mechanism for activating workflows, but is only one part of a broader hosting picture for providing a suitable environment to run your production applications. Typically there are other platform service requirements that as a developer you would like to take advantage of, such as application state storage (persistence), instrumentation for health monitoring, caching, and other capabilities that provide scalability and reliability to deployed applications. Windows Server as an application server today provides services you can take advantage of such as MSMQ for message queuing, and the event log for diagnostics.

Windows Server AppFabric builds on the application server capabilities in Windows Server to 1) host and manage your WCF and WF Services and 2) provide a distributed in-memory data cache. AppFabric provides a set of common services that your applications can take advantage of thereby allowing you as a developer to concentrate on building solutions that solve key business problems. These common services are focused on enhancing Windows Server’s WCF and WF Service hosting capabilities, and making it easier to manage these services. Additionally the distributed cache introduces rich scale-out capabilities for applications built using .NET Framework.

Persisting WF Services

The key scenarios this enables are;

Reliability – The ability to persist (save) workflow state and reliably resume workflow instances that have been idle for a defined time interval.
Availability – The recovery of saved workflow state when an application, process, or computer terminates unexpectedly.
Scalability – The ability to unload idle workflow instances from memory to efficiently use resources, the capability of retrying to load workflow instances when a message arrives on a different computer in the host farm, and gracefully handling retries when there is a lock on the instance.

Windows Server AppFabric provides a Windows service called the Workflow Management service (WMS) that manages instances in the persistence store. AppFabric can install a SQL Server persistence store for your WF Services which the WMS monitors to enable the scenarios above. AppFabric also supports other store solutions as well.

Monitoring

The key scenarios this enables are;

Health monitoring – How well is my app running? The ability to see expected healthy events occur within your service to know that it is still operational.
Troubleshooting – What has failed with my app? The ability to quickly diagnose failures within your service and either correct these or provide a developer with further detailed information.

Windows Server AppFabric provides a Windows service called the Event Collector service that captures health and failure events from your services and writes these to a SQL Server monitoring store, or another store built to leverage the pluggable AppFabric monitoring solution. This provides analytical data about your applications. You can either take advantage of rich UI tooling integrated into IIS Manager to view these events in the monitoring store, or build your own reporting using SQL Server Reporting Services or another data analysis solution, to view this data.

Process Hosting

The key scenarios this enables are:

Efficiently using computer resources by hosting services in the Windows Process Activation Service (WAS) in IIS. IIS and the WF runtime are deeply integrated. For example, if IIS decides to recycle a process due to memory constrains it will communicate with the WF Service to ensure that a graceful shutdown occurs, thereby allowing the service to be restarted in another process or on another computer by the WMS.
Auto-start to “warm-up” services hosted in IIS. When the computer starts, or when IIS starts, services can be pre-warmed, thereby reducing the latency on the first message.

By integrating the WF runtime deeply with the IIS/WAS process activation model, WF Services are ideally suited to being hosted in IIS/WAS and benefit from the rich hosting capabilities that IIS/WAS provide.

Distributed Caching

Distributed, service-oriented applications often require support for a large number of users, and high performance, throughput, and short response time. Services are increasingly moving “far away” from their underlying data stores and in many cases those data stores are “expensive” to access due to both technical and licensing costs. As a result, developers are increasingly forced to find alternatives to continually accessing the physical data store and often turn to caching to meet these challenges.

Windows Server AppFabric provides a distributed, in-memory, application cache for developing scalable, available, and high-performance applications. The caching capabilities fuse memory across multiple computers to give applications a single unified cache view that can be easily scaled-out by simply adding more computers on demand.

Some key caching features provided by Windows Server AppFabric include:

Caching any serializable CLR object and providing access through simple cache APIs
Enterprise scale: tens to hundreds of computers
Configurable to run as a service accessed over the network
Dynamic scale-out by adding new nodes
High availability through backup copies
Automatic load-balancing
Seamless integration with ASP.NET with an ASP.NET Session State Provider (better perf and scale and no more sticky routing!)
Integration with administration and monitoring tools such as Windows PowerShell, Event Tracing for Windows, and System Center.

Tooling

The tooling support for services in Windows Server AppFabric will be covered in more detail by future posts. Integrating tooling into IIS Manager provides a familiar management, control, and monitoring experience for the IT professional managing applications in a production environment or the developer troubleshooting deployed applications. In addition, AppFabric provides an extensive set of Windows PowerShell commands to enable you to script the capabilities in the UI.

Summary

This post describes the key benefits of building WF Services with Visual Studio 2010 and .NET Framework 4, and the benefits of hosting these in Windows Server and managing and scaling them with AppFabric.

The deep integration of WCF and WF provides an intuitive approach for developing declarative WF Services. WF Services make it possible to build long-running services that take advantage of the service coordination support provided by the workflow runtime, enabling you to use workflow to solve key business problems.

Windows Server AppFabric adds improved hosting capabilities to Windows Server to efficiently host all your WCF services, including WF Services. Additionally, AppFabric provides common services that help you as a developer build scalable Web and composite applications.

Downloads

You can download Visual Studio 2010 Beta 2 from the Visual Studio 2010 page on MSDN.

You can download Windows Server AppFabric Beta 1 from AppFabric page on MSDN.

PDC 2009: Developing REST Applications with the .NET Framework

.NET Connected Framework Team — Sun, 15 Nov 2009 21:38:00 GMT

Attending Microsoft PDC 2009? Then come hear Henrik Frystyk Nielsen's presentation on Developing REST Applications with the .NET Framework. The talk gives an overview of REST principles and why REST is becoming popular beyond traditional Web applications. Learn how to write applications that produce and consume RESTful services using the .NET Framework 4 and the improvements we have planned for future versions of the .NET Framework.

Common User Mistake in .NET 4: Mistyping the WF/WCF Service Configuration Name

Amadeo Casas Cuadrado — Mon, 09 Nov 2009 23:59:00 GMT

Today I am blogging about a common mistake that several developers have committed when using our latest .NET 4 bits. This user experience has its origin in the simplified configuration work developed in this upcoming version of the framework. I will summarize it with the following scenario.

Suppose you would like to write a new WCF Workflow Service Application using Visual Studio 2010. The configuration file that is added to your WF service when using this Visual Studio template makes use of the simplified configuration features in .NET 4, and thus it does not specify any <services> section to define endpoints for your WF service:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<behaviors>

<serviceBehaviors>

<behavior>

<serviceMetadata httpGetEnabled="true"/>

<serviceDebug includeExceptionDetailInFaults="false"/>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

</configuration>

Therefore, a set of default endpoints will be added to your service.

Now, imagine you would like to take advantage of the new WS-Discovery features and so make your WF service discoverable at runtime. In order to do that, you will need to add a ServiceDiscoveryBehavior and a DiscoveryEndpoint to your WF service. Since the most natural way to do this is via service configuration, you may want to expand the previous configuration to:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<services>

<service name="Service" behaviorConfiguration="ServiceBehaviors">

<endpoint name="Endpoint"

address=""

binding="basicHttpBinding"

contract="IService" />

<endpoint kind="udpDiscoveryEndpoint" />

</service>

</services>

<behaviors>

<serviceBehaviors>

<behavior name="ServiceBehaviors">

<serviceMetadata httpGetEnabled="true"/>

<serviceDebug includeExceptionDetailInFaults="false"/>

<serviceDiscovery />

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

</configuration>

The look of this service configuration probably reminds you of what you previously had to write to develop your web services in .NET 3.5 using WCF.

In order to make sure your service is ready to be deployed, you can press CTRL-F5, and then select Service1.xamlx. The following unexpected screen appears:

Why is the metadata publishing currently disabled? Looking at the configuration file, the service we just opened seems to have a ServiceMetadataBehavior with the httpGetEnabled property set to true. Why is this not working properly then?

If you take a closer look at the configuration file, you may realize the following: the default service name in the WCF Workflow Service Application template is Service1, and not Service. After changing the service name in the configuration file to be Service1, and pressing CTRL-F5 again, you will now be able to see the following:

The correct configuration has been added to your service!

What we have experienced here is the result of mistyping your service configuration name. When the service was opened, since no explicit configuration was found for it, a default set of endpoints with no default service behaviors was added to your service, and that is why the metadata publishing was not being enabled.

In .NET 3.5, the user experience was an InvalidOperationException thrown when a service was to be open to indicate that it “has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.” However, due to the simplified service configuration work in .NET 4, this will not be the case in the upcoming version of the framework, and users will need to make sure that the proper configuration (e.g., security, encoding, etc.) is correctly added to their services.

We are currently thinking on different ways to mitigate this. Adding design time configuration validation seems to be the best solution so far. Opinions?

New Beta 2 docs to help with code migration (from .NET 3.x and .NET 4 Beta 1)

Cliff Simpkins — Mon, 02 Nov 2009 16:06:08 GMT

Fresh on the heels of the beta 2 release of .NET 4/Visual Studio 2010, the team has been working on supplemental documentation to help you out with evaluation and adoption of WCF and WF in .NET 4.

Last week, two sets of documentation went live:

WF4 Migration Guidance: The WF team updated the documents to .NET Beta 2. We posted the documents up to the Downloads site mid last week.
B1->B2 Breaking Changes: The team also created a document that outlines the breaking changes between Beta 1 and Beta 2 of the .NET Framework 4.

We have a couple of new migration guidance documents in their final authoring/reviewing stages, and I hope to have them published out to the Downloads site by the time PDC comes around.

It’s exciting times having the second beta bits out, seeing what folks are doing with the new capabilities in .NET 4, and hearing from some customers that they are planning on taking advantage of the ”Go Live” License that is available with the Beta 2 release.

At any rate – happy Monday all – enjoy the docs and the new beta! If you’re heading to PDC and want to grab lunch with someone from the team while at the event, remember to drop me a note. BTW – I saw the shirts for the event last week – they look real nice!

Going to PDC? Want to meet the team?

Cliff Simpkins — Mon, 26 Oct 2009 15:57:44 GMT

3 weeks to go until PDC09; sessions are being reviewed, demos are being polished, schedules are being finalized, and the booth machines are being installed and packed up to go down to Los Angeles. Among the WCF, WF, and ‘Dublin’ group, we have about 15 people who will be down at PDC to chat with you about what is coming out with the release of .NET Framework 4 and to discuss some of the thoughts around what might come afterwards.

With 15 people at the event, that provides about 40-ish opportunities to chat with folks over lunch at the event. With PDC 3 weeks out, we would like to offer up about 30-40 spots with the folks heading to PDC09. Attending the event this year are folks from the PG who write and design WCF and WF, as well as the folks behind the ‘Dublin’ technologies. These are our architects, our program managers, our devs, and some folks from our business group.

If you have interest in catching up with one of us at the event…

Click the ‘Email’ link in the header above (white text; lower left hand portion of the header), or drop us an email to the endpoint alias (at - of course - microsoft.com)
Use the subject ‘Meet at PDC’
In the message/body, give us an idea of who you would like to catch up with (general role is fine; we’ll match folks up appropriately) and what you would like to discuss
Don’t forget to use/specify the best email to reach you at

Starting next week (week of Nov 2nd), we’ll start matching up the top 20 submissions to folks – and connect you up someone from the team. You can then coordinate lunch or coffee/tea or whatever in advance of the event. We’ll then fill up the remaining spots in the week before PDC.

Topics can range from the technical (feedback on the product, suggestions about what you would like to see done differently, a discussion on issues you’re currently having (and how a change we might make would make it easier)) to business (potential case study, compelling partner product, would like to learn how to better partner) to how to get more involved with authoring tutorials/whitepapers to feedback on what could be done differently on the web properties.

That being said, the team will also be heavily representing the technologies at PDC – in sessions, at the booths, and in the lounge. Even if you don’t get selected (or even submit) for a slot, we’d love to meet you and learn more about how you’re using (or would like to use) our technologies!

See you at PDC!
- Cliff

Client Profile in .NET 4

.NET Connected Framework Team — Wed, 21 Oct 2009 16:49:00 GMT

If you redistribute or require .NET 4 for your applications, you now have the option of installing .NET 4 Client Profile – a subset of the Framework intended for client applications.

Even better, Client Profile includes almost all pieces of Windows Workflow Foundation and Windows Communication Foundation! The few exceptions are assemblies oriented around web-hosting and WF3 components; I’ll get to these limitations later in this post. First, I’ll describe how you can start taking advantage of the Client Profile right away, and explain what’s included from the perspective of WF and WCF. For more details about other parts of the Client Profile, refer to this introductory post by Jossef Goldberg.

An overriding theme of our efforts has been to ensure that applications running in .NET 3 or 3.5 remain unaffected when switched over to running in .NET 4. Also, developers with projects building in .NET 3 or .NET 3.5 looking to move to .NET 4 are also not affected (and in some cases, only minimally affected) when rolling their projects forward.

So if Client Profile doesn’t interest you, relax – it’s a choice. Also, note that if you install .NET 4 Full, .NET 4 Client Profile is a fully contained subset of .NET 4 Full – so anything that’s a part of .NET 4 Client Profile is a part of .NET 4 Full.

To enable your application to target the Client Profile, you just need to change the “Target Framework” setting in your project like so:

Applications built and targeted this way will be able to run on machines that have the .NET 4 Client Profile installed, as well as those with .NET 4 Full. These projects will not let you build successfully when referencing classes that exist in only .NET 4 Full. On the other hand, applications targeted at .NET 4 Full will be unable to run on machines that only have the .NET 4 Client Profile installed on them, and you’ll get an error message directing you to download and install the Full framework:

To maximize what you could exploit in the Client Profile, we have refactored two assemblies. Each of these assemblies is now effectively split into two, one existing in the Client Profile and another that can be referenced from only .NET Full projects:

1. We’ve moved the JSON serialization classes from System.ServiceModel.Web.dll to System.Runtime.Serialization.dll. These serialization classes are being type-forwarded, so if you have any existing applications, they’ll continue to run just fine. System.Runtime.Serialization.dll will be installed with.NET 4 Client Profile, while System.ServiceModel.Web.dll will come with only .NET 4 Full.

2. We’ve moved and type-forwarded some classes related to hosting and activation from System.ServiceModel.dll to a new assembly, System.ServiceModel.Activation.dll. The former assembly is a part of .NET 4 Client Profile, while the latter is in .NET 4 Full.

Like I mentioned earlier, almost all assemblies we shipped with .NET 3 and .NET 3.5 are a part of the new .NET 4 Client Profile. In addition, almost all assemblies we are shipping for the first time in .NET 4 – including all WF4 assemblies – are a part of .NET 4 Client Profile. A comprehensive list of what’s in the Client Profile and what’s not will be published on MSDN.

So what’s not included in .NET 4 Client Profile? Here is a list of the main pieces, but this is not meant to be exhaustive. If your applications depend on anything from this set of assemblies, your projects should target .NET 4 Full:

- WF3 in .NET 4: This includes System.Workflow.Runtime.dll, System.Workflow.Activities.dll, System.Workflow.ComponentModel.dll, System.WorkflowServices.dll, and other related SQL files, performance counters, and tools.

- WF4 and WCF Hosting assemblies: System.Xaml.Hosting.dll, System.ServiceModel.WasHosting.dll, System.ServiceModel.Web.dll, System.ServiceModel.Activation.dll, WsatConfig.exe, and related tools

WF4 Changes Between Beta 1 and Beta 2

mwinkle — Tue, 20 Oct 2009 05:25:50 GMT

Hi all, I’m Matt Winkler, a PM on the WF team and occasional guest blogger here on the endpoint. I wanted to take a moment to highlight some of the interesting new things in WF4 in Beta 2. For more info on Beta 2, please check out this page.

The goals of a milestone like Beta 2 are two fold: 1.) to react to customer feedback that we’ve received on previous releases and 2.) stabilize and lock down the product to get ready to ship. While the items in #1 will be most visible, the team has done a lot of work stabilizing the product, and I feel pretty good about the Beta 2 release.

What are the big changes?

Activity Hierarchy Changes

For those of you who thought it was a little weird that we talked about writing activities, but having to derive (ultimately) from WorkflowElement in order to write them, this change is for you. Here’s a snapshot of the activity hierarchy in Beta 1:

We heard that feedback loud and clear and have made a few changes to how the activity hierarchy is factored:

The key changes are:

WorkflowElement goes away, and is replaced with Activity. Activity is the root type for all units of execution within the world of WF
Addition of ActivityWithResult which is the base for the Expression activities
Addition of AsyncCodeActivity. We got a lot of feedback that people liked what we were doing integrating asynchronous programming within activities but that there was still a fair amount of work in order to hook those up. AsyncCodeActivity is some nice sugar that makes it pretty easy to write an activity that takes advantage APIs that surface a Begin/End pair using the asynchronous programming model.

Runtime and Hosting

Validation has been improved for activity authors to write code within CacheMetadata() to validate the activity tree. CacheMetadata() is also the one stop shop for customizing behaviors that were previously spread through methods like OnGetArguments(), GetConstraints(), and GetActivities()

Make it easier to use ActivityAction by introducing DelegateArguments to pass data into and out of an ActivityAction. In Beta 1, this required using an object of type Variable<T> that was assigned to a property named Argument.

In the ‘under the hood’ category, the team has made improvements to Persistance, Durable timer and tracking which should provide a better runtime experience for the WF4 developer.

Last on the runtime front, dynamic update was a feature that had made its debut in Beta 1, but was removed again between Beta 1 and Beta 2 - and will not be present in the RTM release.

And, within hosting, WorkflowInstance was renamed to WorkflowApplication based on Beta 1 feedback from users.

Activities

The messaging activities are the key component for integrating WF and WCF together. Based on customer feedback we’ve made improvements to:

Correlation
- XPath can now be generated from ParametersContent
- CorrelationQuery and AdditionalCorrelations have been merged into a collection called CorrelationInitializers. Also, we’ve reduced the need for CorrelationHandles all over the place by improving the CorrelationScope and having an implicit correlation handle.
Parameters support
- We’ve removed the *Parameters activities and merged that into the Send and Receive activities. You can now use the Content property to support MessageContent (primarily for untyped Message or MessageContract ) and ParametersContent (which is for the more RPC style list of name value pairs).

We’ve also refactored the semantics around the error handling activities to behave similar to a “throw” in a C# catch block. The most visible aspect of this change is the addition of the Rethrow activity.

Lastly, the InvokePowershell activity is no longer shipped as part of the .NET Framework. Fear note, for it is not gone; it has been moved to the SDK samples, joining other quite useful activities.

Interop Activity

The Interop activity is a key component for WF4 workflows, allowing you to continue to leverage activities built in WF3. We’ve made improvements to the way that validations and transactions are handled within the Interop activity to more fully support WF3 activities.

Designer

I plan on having a whole post specifically around that, but we’ve done a fair bit of work to address feedback that we’ve received, namely:

Expand in place support
- This makes it easy expand an activity within the canvas without having to drill into it. This also lets you collapse activities when you don’t want to see all of the detail
Imports designer
- No more fully qualified type names within expressions
Text of flowchart lines for FlowDecision and FlowSwitch
- This is a nice usability / readability fix for the Flowchart, making it easier to see which cases and conditions the lines leading from decision shapes are for.

We received a lot of great feedback from folks about Beta1, and we’ve had a few usability studies done here in Redmond which have provided additional feedback that have shaped the work that we’ve done on the designer. Additionally, we’ve done work to clean up the object model to make it easier to rehost and customize the design experience. There have also been a number of key stability improvements and bug fixes to the expression editing experience which was a little rough in Beta 1.

If there are other resources you are looking for, let us know!

3.5 SP1 RTM WCF Source Code Available

kmouss — Sat, 17 Oct 2009 01:36:00 GMT

Late in the summer we have released WCF sources publically in the reference source. You can now browse and debug WCF source code through Visual Studio. We are working to get the WF in reference source later this year. I will provide an update when WF is also available.

Please note that this is version-dependent and we currently support this for 3.5 SP1 RTM only. Any support QFE or GDR upgrades for the assemblies aren't currently part of the package. New updates will be available in future. Here are the options to browse or debug thorugh WCF sources:

Option 1 – Install & Local Debugging

Download Reference Source Code Center.
Install Reference Source WCF MSI in your local machine say under: 'C:\ReferenceSource'.
Launch Visual Studio 2008.
From the Tools menu, choose Options.
In the Options dialog box, open the Debugging node and select General

Uncheck "Enable Just My Code (Managed only)"
Check "Enable source server support"
Uncheck "Require source files to exactly match the original version"

Select Symbols under Debugging.
In the Symbol File Locations box, validate the location where the installed symbol files (.pdb) are present. If not, then add originally downloaded symbols location: C:\ReferenceSource\Symbols
Build you app, set breakpoints and F5 to debug..

Option 2 - Remote Debugging

You will need to make sure that the version of the framework is 3.5 SP1 RTM (no GDR update for now) as the project assemblies' versions and symbols must match. With this option you can debug and step through WCF framework code remotly through the reference source server.

Reference instructions under: http://referencesource.microsoft.com/serversetup.aspx

( Same as above, just set your .pdb location to: http://referencesource.microsoft.com/symbols )

WCF Extensibility Guidance

KentBrown — Sat, 17 Oct 2009 01:15:32 GMT

We’ve just published the first chapter of the WCF Extensibility Guidance series.

One of the powerful things about WCF is its extensible architecture. However, the degree of extensibility can also be daunting. It’s not something you do every day, so you might not know which is the best extensibility option to use to achieve your goal.

Jesus Rodriguez was the lead author on this guidance. If I am ever on “Who wants to be a Millionaire?” and I expect hard WCF questions, Jesus will be my lifeline. I’ve needed his help many times and I haven’t been able to stump him yet. Pablo Cibraro, an expert in WCF security, also contributed significantly.

We’ll be rolling the other chapters out over the next few weeks. Please let us know how this guidance is useful to you and if there are other extensibility topics you would be interested in.

Contract First Web Services with WCF

KentBrown — Fri, 16 Oct 2009 16:45:20 GMT

Christian Weyer has published a great article on the topic of Schema-based Development with Windows Communication Foundation.

Few would argue with the value of Contract First programming when building large systems. However when programming web services, the choice comes down to Code-based Contract First or Schema-based Contract First.

The WCF tools provide great support for the Code-based model – you define an interface using normal code constructs as you would for any .NET class or component, and then apply the ServiceModel attributes. Then the WCF plumbing automatically handles things like WSDL generation, and serialization issues. For most developers this is a very convenient model.

However, there are reasons, especially when interoperability with other web service stacks is a priority, why many prefer the Schema-based model. For them, the WSDL is the contract. WCF does support this with tools like SvcUtil, but manipulating WSDL by hand can be a daunting task.

Christian has long been a proponent of Schema-based Contract First and has developed tools to plug into Visual Studio to better support this model. In this article he explores the reasons you may want to consider the Schema-based approach, how WCF supports it, and how the latest version of the Web Service Contract First tool, WSCFBlue (a free tool hosted on CodePlex), makes it even easier.

All WCF, WF, and ‘Dublin’ sessions live on PDC site; 5 Weeks to Go!

Cliff Simpkins — Wed, 14 Oct 2009 17:01:09 GMT

We’re five weeks out from PDC09, and the rest of our sessions went live last week. I know I posted a couple weeks ago about PDC and sessions that went live, but I wanted to let folks know about the four new sessions – to help you maximize your experience around the Connected Framework technologies!

This looks to be a great event, as the team dives in deep on the enhancements coming with .NET 4, and discussing some of the thoughts around what’s to come next.

PDC Sessions of Note
The below list is a refresh of the one I posted a couple weeks ago, with additions marked out.

The larger team will be delivering the following seven sessions:

In addition to the sessions being done by the team, WCF comes up in several other sessions of note at the event:

On the Floor of the Event
As an update, we have confirmed that we will have a small 20-seat theatre in the Framework and Tools lounge area. In the theatre area, we’ll be doing a series shorter ‘chalk talks’, discussing more special interest topics. There are some real gems being planned for discussion; we’re looking forward to hearing your thoughts.

I’ll post up any additional notes as we come up on the event. And, as a reminder, drop a note if you want to catch up with someone from the team while at PDC. Let me know what you would like to discuss, and I’ll reach out to the team that will be in LA and try to connect you with someone so you can coordinate schedules.

Hope to see y’all in LA!
Cliff