Yossi Dahan [BizTalk]

Google
 

Wednesday, February 28, 2007

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.

3 Comments:

  • You can also look at the UK SDC toolkit on gotdotnet which has a bunch of deployment related capability

    By Anonymous Anonymous, at 04/03/2007, 16:48  

  • Thanks, we are using quite extensively the toolkit and I think it is great (although we have made some changes to it, mainly around error handling as well as adding additional functionality such as deploying policies and vocabs).

    I don't think there's anything there to build a project though other than through dev env.

    By Blogger Yossi Dahan, at 04/03/2007, 18:16  

  • Quite right. Biztalk still cannot be built by anything other than DevEnv so we have been forced to use DevEnv exclusively as almost all our solutions have a mix of biztalk and clr code. This means that even pure "build machines" must have vs.net and biztalk installed to get anything to compile. However i dont agree that its a sequencing issue (ie) VS has to be stabilised for biztalk to be able to use its build format etc. This problem has existed from v2004 and surely by then VS2003 was fully stabilised and even with its custom proj formats, the BTS team could have worked out a compilation model that would have allowed a pure command line approach. MSBuild was CTPed and beta'ed for a long long time and the BTS team had another opportunity to sort their build and project format out and they didnt do it. Take versioning, for another example. There is still no simple AssemblyInfo.cs/vb way to change versions. We have had to resort to using the XmlWrite in MSBuild to change the Assemblyfile version and info version in the btproj file.

    just my two cents.

    cheers,
    benjy

    By Blogger Santosh, at 25/03/2007, 14:37  

Post a Comment

<< Home