MSB3147: Could not find required file 'setup.bin' on a x64 machine.

Another day spent on the issue above. This one shows up during the automated build on a x64 machine. The MsBuild script works as a charm on a development machine and fails on the build server.

As internet explains, this issue stems from the fact that there’s no way for MsBuild to locate the folder containing so called bootstrapper which is required to assembly a ClickOnce setup package. Even if the SDK is installed but VS is not, there are some registry entries missing.

If you ever encounter this issue, please do know that there is a workaround which will work for sure – you just copy the Engine folder from the "c:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Engine" folder (assuming you are on .NET 4.0) to the folder of your ClickOnce app. To us, this was unacceptable.

What about other solutions? Well, the blog post above mentions that MsBuild tries to locate the Engine folder by reading the information from following registry entries:

1. HKLM\Software\Microsoft\GenericBootstrapper\1.0\path
2. HKLM \Software\Microsoft\.NetFramework\SDKInstallRoot<Version>\Bootstrapper
3. HKLM \Software\Microsoft\VisualStudio\<Version>\InstallDir\Bootstrapper

And, well, that’s not exactly true. First, forget about 2. and 3., you possibly do not have these on your development machine and, still, the solution builds correctly. Second, the 1. should refer to “4.0” instead of “1.0” in case you build for .NET 4.0.

And third, remember that on 64-bit machines the registry entry differs from the one above, it should be HKLM\Software\Wow6432Node\Microsoft\GenericBootstrapper\4.0 (note the Wow6432Node in the path).

No code generated when you create/update a service reference in a Silverlight application

This took us few hours to resolve – after few changes in the project, the “Update service reference” operation invoked from within the Visual Studio in a Silverlight application ends with no errors but the sole content of the created proxy class is just the preamble:

//------------------------------------------------------------------------------

// <auto-generated>

//     This code was generated by a tool.

//     Runtime Version:4.0.30319.1

//

//     Changes to this file may cause incorrect behavior and will be lost if

//     the code is regenerated.

// </auto-generated>

//------------------------------------------------------------------------------

No namespace, no class, no code, just the preamble.

It seems that there’s an issue somewhere between the slsvcutil.exe (the tool used to create Silverlight proxies) and Visual Studio. After hours lost on searching for the real issue, it finally turned out that the default service reference option, “Reuse types in … referenced assemblies”, forces Visual Studio to append a list of “/reference:<filepath>” to slsvcutil.exe (which is invoked by VS on create/update reference).

What happens next is slsvcutil.exe tries to load all listed assemblies and when an assembly references another assembly which cannot be resolved, the slsvcutil.exe ends with a nice error message “Could not load file or assembly …”.

However, when invoked from the Visual Studio, for some unknown reasons this error message is swallowed and you end up with no error message but no code generated for your proxy class.