Upgrade to 4.1 with Cruise Control - Cryptographic

dsquires · Post by **dsquires** » Fri May 09, 2008 9:42 am

Hello. We've been running Cruise Control .NET against Vault 3.5 forever with no issues. We're attempting to upgrade to Vault 4.1 and all goes well until we turn on Cruise Control - we're getting a Cryptographic exception (keyset not found)... And I was wondering if anyone had a quick idea as to why.

Of Course - the guy who set up the original integration is Gone and didn't document his process... So I'm not sure if we're missing an obvious step or not.

thanks all!

Post by **jeremy_sg** » Fri May 09, 2008 10:28 am

First, can you post the exact error message? I want to verify that I'm giving the correct advice.

Second, I'm making an assumption that .Net Framework 3.5 is installed on the computer in question (because Crypto errors in the past have usually involved 3.5). If that's the case, can you try setting the runtime version in the vault.exe.config?

<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
<requiredRuntime version="v2.0.50727" safemode="true"/>
</startup>
</configuration>

If my assumption isn't correct, you will also want to verify that the user who is running the CC.Net process has full control over the \Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys directory.

dsquires · Post by **dsquires** » Fri May 09, 2008 10:59 am

Thanks for quick response, Jeremy.

This is from the event viewer:

An unhandled exception ('System.Security.Cryptography.CryptographicException') occurred in vault.exe [1404]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.

Interestingly - i didn't seem to have a vault.exe.config. I added it with the proper xml declaration, etc in the directory with vault.exe and added the settings... and made sure the the ccnet service was running as local admin. No love yet.

dsquires · Post by **dsquires** » Fri May 09, 2008 11:02 am

Oh - and yes... this machine is running 3.5...

Post by **jeremy_sg** » Fri May 09, 2008 11:13 am

Can you post what you have for the exe.config? Also, it might help to start with a copy of the VaultGUIClient.exe.config file.

dsquires · Post by **dsquires** » Fri May 09, 2008 11:21 am

Thanks to you pointing me in the right direction - i got it working. I checked out the permissions on that MachineKeys directory and gave Administrators full access to it (they had read permissions previously). I'm not exactly sure I understand why this would help - but ccnet is now talking to vault.

lbauer · Post by **lbauer** » Fri May 16, 2008 12:21 pm

Glad things are working for you now.

Mike Dimmick · Post by **Mike Dimmick** » Fri May 16, 2008 10:58 pm

jeremy_sg wrote:Second, I'm making an assumption that .Net Framework 3.5 is installed on the computer in question (because Crypto errors in the past have usually involved 3.5). If that's the case, can you try setting the runtime version in the vault.exe.config?

<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
<requiredRuntime version="v2.0.50727" safemode="true"/>
</startup>
</configuration>

".NET 3.5" is an awful name because it leads people to expect that the CLR version has changed. It hasn't. It's still v2.0.50727. However, .NET 3.5's installer installs .NET 2.0 SP1 if that hasn't already been installed. There is no way to redirect from .NET 2.0 SP1 to RTM because the files for RTM are overwritten by the service pack. (The assemblies, e.g. System.Windows.Forms.dll keep their original assembly version, 2.0.0.0, but the file version numbers are updated to e.g. 2.0.50727.1434 - the file in the GAC is replaced.)

So if there's a problem with Crypto in ".NET 3.5", it will also be there if you only deploy .NET 2.0 SP1.