error MSB4075: The project file must be opened in VS IDE and converted to latest version before it can be build by MSBuild

We've implemented extensive MSBuild scripts to ensure our deployment is fully automatic and repeatable. this helps greatly in keeping release cycles short and boost the confidence in the solution as we always know the app is deployed correctly. we do not have these "ooops, forgot to do this, or that" after a release which you often get with manual processes.

Anyway - when I first started looking at MSBuils a while ago I was happy to see that csproj and vbproj files are simply MSBuild files now, which, again, boosted my confidence with this approach; I was slightly concerned that BizTalk project files have not been modifed to be MSBuild files but I guess this is understandable given the dependency between BizTalk and VS and the fact that the latest versions of both have been released quite close to each other.

Now, since we've managed to create our deployment framework regardless and had no issues with it (resorting to command line calls to build solutions with biztalk projects) this wasn't a big issue. until today.

Until now we did not have .net projects that refer to BizTalk projects, but today I've added a proeprty schema, and I've used properties from it in a pipeline component.

to do things properly I try not to hard code the name and namespace of the property but rather take them from the generated class in the compiled property schemas assembly; this, of course, requires that I will add a reference from the pipeline components project (c# assembly) to the BizTalk project (BizTalk assembly).

This broke our deployment script - when we call the MSBuild file of the csproj to build it it works out all the references and tries to build them.
The trouble is that it assumes they are all valid MSBuild files so it calls MSBuild passing it the BTProj file to build, but of course a BTProj file is not a valid MSBuild file so it fails with the error in the subject.

The only way I could avoid this is to remove the reference and hardcode the property names and namespaces in my pipeline component. not the end of the world, but not as elegeant.

Object reference not set to an instance of an object when enlisting orchestration

Yesterday we've been prototyping a bit of work which involved a lot of iterations of an orchestration.

Becuase our solution involved quite a few schemas, pipelines, property schemas, map etc on top of the process itself (and the fact that some of those we're already deployed to another application in our BizTalk server) we could not easily use visual studio to deploy the process (which is quite a limited option anyway, as I've blogged in the past).

Becuase we mostly did not change the process interface anyway we could get away witht he usual cycle of build, gac and restart (as you do), but eventually we did have to make an interface change (in this particular case it involved changing a "specify later" orchestration port to a "direct" port) so we had to re-deploy the assembly with the processes.

knowing that deploying from VS will not work we used BTSTask to deploy.
However, when we went to enlist the orchestration we've receive "Object reference not set to an instance of an object" error.

The cause of this was that I forgot that BTSTask does not GAC the assembly during deployment (although when deploying from VS assemblies do get GAC'd) and so the definition in the biztalk db did not match the acutall assembly loaded from the GAC.

GAC-ing the updated assembly solved this of course.

AnonymousTypes and serialization

In my current project we have to deal a lot of serialization of deserialization of objects; mostly due to the fact that we have a common object model accross most of our services and that mostly it is these objects that gets passed between web services in our solution.

In fact, almost every object we have is represented by both a .net class and a BizTalk schema and for that reason we have decorated most of our classes with serilization attributes to control the format of the xml generated.

As you all know, when objects are used in exposed web services, a schema that represents them is generated and embedded in the WSDL file, from which proxy classes will be generated in consuming applications.

A while ago I’ve noticed that in most of our classes have within the xml serialization related attributes the following attribute –

System.Xml.Serialization.XmlTypeAttribute(AnonymousType:=True)

Hvaing this instructs the the schema generator to avoid treating this class/type as a global type which prevents re-use.

To demonsrate the issue consider the following –

I have a web method HelloWorld that takes in 1 parameter myenum of type MyEnum (which is an enumeration)


If the enum type has the discussed dattribute the wsdl is generated as the following –




Notice that that enumeration is a local definition of the element.

Without the attribute the wsdl is generated like this –



Notice that now the enum is declared globally and can be re-used across the methods.

I'm not sure why we had this in, I suspect, if I'm not mistaken, that the xsd.exe tool adds this attribute to classes generated from xml, and we've used this in many cases as our template.
Either way - I now try to avoid this attribute generally and only apply it when it makes sense. otherwise I have all the types declared as non anonymous which enables reuse.

"The send port configuration corresponding to the message was not found"

Today our operations team spotted the following error in the event log of one of our servers:

A message going to a one-way send port is being suspended. Reason:The send port
configuration corresponding to the message was not found.
This usually
happens when a send port was deleted while it still had some active messages.

This has sent us chasing in the wrong direction for a short while trying to think who has deleted what on the server.
Shortly after the real cause of this issue became clear through another event in the event log which noted that access to the SSO database was denied.
Of course, as the port configuration is stored in the SSODB, if access to this databsae is restricted port configuration cannot be accessed and so the message could not be delivered

"Professional BizTalk 2006" book

Recently I've had the great privilege to review Darren Jeffords "Professional BizTalk 2006" book.

I have to say that, since there are already a few good BizTalk related books around, I was a bit sceptical at first about the need for another one; but having read Darren's book I'll be the first to admit I was very wrong.

The book hands out lots of great techniques, tips and tricks about BizTalk development as well as invaluable knowledge about the inner workings of BizTalk.

I'm sure even the most seasoned BizTalk developer out there will find quite a few gems in it; I don't think there was a single page from which I did not get something useful.

Definitely a must have book for any one serious about BizTalk!