Vault gives "Input string not in correct format" o

Beth · Post by **Beth** » Fri Sep 07, 2007 4:14 pm

If it wasn't the cache, I was thinking maybe some ways of handling networking are different in various Windows profiles. I'm not 100% sure on that, and they would have to not be using roaming profiles, or he'd have the same issue on another machine.

djkunkel · Post by **djkunkel** » Mon Sep 10, 2007 7:28 am

I'll give these things a try today. We are not use roming profiles here.

AFAIK, you can't use the requiredRuntime element to select a specific revision of a runtime:

The version attribute string must match the installation folder name for the specified version of the .NET Framework. This string is not interpreted. If the runtime startup code does not find a matching folder, the runtime is not loaded; the startup code shows an error message and quits.
http://msdn2.microsoft.com/en-us/librar ... s.80).aspx

One more idea on this. If Nick is logged into his computer, and then lets someone else login to Vault, does it work? If it doesn't then I think it's something tied to his Windows profile.

It works for nobody as long as Nick is logged into his own machine. I agree it must be something with his Windows profile on his machine.

Thanks for the support so far.

Post by **jclausius** » Mon Sep 10, 2007 8:11 am

One other possibility is the registry for the account.

Vault will store some user specific info (window positions, user settings, etc.) in the registry for HKEY_CURRENT_USER\Software\SourceGear\*.

Perhaps (while logged in), Nick should remove the SourceGear\Vault or SourceGear\Fortress key before starting the GUI client. <Registry_Disclaimer>Please exercise extreme caution when modifying the Windows Registry as a misstep can corrupt a Windows installation.</Registry_Disclaimer>

djkunkel · Post by **djkunkel** » Mon Sep 10, 2007 1:47 pm

OK. I was able to clear the registry key on Nick's machine, but the Sourcegear folder was not present under his profile in documents and settings (<username>\Local Settings\Application Data\Sourcegear). The folder does exist on working client machines (and accounts).

No change.

djkunkel · Post by **djkunkel** » Mon Sep 10, 2007 1:49 pm

I did check to ensure that Nick's account has permission to write to that folder as well, fyi.

Post by **jclausius** » Mon Sep 10, 2007 2:00 pm

Maybe the path location is not correct w/ Nick's account.

We can approach this a couple of different ways...

1) Search for CacheMember_Repository on Nick's machine. Do you see any file in a directory that would be associated with Nick's Window's account?

2) Have Nick try to log in with the Vault client. Once you're received the error, close Vault and look at the registry for Nick : HKCU\Software\SourceGear\Vault\Client\Settings. Is there a string value for a CacheLocation (eg. E:\Users\account_name\AppData\Local\SourceGear)?

3) Using the info from step 2, does Nick's account have security rights to that path? Does that path have a sub folder for Client\{Repository GUID}\client\{vaultlogin}? Does NIck's account have full control to this? Is there a file named CacheMember_Repository in that folder?

djkunkel · Post by **djkunkel** » Mon Sep 10, 2007 3:03 pm

OK. Here are the results.

1. Their is no file for Nick's account. For mine, yes.
2. CacheLocation points to C:\Documents and Settings\beccin\Local Settings\Application Data\Sourcegear. That directory does not exist.
3. Nick has "Full control" to that folder (C:\Documents and Settings\beccin\Local Settings\Application Data). However the directory has no Sourcegear folder.

Other interesting tidbits. When I right click on the Vault icon and "Run as..." with Nick logged in, and enter my credentials, it works just fine.

I used the .NET 2.0 config tool's "Elvaluate assembly" option on the runtime security context menu to determine what .NET security policy is being applied to the VaultGUIClient.exe. It reports "Unrestricted"

Beth · Post by **Beth** » Tue Sep 11, 2007 8:34 am

I'm wondering if it would be at all possible to make a backup of any files the user needs to keep and then delete the user's Windows profile from that machine. It would end up erasing all his custom settings and may affect other programs as well. It's a pretty destructive way to go about it, but it might do the trick. You would want to consider the implications on all his software and work he does before trying that, and make sure all important files are backed up and out of his profile area.

Or you could rename the profile that is on that user's disk as well, and a new one will be made when that user next logs in. That way, if you need to go back because something breaks, that is still an option.

I think you might have to be logged in as Administrator to do this. Then you would just go to C:\Documents and Settings\<username>, and rename the folder that is his username.

No matter which route you take, I'd recommend a backup or copy of any files the user needs.