BizTalk Server 2009, BizTalk Server 2010, Deployment, Development

Visual Studio (BizTalk Server) 2010 development / BizTalk Server 2009 deployment mix

Can you use the updated development environment for BizTalk Server 2010 with Visual Studio 2010 while still deploying to BizTalk Server 2009?

Can you do it? On a file level, yes. On a project level, yes. On a solution level, doesn’t seem like it. On an assembly level, no.

I tried two scenarios.

  1. A simple messaging only scenario with a transformation on the receive port.
  2. An orchestration scenario picking up the file from the receive location, doing the mapping and delivering it to the send port.

I developed the solution on a BizTalk Server 2010 / Visual Studio 2010 combo and deployed it to BizTalk Server 2009.

So what worked and what didn’t?

Compile and deploy the .NET 4 assembly to BizTalk Server 2009



Even though I did Add a resource manually selecting the file to be a BizTalkAssembly BizTalk Server 2009 kept on reverting it back to File. Obviously it doesn’t recognize it, or recognizes that it’s an incorrect version of the framework.


Re-target the solution to .NET 3.5 or .NET 2.0



The following is taken from

BizTalk Server 2010 supports building new applications only on .NET Framework version 4 . You can build both BizTalk applications as well as custom applications (such as custom functoids, custom pipeline components) using .NET Framework 4 . However, BizTalk Server 2010 continues to support the BizTalk Server 2006 R2 and BizTalk Server 2009 applications (BizTalk applications and custom applications) built on .NET Framework 3.5 SP2.

If you launch an existing BizTalk project in BizTalk Server 2010 , it automatically gets migrated, changing the .NET Framework version to 4.0. You cannot modify the .NET version number later in the Properties dialog box of the BizTalk project.

In essence it says that you cannot use the re-targeting functionality within Visual Studio 2010 for BizTalk Server 2010 projects. If you try, because the drop down is still there, you get the following dialog:

Using Files created by Visual Studio 2010, like .xsd, .btm or .odx


You can copy paste files from one project into another, without any issues I detected.

Open the project file created with Visual Studio 2010 and re-compile using Visual Studio 2008

SUCCESS! But with some issues…

You can open a BizTalk project created in Visual Studio 2010 in Visual Studio 2008 and just re-compile it. Without any issues I detected. However, it does not seem like Visual Studio 2008 wants to open the solution file, which may be an issue in some situations, like for example if you wan’t to create automated builds. The structure of the solution file begins like this:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "BizTalk Server Project1", 
"BizTalk Server Project1BizTalk Server Project1.btproj", "{DE7C19FB-A5BA-46A0-9382-ACFB3EB91409}"

This may very well be what causes Visual Studio to dismiss it.

Hope this helps someone thinking along these lines 🙂

Disclaimer: This is tested with BizTalk Server 2010 Beta. All artifacts used while performing these tests are trivial. It might very well be that in some more complex scenario this might not work.

BizTalk Server 2009, MSMQ

Weird MSMQ issue with an even weirder solution

You may think I am crazy… In fact, it seems so unbelievable I don’t quite believe it myself, but I experienced it, and can’t shrug it off. So, on the off chance that someone else might run into this, I am writing down the experience since I couldn’t find a single reference to it when I searched for a solution (which by all means in turn means it’s unlikely that it has happened to all that many people before).

On one environment I was testing MSMQ connectivity. From my brand new BizTalk Server 2009, windows Server 2008 64-bit, environment I wanted to connect to a Windows Server 2003 remote transactional MSMQ queue. Since I wasn’t doing anything remotely service oriented, quite the opposite – it was all about file transfers, I decided to use the “old” MSMQ adapter.

This didn’t work, and failed with the error message:

The adapter “MSMQ” raised an error message. 
Details “The type initializer for ‘<Module>’ threw an exception.”.

Ok. So faced with this what do I do? I start local. I created a local private transactional queue, a FILE receive and a MSMQ send – to get a message into the queue. This worked fine.

I then wanted to read the message out from the queue and write it back to disk. This did not work, but failed with the same error message.

I created a second queue, non-transactional, and put a message in there and tried to read it from that, to peel away the transactional aspect. Same non-helpful exception.

