Upgrade to 4.1 with Cruise Control - Cryptographic
Moderator: SourceGear
Upgrade to 4.1 with Cruise Control - Cryptographic
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!
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!
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.
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.
Subscribe to the Fortress/Vault blog
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.
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.
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.
Subscribe to the Fortress/Vault blog
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.
-
- Posts: 28
- Joined: Tue Feb 17, 2004 7:42 am
- Location: UK
- Contact:
".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.)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>
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.