Vault gives "Input string not in correct format" o

[Beth]

I'm thinking maybe a look at making some networking setting changes on your client might help. After trying each item, try to use Vault and let me know what happens.

Could you go into your Vault Tools - Options and change the setting for Chunked Encoding to the opposite of what it is now?

Can you set your network card to half-duplex?

There's a thread here that had some good suggestions: http://support.sourcegear.com/viewtopic ... highlight=. Mostly with the possibility of the MTU/windows scaling issue that was mentioned there.

[nickmoyle]

You also may want to look at rolling back the .NET framwork 2.0 on your client machine. There are reported differences between 2.0.50727.832 and 2.0.50727.42 which could potentially be causing your problem.

A number of people have reported issues with this version on MSDN (for things other than Vault) and uninstalling KB928365 has resolved their problem.

One other thing would be to ensure that the SQL protocols in use are the same across the client and server, and that the SQL Server default collation is the same as that of the Vault database.

[djkunkel]

Thanks for the suggestions.

1. I've tried reinstalling .NET 2.0 to the original release.

2. I'm not sure what good changing SQL settings would be since AFAIK Vault client only uses SOAP to talk to the server.

[djkunkel]

The TCP scaling issue only affects Windows Vista. I'm running XP.

I'm ready to pretty much give up on this issue. It was fun to try your product, and it certainly seemed a great fit for our needs, but it looks like it isn't going to work in our environment. We've trialed other source control packages without an issue (SVN, CVS, Source Safe, Evolution). Your software seems a much better fit for us, however.

It is certainly something with our setup, as when logging in as another Active Directory account on the failing machines, all is well. Only the account for the machine's "owner" fails. I was hoping you could give me some insight from the log files on what could cause that error so I could find the discrepancy.

Thanks for your help.

[jclausius]

Sorry to see you couldn't find the configuration problem for Vault in your environment.

One other possible thing would have been to see if we can isolate this as a .NET issue or something else. We could have temporarily set .NET Framework to use .Net Framework 1.1. This is done in IIS for the App Pool or .NET tab. For the client, this is done by adding :

Code: Select all

<configuration>
<startup>
<requiredRuntime version="v1.1.4322" safemode="true"/>
</startup>
<system.net>

to the VaultGUIClient.exe.config file.

It would have been nice to know if this was isolated to a .NET configuration problem.

In any case, we wish you well.
Cheers.

[djkunkel]

I've entered your configuration change to a GUI client. I get this message from .NET when starting:

VaultGUIClient.exe - Strong name validation failed.
---------------------------
Strong name validation failed for assembly 'C:\Program Files\SourceGear\Vault Client\VaultGUIClient.exe'. The file may have been tampered with or it was partially signed but not fully signed with the correct private key.

[Beth]

when logging in as another Active Directory account on the failing machines, all is well. Only the account for the machine's "owner" fails.

Ohhhhh, ok, so that's only with particular user accounts on those machines? What happens if you have those same people that it fails for log into a working machine. Does Vault work for them then?

[djkunkel]

Yes, stangely. I'll attach some names to make this easier to explain.

Nick, when he logs into his computer with his AD account, Vault fails with the message. When Nick logs into another computer with his same AD credentials, Vault works properly.

When I log into Nick's computer Vault works properly.

[jclausius]

When logging into Vault from Nick's Window session, does the Vault login fail for any Vault login (Nick's, Your's, Admin)?

[djkunkel]

On Nick's machine, logged in as Nick, it fails for any Vault user. Logged on to Nick's machine as Me, every vault accounts works.

Nick logged into another machine (not his own) works for all Vault accounts.

[djkunkel]

Sorry to see you couldn't find the configuration problem for Vault in your environment.

One other possible thing would have been to see if we can isolate this as a .NET issue or something else. We could have temporarily set .NET Framework to use .Net Framework 1.1. This is done in IIS for the App Pool or .NET tab. For the client, this is done by adding :

Code: Select all

<configuration>
<startup>
<requiredRuntime version="v1.1.4322" safemode="true"/>
</startup>
<system.net>

to the VaultGUIClient.exe.config file.

It would have been nice to know if this was isolated to a .NET configuration problem.

In any case, we wish you well.
Cheers.

Is there anyway to get around the strong name error so we can try this route?

[Beth]

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.

[jclausius]

I'm not certain what the strong name error would be. Let's try a specific version of .NET 2.0.

With the following

Code: Select all

<requiredRuntime version="2.0.50727.42" safemode="true"/>

entry, do you still receive a strong name error?

[jclausius]

BTW - I guess you would actually have to have "2.0.50727.42" installed.

[jclausius]

I think Beth is onto something. When you log onto Nick's machine, the software would presumably be the same. However, there will be differences in profiles.

We do store private information in a user's profile. Perhaps something there was corrupted. If you look under Nick's profile for Local Application Data, you will see a SourceGear\Vault_1\* directory structure.

Assuming ALL versions of Vault and Visual Studio have been closed, rename the Vault_1 directory (Vault_1.old). Now try the Vault login. This will re-create the SourceGear\Vault_1\* cache files, so we would be starting with a clean slate.