So I’m currently working with a customer/partner that needs some help with building, deploying and testing BizTalk 2009 applications with TFS 2008 (other post will describe that solution) and as usual I start off in my own virtual environment where I test building, deploying and testing before I deliver the builds to the customer.
Anyway everything is working exactly like my own environment until the build script hits the “export BizTalk 2009 application as msi” section. I get this funny error message:
BizTalk Server Deployment
Error while exporting application <my application> into MSI package. Function failed during execution…
So the first thing I try is running the same command that TFSBuild just ran in my own Command Prompt, and of course it runs without any errors. So I start looking for stuff that differs between my account and the TFSBuild service account. I go through all the permissions and security groups without any luck. So I continue with my search in the TFSBuild log and find that the temp directory for the service account looks a bit strange:
C:\users\ <TFSBuild Service Account>\Tmp\…
Can you see the problem?
There was a space in the name for the TFSBuild service account and that made the ExportApp function of BTSTask to fail. The solution in my case was to set the environment variables TEMP and TMP to nicer paths like C:\Temp or C:\Tmp and the build worked.
So don’t use spaces in your account names because you never know what problems you’ll run into.
2010-11-15 Script file updated
This blog post has been updated after feedback from my colleagues Markus Ahlstrand and Johan Leino, thanks you guys! The original blog post contained 1 error and needed 2 clarifications and 1 refinement, all updated content is highlighted below.
I’ve worked a lot with SharePoint development during the last 3 years and before SharePoint 2010 you could use Virtual PC to create your development environment. But as you might know a SharePoint 2010 development environment has to be on an x64-bit environment as described in this article “Setting up the Development Environment for SharePoint 2010…
So this left me with some alternatives:
- Install the bits on your own x64-machine.
- Use another virtualization platform such as Hyper-V, VMWare or VirtualBox that have support for x64 on my own x64-machine.
- Create a bootable VHD from Windows 7.
I chose the bootable VHD option because I love the feel of Windows 7 and the rich features that Windows 7 gives the end user. On the other side I need the flexibility to start my SharePoint 2010 box when I need that with (almost) no performance loss.
There’s a lot of blogs out there that describe how to create a bootable VHD and so I will not list them here but I will give you a nice automated head start (without MB’s of download).
In the linked CreateBootableVHD_v2.zip you will find two files:
- A machine running Windows 7 or Windows Server 2008 R2.
- Windows 7 or Windows Server 2008 R2 installation media or a Windows 7 or Windows Server 2008 R2 .wim image captured from a reference machine.
The following steps are provided with a “works on my box” guarantee.
Ex: .\CreateBootableVHD_v2.bat C:\VHD\W2k8.vhd 40000 FIXED X F:\sources\install.wim
To show an actual example here is a snapshot from my latest run:
After 30-60 minutes depending on the size of the VHD and your hardware you’ll have a new boot option.
Hope you enjoy the script.
I finally decided to make a small footprint in the ever growing universe of ones and zeros we call the Internet. I do this for 2 reasons:
- I have a lot of knowledge that I would like to share
- I’m leaving Microsoft to become an Avega Coach in October and in my new role as an Avega Coach it comes with the job to blog
I hope you’ll enjoy my blog and I hope to hear from you soon.