Visual Studio – sides of march (Brian DeMarzo)

For the past 22 months, we’ve been publishing using ClickOnce to the same path, using the same certificate, with no problems. This week, problems found us:

C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (3652,9): error MSB3482: An error occurred while signing: Failed to sign . SignTool Error: The signer’s certificate is not valid for signing. SignTool Error: An error occurred while attempting to sign:

The usual problem here is an expired certificate, but the certificate we’re using was created in December 2010 and expired in year 2039, so we knew expiration wasn’t a problem. The certificate file itself was also known to be valid; it was stored in our Subversion repository and hadn’t changed since the day it was created.

We called Microsoft (free support using our MSDN subscription). We spent about four hours working with them, creating test certificates, creating new certificates, trying to publish, with mixed and inconsistent results. We were told to use a new certificate because our current certificate was deemed corrupt. (When I asked what corrupt means, I was told it means the certificate file is bad. When I said that the MD5 hash of the certificate file was identical to the MD5 hash of the file created nearly two years ago and that it was stored in source control, I was told it was “bad” not corrupt. Semantics. Whatever.)

I seem to have fixed the problem this morning. It wasn’t the certificate. It wasn’t the path. Frankly, I don’t know what it is. I only know what steps I took before the point in which everything started publishing normally, as it had for the past 22 months.

Here’s what I did: I verified that every project in the solution has the same target platform (x86), .Net Framework version (3.5), and correct assembly information (some had default copyright information, some had autogenerated version numbers where we expected 1.0.0.0). After doing that and rebuilding, the ClickOnce publish worked as it did before, with the same old certificate, and clients behaved as expected (upgrading according to ClickOnce settings).

It makes no sense, because none of those settings were changed from our last good ClickOnce publish. Either way, it fixed the problem. Hopefully, it’ll help fix yours, if and when this annoying problem comes up.

I’ve recently started working with Outlook Redemption, an excellent alternative to direct MAPI calls. Some of the other devs on my team wrote some libraries that use it, complete with unit tests. All the code and unit tests run fine on my machine (VS2008, 64-bit Windows).

                     /"\
                    |\./|
                    |   |
                    |   |
                    |>~<|
                    |   |
                 /'\|   |/'\..
             /~\|   |   |   | \
            |   =[@]=   |   |  \
            |   |   |   |   |   \
            | ~   ~   ~   ~ |`   )
            |                   /
             \                 /
              \               /
               \    _____    /
                |--//''`\--|
                | (( +==)) |
                |--\_|_//--|

In order to illustrate some functionality, I needed to write a simple console application that used the code that these other devs wrote, so I referenced it and tried it… and was given an exception (the computer version of the middle finger):

Unhandled Exception: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following error: 80040154.

My first instinct was to search through the registry for the CLSID. Sure enough, it was there, and everything looked right. It has to be — otherwise, the unit tests (which use the exact same code) wouldn’t work.

The next thing I tried was unregistering and re-registering Redemption.dll (using regsvr32). No luck; unit tests work, console app fails.

Reboot? No luck; unit tests work, console app fails.

I did some reading, and apparently MSTest runs as a 32-bit application (though it can be run as 64-bit). I tried forcing Visual Studio to compile in x86? No luck; unit tests work, console app fails. Forcing Visual Studio to compile in x64 didn’t help either.

More reading, and I started to understand more about what the “Any CPU” platform compilation means, and the trials and tribulations of programming for 64-bit Windows. Now I am smarter, but I still can’t get my damn simple console application to work!

Seemingly out of options, I found myself staring at the Debug output directory, and noticed something:

SimplePstExtraction.exe SimplePstExtraction.vshost.exe

I went ahead and turned off the Visual Studio hosting process, and viola! Everything works fine. I don’t know why, exactly (though I’m sure it’s related to the difference between 32- and 64-bit processes), but it fixed my issue, so if you have the same problem, hopefully it’ll fix yours.

Tag: Visual Studio

Solved: ClickOnce publish failing with a valid certificate

The Visual Studio hosting process and 64-bit Windows