stuck - Ticks out of range - High priority

djMax · Post by **djMax** » Wed Oct 20, 2004 3:44 pm

I cannot run the Vault client. It is stuck in an infinite loop of a dialog box. The dialog box says:

The working forlder state information for <foo> is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Ticks must be between DateTime.MinValue.Ticks and DateTime.MaxValue.Ticks.
Parameter name: ticks

This is causing ALL projects under this repository to fail, which is essentially stopping all development. Not good.

Vault 2.0.6. No upgrades recently. Have been using VS2005, but this error is just in the client. Other people can get in ok.

lbauer · Post by **lbauer** » Wed Oct 20, 2004 3:51 pm

We spoke on the phone and you indicated you have .NET Framework 2.0 on the client machine. Vault Server and Client are not yet compatible with .NET Framework 2.0. We suggest you uninstall .NET Framework 2.0 and delete your current working folders and client side cache files. Then try running the client again.

dan · Post by **dan** » Wed Oct 20, 2004 3:54 pm

This doesn't make a lot of sense if nothing has changed recently. It looks like a new working folder was set somewhere to a folder from a previous version of Vault.

Bring up the GUI client and see if you get the same error, and check the working folder that is assigned to the solution you are working with (and all its supprojects) and make sure they are correct. You may need to do an Open From Source Control on the project to a brand new working folder, which will cause you to lose any edits in your working folder, but you can copy files you've modified over and it should pick them up from there.

dan · Post by **dan** » Wed Oct 20, 2004 3:55 pm

Ahh - you are using the 2.0 framework. That explains it...

djMax · Post by **djMax** » Wed Oct 20, 2004 3:55 pm

that's not really an option. You're saying that the Vault client and .Net 2.0 can't live on the same machine? That's not especially acceptable. We have active work underway with .Net 2.0 that we cannot just dump, and I have active changes. As far as Vault should know, they are just files. What does this error really mean and how can we get to the bottom of it?

djMax · Post by **djMax** » Wed Oct 20, 2004 3:57 pm

I refer to the release notes for 2.0.6:

# Client/Server Changes
Both client and server must be upgraded to take advantage of these changes:
# Both client and server are now compatible with with .Net framework 2.0 Beta

It has in fact worked fine up until now, with many checkouts and checkins.

dan · Post by **dan** » Wed Oct 20, 2004 4:07 pm

The 2.0.6 release fixed a problem with the 2.0 framework on the server that caused database corruption, but there are still lots of bugs to work out. So, we are "compatible", but not bug free on the beta version of the framework. There are probably lots of other problems related to the beta of 2.0 that have not been found yet.

Try the steps outlined above though - hopefully it will get you up and working.

djMax · Post by **djMax** » Wed Oct 20, 2004 4:17 pm

Here's my running theory. When Vault is run from inside VS2005, it screws up the working folders, and then the client can't read anything anymore. I would argue that 2.0.6 is in fact NOT compatible with .Net 2.0 given that an error in a single project's working folder causes the entire client to lockup and it seems the only solution is to wipe out all working folders and start over. I'm hoping I'm wrong somehow, because that very well may make me switch back to VSS.

What's worse is that now, on a TOTALLY separate machine, none of the status searches appear to be working. What gives?

ericsink · Post by **ericsink** » Wed Oct 20, 2004 4:46 pm

djMax wrote:I would argue that 2.0.6 is in fact NOT compatible with .Net 2.0

You may very well be right. When we said "Both client and server are now compatible with with .Net framework 2.0 Beta", we used wording that was too strong.

The 2.0.6 release fixed a problem with .NET 2.0 which was truly catastrophic. It would have been better for us to just say that this one problem was fixed. We don't actually have enough testing or experience with .NET 2.0 to claim compatibility.

In fact, if you're using Vault on .NET 2.0, we would expect you to see problems. If you're using Vault with IDE integration with Visual Studio 2005 beta, we would expect even more problems. I think we just sort of assumed that anybody using a pre-release version of .NET would expect lots of difficulty, but we should have set those expectations more clearly.

