New video on using Team Foundation Server for BizTalk Server 2009 development with

New video on using Team Foundation Server for BizTalk Server 2009 development with

 
The Channel 9 Screencasts has a new video on using Team Foundation Server for BizTalk Server 2009 with Johan Hedberg from the BizTalk User Group in sweden.
Johan goes over the basics of creating a new build type and building BizTalk 2009 projects, unit testing / continuous integration features, and the extra steps required to […]

Moonlight 1.0 Release

Moonlight 1.0 Release

I am excited to announce that Novell today released version 1.0 of Moonlight, and is making it available for download at no cost with support for most major Linux distro’s (including openSUSE, SUSE Linux Enterprise, Fedora, Red Hat, and Ubuntu). For those unfamiliar with it, Moonlight is a joint effort between Novell and Microsoft of an open-source implementation of Silverlight for Linux.

My team has worked closely with Miguel de Icaza and his team on the project.  We are also shipping the Microsoft Media Pack – which is a set of licensed media codecs that enable playback for all Silverlight compatible media (wmv, wma, mp3, etc.), as a free download for Linux users who run Moonlight.

Moonlight enables Linux users to view Silverlight content and Silverlight applications.  Recently the official Presidential Inauguration Committee broadcast the inauguration of President Barack Obama using Silverlight.  Over 50,000 viewers using Linux installed Moonlight and watched the event live using it.  Miguel de Icaza and the volunteers behind Moonlight made a tremendous effort to make sure that Linux users were able to watch the broadcast of the inauguration, even though the official release of Moonlight was still a few weeks away.

image

I am really excited about the awesome work Miguel and his team at Novell have done, and we’re looking forward to seeing Moonlight 2 (a Silverlight 2 compatible implementation with .NET support) which the team is hard at work on. For more details on the Moonlight 1.0 release, check out Miguel’s blog post on it.

Thanks,

Scott

"BizTalk Server and WCF Support in Visual Studio 2008" whitepaper just published!

Microsoft%u00ae Visual Studio%u00ae 2008 provides robust support for solutions that use the Windows%u00ae Communication Foundation (WCF) and Microsoft BizTalk%u00ae Server 2009. While some of the functionality is clearly visible, some of it may not be evident to a BizTalk application developer how to take full advantage of these options.


The purpose of this whitepaper is to provide a clear and concise summary of the capabilities exposed by Visual Studio in support of BizTalk Server and WCF. That paper contains an explanation for the BizTalk application developer how each feature can help you in your complete BizTalk Server and WCF solution. You can view this as a high-level explanation of how Visual Studio 2008 can help support your BizTalk Server and WCF development and integration.


You can read or download it at http://msdn.microsoft.com/en-us/library/dd443655.aspx.

Hosting a WF 4.0 workflow service in “Dublin”

I did a post a couple of months back where I showed you how to take a WCF service and host it on the Azure service platform. I thought that was pretty cool, but wanted to take it to the next level. So, why not call that from a .NET 4.0 workflow, and host that workflow in “Dublin” (the set of WCF/WF hosting capabilities being added to the Windows Server application server)?

I heard it was Ron Jacobs that said that with .NET 3.0, WF and WCF “had just met”, in .NET 3.5 they “were dating”, and in .NET 4.0, “they’re married”. It’s a great way to think of it. The integration between WF and WCF now is really tight, and makes it really easy to create, host and expose a WF service using WCF.

I did this using the Community Technology Preview of the .NET 4.0 framework, using the virtual machine that was made available to PDC2008 attendees. Note that as with almost any CTP, it’s a pretty sure thing that there will be changes to the framework between that point in time and the ultimate release, so some of these screenshots, shapes and even steps may become obsolete. As always when working with pre-release software: expect change! I’m not going to say it was quick, but this post could save anyone trying to do the same a lot of time.

First step was to create a new project using the Windows Application Server template in Visual Studio 2010 PDC CTP (this will not be required in the release, it will just be workflow project).

I added a ServiceOperation step, which is how I will expose the service to the outside world. The collapse sequence inside the “after receiving message” is where we will consume the service.

With the PDC08 CTP VM, you need to define the operation contracts for both consumed and exposed service.

This first operation contract is the contract we will expose to the outside world. As you can see, we accept two string parameters on the way in, and return a string value.

The inside the collapsed sequence here’s where we call the service:

OK, so far this is pretty cool, but what could make it cooler? Take a look at the URI That’s a WCF service that I wrote that’s hosted in the cloud, on the Azure Services Platform.

And next is the operation contract definition of the service we are calling (the client operation). Hard lesson learned: you need to be REALLY careful with names you enter in the consumed service operation contract, or you’ll end up with a mismatch with the service WSDL, and invoking it will fail. This can be challenging to troubleshoot. This is after all a CTP, so, there are bound to be some areas that are opportunities for improvement.

For completeness and to close the loop in this post, I invoke my workflow service using the WCF test client application:

I thought it would be nice to echo out information to the debugger as the service was executing, so I created a custom workflow element to do that, which is the “DebugWriteActivity” you see above. I wanted to pass in a string from the host workflow, the technique is shown below.