I was somewhat at a loss. As I expressed my disgust a colleague asked why I didn’t use the WCF-NetMsmq, and though I had no intention of using it in the final solution that brought on the idea of trying that instead. So I configured a port for that and enabled it.

When I did, I got back the message from the queue. However… as I looked in the Event Log I saw error messages from that adapter and looked to see that I had configured it incorrectly – I had continued to put the queue name as xxxprivate$yyy (in the WCF-NetMsmq adapter you don’t use the $). What had happened? I had not gotten the messages with my WCF-NetMsmq port.

As I enabled the WCF-NetMsmq the old MSMQ ports had sprung to life and begun working!

I could now get messages from the local transactional as well as non-transactional queue.

And when I tried the remote queue I now got another, much more helpful, error message:

The adapter “MSMQ” raised an error message. 
Details “This operation is not supported by the remote Message Queuing service.
For example, MQReceiveMessageByLookupId is not supported by MSMQ 1.0/2.0,
or remote receive of the large mesasage cannot be done by the client below v3.5

As it turns out, I can’t make the connection I wanted, as remote transactional queues are not supported by the BizTalk MSMQ adapter in this scenario, on accounts of it not being available in Message queuing 3.0 (which, if you remember, my target system is running since it’s Windows Server 2003). References are here:

But the real point here is not that, but the strange exception I got up front. Repro you ask? Couldn’t get it to happen on any other environment, in fact, on the ones I tried the MSMQ adapter just works. No weird exceptions.

BizTalk Server 2009, Learning

BizTalk Server 2009 Training

During the fall of 2009 I teamed up with fellow MVP Mikael Håkansson and delivered internal training to Logica employees in Sweden. Training in part based upon existing training material from Microsoft but with presentation material that we made especially for this course. We have since developed this material even further.

Being a MCT I was contacted by one of the major certified learning providers in Sweden that through mutual contacts had learned of what we had done. I have the pleasure of being able to start this year by announcing that an agreement have been reached with AddSkills to deliver this course to the public.

So if you are in my part of the world (a.k.a. Sweden) you now have an additional choice to get quality BizTalk Server training that covers the latest version. See available sign-up details and dates here. Delivery of custom on or off site courses based on the same material is also possible.

64-bit, BizTalk Server 2009

BizTalk Server 2009 Standard and 64-bit processing

I was kind of suprised when I saw this blog post. Saying that 64-bit processing wasn’t allowed with Standard Edition of BizTalk. Since I was at PDC at the time I asked the people there who were (without me putting words in their mouths) equally suprised. At the time they couldn’t see either a licensing or technical reason as to why that would be so. And to add to that it was strange that Branch was allowed while Standard was not.

I didn’t have access to machines (or time) to test right then, but after getting back I tested and true enough you are not allowed to create a 64-bit host. The UI stops you. As you can see, this doesn’t stop BizTalk Server Standard from being installed on a 64-bit machine – it just doesn’t get the benefits of 64-bit processing.


I also found an “official” explanation to this here, which I’ve pasted below:

“We consider 64-bit support an Enterprise Edition level feature that a customer would only select if they require faster messaging/orchestration processing or the larger addressable virtual memory of 64-bit mode for large BizTalk message mapping or other memory intensive operations. Because the Standard Edition is designed for small-to-medium environments, it is licensed to only run on a single BizTalk server with a maximum of two CPUs, maximum of five “BizTalk Applications”, and a single message box. 64-bit support for the Standard Edition seemed counter-intuitive from a technical and licensing perspective. If the deployment scenario requires 64-bit hardware then it certainly requires BizTalk Enterprise as well. Standard edition is for single box only installations. Enterprise is also required for multi box installs and for clustering.”

Judging from the fact that 64-bit is now very much mainstream, especially on servers, I would expect to see this change in the upcoming releases of BizTalk Server.

.NET 3.5, BizTalk Server 2009, Development, SOA, WCF

Oh BizTalk, why dost thou mock me?

