Upgrade to .NET Framework 2.0 will corrupt Vault database

[lbauer]

Vault is not supported under ASP.Net 2.0 / .Net 2.0 Framework. Upgrading from .NET framework 1.1 to 2.0 can cause your Vault tree to become unusable and SourceGear will be unable to repair it.

Vault relies on some components of the .Net Framework to construct your source tree. Due to these compatibility issues, a source tree saved in the .Net 1.1 Framework is modified incorrectly under the .Net 2.0 Framework.

A fix for this will be issued in the Vault 2.1 release.

See this post for additional details:
http://support.sourcegear.com/viewtopic.php?t=1653

[Thomas Linder Puls]

Is this only for the server, or does it also apply to the clients.

Can an client running on an updated machine ruin the data?

[jclausius]

A client cannot "ruin the data". However, a client may lose its Working folders, meta data information, and may encounter other unexpected problems.

We realize this is important to some people, and we are working on a fix to address the problem in the Vault 2.1 release.

[thomas62j5]

We were going to evaluate Vault until we read about this problem.

Any time frame for the 2.1 release?

[dan]

It is still a few months away. We might fix this in a dot release earlier if there are a lot of people who want to upgrade to the .Net framework 2.0 on their server machine.

[ericsink]

We were going to evaluate Vault until we read about this problem.

Just curious: Why wait?

The person who discovered this problem was an extremely early adopter. We anticipate that most Vault users will be a bit more cautious. The 2.0 version of the .NET Framework won't be shipping for many months. You don't really want to install an early beta of the 2.0 framework on an important server, right?

It is unfortunate that Microsoft decided to break compatibility between 1.1 and 2.0. It is an especially unfortunate coincidence that this compatibility change happens to affect Vault in such a severe way. But like Jeff said, we'll have a workaround for the problem in 2.1, which will ship long before .NET 2.0. The 2.1 release will ship sometime in the next few months.

Anyway, like I said, I am curious why this issue would cause anyone to change their plans for evaluation of Vault. I won't argue with whatever your reasons are. I just want to listen.

[onovotny]

/me takes a bow -- I have now scheduled weekly database backups and daily zip backups of the shadow folder.... being a guenea pig is so much fun!

Eric, one thing you may want to play up is the currently planned incompatibility between Hattaras and VS 2003. In serveral posts, Buck Hodges says that the client side of SCM will require the 2.0 framework, thereby not working in VS2003.

While there may be hacks to get C# and VB.Net to target the 1.1 framework with MSBuild, I suspect that VC7.1 will be a harder beast to target from VS 2005, especially in solutions that have both MC++ and C# code in them.

At any rate, you certainly have my vote for bugfix rather than version release, but I'm sure you knenw that already

Cheers,
--Oren

[thomas62j5]

Hi Eric,

You asked "why wait." I must confess I have not paid much attention to .NET, and just assumed that 2.0 was either the current version out or that it would be coming soon. We run at a colocation facility, and were concerned our provider might decide to update .NET on our servers, and were worried about this corruption issue mostly for that reason. I have checked with them, and they assure us they would never update software without asking, and now you're saying 2.0 is not even out yet and won't be for many months, so that is good enough for me.

I am hoping you will have the fixed version out though before .NET 2.0 is released.

Regards,
Thomas

[ericsink]

I am hoping you will have the fixed version out though before .NET 2.0 is released.

Definitely.

Thanks for the response.

[cdaniel]

I'm assuming that Vault 2.0.x could actually coexist with .NET 2.0 on either the client or the server, provided the necessary manifest/configuration changes are made to force Vault Server/Client to run on the 1.1 framework.

Yes?

[jclausius]

Please correct me if I'm wrong, but I'm pretty sure the client would work by using the correct <runtime><assemblyBinding> tags in *.exe.config.

As for the server, as long as IIS has been regsitered (%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i) to run under the 1.1 .Net framework, this would work as well.

[thomas62j5]

As for the server, as long as IIS has been regsitered (%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i) to run under the 1.1 .Net framework, this would work as well.

Ahhh! So THAT is how you configure IIS to use 1.1. I was going through all the file extensions individually and changing them to use the 1.1 DLL instead of the 1.0 DLL... thanks for the info.

[onovotny]

Please correct me if I'm wrong, but I'm pretty sure the client would work by using the correct <runtime><assemblyBinding> tags in *.exe.config.

This is partially true. For the standalone Vault GUI client, then yes, the bindings will force Vault to use the 1.1 framework. Where you have trouble is using the SCCI under VS 2005. I'm not 100% sure, but I suspect that the implementatin is in a DLL assembly thereby running in-process with VS 2005. Since VS 2005 is running on the 2.0 framework, conflicts could arise.

As for the server, as long as IIS has been regsitered (%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i) to run under the 1.1 .Net framework, this would work as well.

This is true. In fact, the 2.0 framework adds a tab to the IIS Website Properties box which makes it a snap to toggle between framework versions per Application.

--Oren