We had a very useful brown bag session with the BizTalk Product Team this week and went through some of the new developer improvements. Fortunately not much of this was under NDA so I thought id share some of what I learnt and my thoughts on this. Ill just keep this in the simple format below:

BizTalk Project Files are now MsBuild

A new BizTalk project file is basically an extension of a C# project file. It looks very similar to a normal MsBuild based project file see the Picture below.

From this picture you can see lots of familiar stuff. You can see from the following picture from the project file that a BizTalk project file imports the C# MsBuild targets as well as some new BizTalk ones by default.

I believe BizTalk projects have their own project type guid in the project file system which indicates them as a certain type of project file. You can see this above in the MsBuild script where the Project type Guids indicate this project contains C# and BizTalk stuff. I would assume here you can also add the project type guid for MsTest projects and then start putting tests in this project also. In practice you probably wouldn’t do this, but it illustrated whats possible with project files now being in MsBuild.

BizTalk Projects Can have non BizTalk Artefacts in them

That’s right you can now add other artefacts than BizTalk ones. Some examples of this might be you have a C# class, a text or xml file in your project. Because of what I said above about the C# targets this means if you include a .cs file in your BizTalk project then it will be compiled and made available just like any other normal class. There are a couple of questions and limitations relating to this however:

1. In the current CTP you can not Add New Item and add a C# file etc to the project. This is expected to be in future releases, but for now you will need to add the item to the file system then add it as an existing item.
2. Because the BizTalk project file extends on C# if you add a VB file it will not by default be compiled. If however you add the VB MsBuild targets it should be possible to compile these files also. Essentially its just an MsBuild script so you can do what ever you can do with .net projects.

Assembly Info

BizTalk projects now have AssemblyInfo.cs type files like any normal C# project. This makes things simpler for manipulating these kind of files. See the pic below, if you notice there is a new assembly attribute called BizTalkAssemblyAttribute which I guess indicates the assembly is a BizTalk assembly.

No more Deployment/Development

One thing which makes me very happy is that the pointless configuration difference between C# and BizTalk projects is now gone. You can see this below.

It would be nice if the Deploy tick box wasn’t checked by default also. This is a useful setting for small demo type projects but in real projects you are unlikely to deploy your BizTalk assemblies through the Visual Studio IDE. I guess now we are based on MsBuild it might be possible to create a new project template where this is not checked (possibly a small community project here).

Compile BizTalk Solutions without Visual Studio

In the installation of BizTalk there is an option to install Project Build components. This means you can use these components to build your solution without Visual Studio. This is what a number of people have been asking for to help them implement the good practice on a Build server of compiling code without needing Visual Studio.

Strong Naming Change

The way BizTalk projects are strong named has changed and is now the same as for C# projects. From the picture below you can see this is set through the project property editor and it sets information in the MsBuild project file. Again another handy improvement in that it is just the same as C#.

Common Project Settings

As you can see from the below picture you can see the BizTalk project also has the same settings which are commonly used in C# projects. You can set the highlighted sections so you can set warnings and constants etc.

One of the more interesting things however though is that you can setup the XML documentation for the project. At present this will only do documentation for things like C# files within the project, but I guess in the future this is something that either Microsoft or the community may look at as a way of incorporating BizTalk Documenter style functionality into the compilation process.

Project Migration

When you migrate your project to BizTalk 2009 there is a migration wizard similar to the one for migrating .net code. You can use this or you can also call DEVENV from the command line with the /UPGRADE switch to migrate your code. You seem to get the normal features of the Visual Studio migration wizards. One limitation here is I believe the project migration does not change the project configurations from the old Development/Deployment modes so you will have to do this manually. And also apparently you can migrate from BizTalk 2006 or BizTalk 2006 R2 to BizTalk 2009.

Unit Tests

As I have mentioned in some other recent posts there is a new Unit Tests property as shown in the picture below. This will make the compilation process generate some additional code to help you unit test various BizTalk artefacts. If you would like some more information about how to use these features please refer to my updated BizTalk Testing Guidance on the following link:

http://geekswithblogs.net/michaelstephenson/archive/2008/12/12/127828.aspx

Improved Build Performance

Apparently when BizTalk projects are compiled now the MsBuild will be able to tell if things have changed and only compile what has changed. Maps and Schemas seem to be complied to a .cs file before being compiled into the assembly a bit like Orchestrations could be if you made that tweak in earlier versions of BizTalk. This means MsBuild is able to detect the changes to these files and only recompile them as needed. This should in theory improve the overall solution compilation time. This could make a big difference on those projects where you end up with lots of assemblies.

This is most of what I remember from the session which was really useful, thanks to the guys who put this together.