0

I have run into a problem in a solution containing a WiX manged custom action project, which is also using MS RiSE Code Contracts. The problem is that the code contracts tools fail with the following error: enter image description here

I found a few mutterings about this issue going back at least 5 years, but not even a hint of a solution or workaround.

As an experiment, I tried commenting out the WiX-specific targets as follows: 

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <!--<Import Project="$(WixCATargetsPath)" />-->
  <Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

This allows the build to complete and the code contracts analysis/rewrite to complete successfully, however it obviously doesn't produce the correctly packaged self-extracting custom action. Since Windows Installer doesn't have any facility for managed code custom actions, WiX uses the trick of wrapping the managed code in an unmanaged wrapper which is a self-extracting archive containing the managed code custom action and its dependencies. It is a clever trick that lets us write custom actions in managed code, and it works very nicely. Until now.

I suspect what is happening is that the WiX build process is stuffing the managed code into an unmanaged wrapper, which becomes the project's primary output and which the Code Contracts utility then chokes on, because it is not managed code. I can't be certain because the code contracts build process isn't visible, so I can't see how it is working.

The above experiment makes me think that if I could somehow split the build process into separate parts, compiling the custom action code as a bog standard C# class library project, then doign the WiX packaging in a post-build event, I think the code contracts utilities would be able to process the code correctly. The problem is that I don't know enough about the Code Contracts mechanisms, or the WiX build process for that matter, to figure out what I'd need to do in the post-build event.

Would it be possible to somehow perform the WiX custom action packaging in a batch file or PowerShell script, which could be run as a post-build event? What would I need to do?

Tim Long
  • 13,508
  • 19
  • 79
  • 147
  • What is your target platform and what version of the target libraries are you using? I've seen this error when attempting to use 32-bit libraries/dll's in a 64-bit application, though I can't tell from this information if that's what's happening. Most .NET projects will default to x86 (if using Visual Studio). – Ryan J Oct 25 '14 at 00:22
  • Ryan, I am targeting 'Any CPU'. I don't think that is the issue in this case, since if I comment out the WiX targets, then Code Contracts works as advertised, and if I put that back in and disable the code contracts, then the WiX build works as expected. I definitely think it is an interplay between the two technologies. – Tim Long Oct 25 '14 at 09:09

1 Answers1

2

Check out the DTF.chm help file that comes with WiX, in the Development Guide it explains how to manually build the CA DLL with MakeSfxCA.exe.

Sean Hall
  • 7,629
  • 2
  • 29
  • 44
  • Thanks Sean, I will definitely check that out. – Tim Long Oct 24 '14 at 06:18
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – neelsg Oct 24 '14 at 08:39
  • @neelsg The answer to the question is to manually build the CA DLL with MakeSfxCA.exe. The only way to get MakeSfxCA.exe is to download WiX, which includes the help file. The details on how to use MakeSfxCA may vary by version of WiX (which was not provided). This post should not be deleted unless someone else wants to write the batch file or PowerShell script for the OP. – Sean Hall Oct 25 '14 at 17:00