In any given integration project many different parties are involved. In some cases these parties have standard endpoints against which BizTalk operates and sometimes these endpoints are built as you go in the participating systems to meet a new demand. This is true for other types of projects as well – things get finished at different times – and you need to be able to work independent of each other during that time. What you often do determine very early in the project are the design of messages, schemas or APIs through which you exchange information. In many cases a BizTalk project can effectively use FILE send or receive ports that serve the same purpose as a One-Way send or receive port to say SAP would do at a later stage. But how about solicit-response send ports? What do you exchange these for?

In this post I’d like to introduce a way to handle solicit-response through the use of a catch all WCF Service. There any many ways in which to mock a service. The prime benefit with this approach is that you will be able to model your BizTalk solution the way you want it to be, without having to have access to the real service, and exchange the solicit-response port for it’s production or acceptance test counter parts at your convenience.

To achieve this we need something that let’s us send in any message, and based on some part of the message determine what message to send back, and the send it as a response.

WCF is a perfect candidate. It has functionality both to allow us to create methods that handles all incoming requests by specifying a wildcard (*) as the Action property, and accept any message and can send any message as a return. Using the Message base class it also allows us to easily create the response message, and populate the body of the message from the contents of a stream, such as a file (See the ‘Creating Messages from XmlReaders’ topic in the link).

So what I did was I created a WCF Service, and added a method to catch all messages:

[OperationContract(Action = “*“, ReplyAction=”*“)]
Message CatchAll(Message message);

In the implementation for this method I have include the following code:

FileStream stream = new FileStream(ResponseHelper.GetResponseFile(requestAction), FileMode.Open);
XmlDictionaryReader xdr = XmlDictionaryReader.CreateTextReader(stream, new XmlDictionaryReaderQuotas());
MessageVersion ver = OperationContext.Current.IncomingMessageVersion;
return Message.CreateMessage(ver, ResponseHelper.GetResponseAction(requestAction), xdr);

I have a small helper class that just helps me get data from the config, the config in turn looks like this:

  <section name=”requestResponseHandling
type=”ServiceHost.RequestResponseHandlingConfigSection, ServiceHost“/>
    <add requestAction=”
responseLocation=”GetData2Response.xml” />

This enables me to add new responses to incoming requests without needing to rebuild the service to incorporate a new response. You could go crazy here with code and undertakings to reply based on some context or what not. In the case presented here I’m just making it simple and returning the same static message for all request that matches a certain requestAction.

Finally, put this in the host of your choice. In my case I’ve got IIS so I’m hosting it there. That will also cause changes to the web.config to automatically get loaded, so that’s happy times.

Using this from a client is super easy. Just point the address of the client endpoint towards this service instead. The only thing that might not be super simple (though still fairly simple) is that you need to know what the meat of the response will look like when serialized as a response (the body of the response message). That is you need to Generate a sample response message from your wsdl.

Now let’s look at how we can utilize this to mock services in BizTalk Server. Oh, but wait, that sounds like it would be a bit of work to do, but… no, that isn’t the case. In fact, once you have configured the WCF service the only thing you need to do is to point your Send port at this service instead of the system that would otherwise be there in it’s place. Loop closed.

BizTalk Server 2009, Download, VirtualPC

BizTalk Server 2009 VPC

Available. Usable for demos, Hands-On labs and just getting a peak at BizTalk Server 2009 if you aren’t yet running it. Good news. Get it here.

Update 1 [2009-10-19]: This download is currently corrupt. Fix pending.
Update 2 [2009-10-24]: The download page has been removed. Links to files still work. Files still corrupt AFAIK.
Update 3 [2009-10-25]: Download is live again! Files are still corrupt.
Update 4 [2009-10-30]: I’ve download it 5 times. Still corrupt. Some people in other parts of the world seem to be able to download it ok, while others in the same country gets it corrupt. Cached somewhere?
Update 5 (2009-11-02): Got a question from a blog reader that downloaded the file today and found it corrupt if I had heard when a fix was comming. I haven’t.
Update 6 (2009-11-04): I’ve had multiple reports of people downloading the file, both those finding it corrupt and those who are able to use it ok. Try it if you have the bandwidth to spare. I haven’t been able to pinpoint any determining factor, though I do so hate things that are down to chance.

Update: Here are the links directly to the files, for loading in FDM or similiar.

Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Part 7
Part 8