7 July release of the new .NET Services CTP

On 7 July we will release the new .NET Services CTP. As part of this update, the workflow service will be (temporarily) removed.

Key Points

- The .NET Services and the .NET Services portal will be unavailable on 7 July between 9am and 3pm PST for maintenance

- The workflow service will be removed (replaced later on)

- Solutions that use the workflow service will need to be modified and associated workflow service data (such as workflow types and instances) will be deleted.

- Users’ queue and router data will not be saved and restored. Users will need to back up queue and router data locally and restore it, restarting applications and recreating queues and routers once the service is back up.

- The new SDK needs to be installed

Schedule

START: July 7, 2009, 9am PST

END: July 7, 2009, 3pm PST

Actions Required

- Queues and Routers data will NOT be persisted after the scheduled maintenance. Queues and routers will need to be backed up and restored. Use SDK samples such as the SimpleMessagesQueueSample consumer on how to retrieve and send messages to and from Queues

- Solutions that use the workflow service need to be modified to no longer use it

- Download and Install the .NET Services July 2009 SDK

- Read the release notes carefully for any breaking changes and known issues

- Visit the .NET Services Developer Center to access .NET Services forums, videos, blogs, documentations and more

All the above information is publicly available via this blog post. There will be another post nearer the update time where the new CTP features will be covered. Now for a bit more on the workflow decision...

Workflow Services Removal

The removal of the workflow service was announced in this blog post. However, I’d like to give you a bit more detail to help you in your interactions with customers.

.NET Services is part of the Azure Services Platform, Microsoft’s cloud platform, together with Windows Azure and SQL Services. It consists of three core pieces of functionality: a Service Bus, which enables message passing between cloud and on-premises applications across IT infrastructure such as firewalls and routers, an Access Control Service, which you to control who can access your on-premises and cloud-based applications using claims-based identities, and a Workflow Service, which allows you to run and manage workflows in the cloud. Naturally enough, the .NET Services Workflow Service has been built upon the current version of Windows Workflow Foundation, WF 3.5. This allows developers to reuse many of their existing workflows, hosting them in the cloud, taking advantage of a proven and shipping codebase, and utilizing a familiar set of tools in Visual Studio.

While this is a clear, well-thought-out plan for shipping the Workflow Service for November 2009 (PDC), we’ve taken the time to share our ideas and plans with literally hundreds of customers through Software Design Reviews, customer briefings and events, obtaining feedback on what we’re doing and making sure that we build the right thing for our customers. In the case of the Workflow Service, we’ve had one strong and consistent piece of feedback: that, based upon the experience with the VS2010 and .NET Framework 4.0 CTPs, the next version of WF is sufficiently (and improved) from WF 3.5 that, rather than build cloud-hosted WF 3.5-based workflows today and move them on to 4.0 later, customers would far rather wait until .NET Framework 4.0 ships and build their cloud-based workflows based upon that.

We have responded to this feedback by deciding to suspend development on the WF 3.5-based codebase and to work on WF 4.0 instead, withdrawing the Workflow Service from the July CTP with the aim of reinstating it at a later date using the 4.0 workflow engine and tools. So far, everyone we’ve spoken to about this agrees that it is the right thing to do. Furthermore, customers are happy that we have listened to their feedback and are acting on it. However, we need to be clear about what we’re doing and why, to avoid any customer confusion or misunderstanding – hence this blog post. Finally, although no one has objected to this change there can be exceptions. If you happen to know of such a case please let us know the details. We will be happy to follow up on those concerns