In a (not so recent) post, I walked through the steps to get your BizTalk Server 2006 R2+ Orchestrations exposed to the Cloud. See Exposing BizTalk Orchestrations to the Cloud. With the release of the Microsoft .NET Services SDK (March 2009 CTP) this week, you will find your existing .NET Services endpoints no longer valid.

Here's how to resolve the issue.

At the moment your existing .NET Services endpoints are in the form:

sb://servicebus.windows.net/services/[solution name]/[service name]/

This has now been changed to:

sb://[solution name].servicebus.windows.net/[service name]/

Note: you can still register your service hierarchy as before (e.g. sb://.../[service group]/[service name]) but for simplicity I have just used [service name] in the URI's above.

So, even if you followed Microsoft's advise and coded your service endpoints URI's this way:

Uri address = new Uri(String.Format("sb://{0}/services/{1}/{2}", ServiceBusEnvironment.DefaultRelayHostName, solutionName, serviceName));

that didn't get you out of trouble when the URI change was released. We are now encouraged to use the following when generating endpoint addresses in code:

Uri address = ServiceBusEnvironment.CreateServiceUri("sb", solutionName, serviceName);

This will give us an address in the new structure and protect us from any future changes (but we heard that somewhere before didn't we). Also, be aware that (as of time of posting) the published services feed is not listing your services correctly (but they are still accessible). Your new published services feed will also be:

http://[solution name].servicebus.windows.net/

In the coming days, the team at Breeze will be walking through the new goodies the March CTP brings so look out for future posts (of particular interest is the queuing and routing features we have now!).