Anyway, let's try to move forward. It is evening here, so most of our staff is at home. I am hopeful that we can get you running again tomorrow.

djMax · Post by **djMax** » Wed Oct 20, 2004 4:49 pm

Thanks. I'm slowly recovering. It turns out if I *do* use VS 2005 integration, I can run long enough to get stuff checked in for that project. The 2003 projects lost all their working folder info, so I'm going through those manually. The big question after all this will be how I can develop on 2005 at all... I guess I'll need to disable SCC integration somehow.

djMax · Post by **djMax** » Wed Oct 20, 2004 4:54 pm

Apparently Vault has a bit of a mind like a steel trap... It refuses to use the folder that was previously used for my 2005 project, even though I've deleted the folder. I assume this is something in the client cache directory that's causing this. Assuming I have multiple repositories, and that I want to blow away everything vault knows about 1 of them, how can I do that?

dan · Post by **dan** » Wed Oct 20, 2004 6:04 pm

For an exhaustive description of client side cache files, see http://support.sourcegear.com/viewtopic.php?t=6

I would re-interate what Eric said - working with .Net 2.0 beta is problematic, but I'm surprised that integration with VS2005 works at all. Is this something that has been working for you but suddenly stopped working?

Also, are you somehow using the same working folder for VS2003 and VS2005? I'm not sure how that would work, but I'm also not sure why a VS2003 working folder would have problems when a VS2005 working folder is used elsewhere.

Post by **jclausius** » Wed Oct 20, 2004 9:46 pm

djMax:

I'd like to suggest a possible, but untested solution. Now, this will not work with a Vault IDE client, but I believe adding the following information in VaultGUIClient.exe.config *should* force Vault GUI to run with the correct framework as long as the .Net 1.1 framework is installed on your client:

Code: Select all

<configuration>

<startup>
  <requiredRuntime version="1.1.4322" safemode="true" />
</startup>

<runtime>
	<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" appliesTo="v1.0.4322">
	<dependentAssembly>
		<assemblyIdentity name="System" publicKeyToken="b77a5c561934e089" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Data" publicKeyToken="b77a5c561934e089" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Drawing.Design" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Drawing" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Management" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Security" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Web" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Web.Services" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Windows.Forms" publicKeyToken="b77a5c561934e089" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	<dependentAssembly>
		<assemblyIdentity name="System.Xml" publicKeyToken="b77a5c561934e089" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.5000.0"/>
	</dependentAssembly>
	</assemblyBinding>
</runtime>

</configuration>

I want to stress I have not fully tested this, so the xml may be a bit off. Also if you do experiment, with this change to VaultGUIClient.exe.config, please make a backup of the file before the changes, so you can undo anything which may be incorrect.

HTH

djMax · Post by **djMax** » Thu Oct 21, 2004 8:05 am

It had generally been working (VS2005 integration). Putting all the pieces back together, I *think* it went wrong when I finally checked in a change to a file in vs2005. I had checked in a project ok, had checked out files somewhat ok (I'd usually have to do it twice, first with an error, then worked) but things generally worked.

I think the config idea, if it also handles the integration portion, is probably a very promising one, because that what this problem smells like... It seems like the VS2005 version runs in 2.0, serializes stuff in a 2.0 format, and then 1.0 just gets confused. I might just turn off source control in 2005 entirely.

I guess the big question is for y'all at SourceGear, do you want me to try and isolate this problem or do you have better ways of dealing with 2.0 than tracking these down individually? I think it's a fine answer to say "we're not going to get serious about 2005 until it actually is." But if I can help I'm happy to.

dan · Post by **dan** » Thu Oct 21, 2004 2:22 pm

djMax wrote:
I guess the big question is for y'all at SourceGear, do you want me to try and isolate this problem or do you have better ways of dealing with 2.0 than tracking these down individually? I think it's a fine answer to say "we're not going to get serious about 2005 until it actually is." But if I can help I'm happy to.

Yes, we would be glad to get any info you have on breakage with VS 2005/Vault, so that when we look at it more closely, we have good places to start.