A few weeks back while getting Mako XRM ready for launch, I was working through an issue involving ClickOnce build and deployment. I was attempting to isolate a 32-bit COM component so it would not need to be registered on every end-user’s computer upon ClickOnce install. MSDN has a decent article describing the process (http://msdn.microsoft.com/en-us/library/ms165432(v=vs.80).aspx) and it seemed simple enough to carry out. I isolated the reference as suggested and everything seemed fine on my machine. Issues arose when attempting to build the solution out on the TFS build server. I repeatedly ran into this error:

deploying_isolated2

Microsoft.Common.targets (2580): Problem isolating COM reference eWebControl: No registered classes were detected for this component.

I struggled for some time wondering if I needed to register the COM component in some special way on the build server. As I was running out of options, I ran across this MSDN article (http://msdn.microsoft.com/en-us/library/56e00bfh.aspx). The article states:

“On a 64-bit machine, Framework64/<version>/msbuild cannot resolve COM objects registered as 32-bit components. For example, if you register a COM object with regsvr32 and then try to build a project targeting the x86 platform with Framework64/<version>/msbuild, the build is unable to resolve the COM object. If instead you build with Framework/<version>/msbuild, the build is able to resolve the COM object.”

I had assumed that because I set Platform Target to “x86” in my project properties, the build was running as x86. However, the build server was still running the 64-bit version of MSBuild regardless of what my project properties were set to. To remedy this, I had to mess with the build process parameters (Team Explorer -> Builds -> Edit Build Definition -> Process Tab):

Edit Build Definition

Simply switching that flag from "Auto" to "x86" solved my issue.

That flag determines whether the build runs Framework64/<version>/msbuild.exe or Framework/<version>/msbuild.exe. Simply switching that flag from “Auto” to “x86” solved my issue. The solution ended up being quite simple, but I did spend a good bit of my (and others’) time on it. I hope this post saves someone else’s time tracking down and fixing the cause of the build server error.

Looking For More?

Sign up to receive useful software development tips and news from the Don't Panic Labs team.

You have successfully subscribed!

Share This