So there you have it. With virtually no code I created a workflow service (hosted in “Dublin”), which was exposed as a WCF service, and in turn consumed a WCF service that was hosted in Azure.

I’d like to thank Cliff Simpkins (Microsoft) and Zoiner Tejada (Hershey Technologies) for their assistance as I went down this path. I’d also like to thank the people staying on my floor at the Hyatt for not calling security when I first saw this work calling an Azure-based service, my reaction was somewhat errr. “non-subdued” 😉

Technorati Tags: WCF,WF,Azure,Dublin

BizTalk 2009 – Build & Deploy automation with Team Foundation Server 2008 – Part 1

BizTalk Server 2009 comes with support for MSBuild. The question is, how can we use it, and how does it help us? The obvious advantage is of course, that this enables Visual Studio BizTalk projects to be deployed to the production environment without the pain of exporting/importing MSI packages. This is particular troublesome when dealing with large BizTalk implementations, with lots of assemblies, where you need to select and deselect assemblies to be included in the package.

I have previously posted two articles about using Team Build with BizTalk 2006 (that can be found here and here). That solution where more complex, and had many constraints. This solution is very easy to implement, and only require you to add one (1) single row in you default TFSBuild.proj file.

It is possible to automate deployment using BizTalk Server 2006 R*, but not without installing Visual Studio on the production environment. This is because MSBuild can’t build BizTalk 2006 projects, and you need to use DevEnv to do the work. But since BizTalk 2009 projects are C# project, and C# projects is nothing less then MSBuild scripts, BizTalk 2009 projects can be built on environments without the need of Visual Studio.

But there is  a catch -It can build, but there is no support for deployment 🙁

To manage Deployment, we need to do some customization.

When you create a new Build Type in Team Explorer and execute the build, the default build will execute a set of Build Tasks such as GetSources, Compile, Execute Tests etc. The result of the build will give you a folder with the output of the Build. That is a folder with a bunch of assemblies. To deploy these assemblies, we need to figure out where they should deployed to. The obvious place to find this information would be in the bindings files.

So to make use of the new MSBuild support, we need to create three custom tasks:

  • Undeploy Bindings – Since we are going to redeploy the solution, we need to remove all previous assemblies and artifacts.
  • Deploy Assemblies – This Task can optionally be disabled, in case you just want to undeploy. The bindings files will tell us to which BizTalk Application an assembly should get deployed to. if your build results in assemblies that should not get deployed to BizTalk, then these won’t get deployed since they are not included in the bindings files.
  • Import Bindings – This is the last custom task to be executed, and will create all the port bindings. Similar to the Deploy Assembly task, this one is optional is case you just want to undeploy.

Next we need to include these tasks in our build. We do this by adding a single row to our already created Build Type:

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
  <Import Project="$(SolutionRoot)/TeamBuildTypes/Blogical.BizTalk.CustomTasks.targets"/>
  <ProjectExtensions>

The Blogical.BizTalk.CustomTasks.targets file includes all necessary targets, and will execute the Undeploy-, Deploy- and Import Bindings tasks after the Compilation Task has been successfully executed.

That’s it!

There are some architectural constraints and considerations you need to be aware of:

Isolated Solutions

The Visual Studio solution is central in this process, and it’s important that projects within this solution should not be part of, or referenced from within any other solution that is going to be used in any Build Type. The reason for this is that the solution might not be possible to undeploy if it’s referenced by any other assemblies.

Bindingsfile location

In order for the Custom Tasks to find the Bindings files, the Bindings files need to be checked in to a folder named Bindings which needs to be located in the same folder as the Visual Studio solution file. Also the Bindings files need to be named [Some Name].[Target Environment].xml. Where the Target Environment could be something like TEST, STAGE, PRODUCTION etc. Eg Navision.OrderConfirmation.STAGE.xml

Shared Components

Global artifacts, such as generic schemas and pipelines, needs to be handled separately from this Build Process, as these are referenced by any number of assemblies, ports and filters.

BizTalk Applications

This Build Process does not create BizTalk Applications. Nor does it manage its references. Therefore you need to create them manually before deploying. As Applications are normally not created on a daily basis, this should not be a big issue.

Utilizing undocumented BizTalk assemblies

The Custom Tasks does not use BtsTask.exe, as it’s difficult to handle exceptions using for example Process.Start. Instead it uses Microsoft.BizTalk.ApplicationDeployment.Engine (also used by BTSTask, ExplorerOM and Visual Studio). This is working very well, but this is not a documented library. I would really like to see Microsoft ship BizTalk with a better supported Deployment API similar to ExplorerOM.

Installation

The Zip file includes the Custom Tasks library and the CustomTask.target file.

  1. Save the Blogical.Shared.Tools.BizTalkBuildTasks.dll file to preferred directory on each server running the Build Agent. You can use a network share.
  2. Edit the Blogical.BizTalk.CustomTasks.targets file (line 44). Set the <Blogical_CustomTasks> to the directory where you saved the Blogical.Shared.Tools.BizTalkBuildTasks.dll.
  3. Check in the Blogical.BizTalk.CustomTasks.targets file to the TeamBuildTypes folder in you TFS project.

Downloads

Enjoy!