Visual Studio 2005 support?

[CraigNicholson]

Vault 2.0/3.0 does co-exist with Whidbey - it just doesn't work. It doesn't corrupt any data that I'm aware of.

If you look at my previous post you will see that it does in fact corrupt the working folder data due to an incompatibility between the DateTime.Ticks property.

Yes, displaying a message that a future version of Visual Studio may be incompatible with this version of Vault would have been helpful. But, once you know it doesn't work, it doesn't require a new version of an older version of Vault to not load it.

That would be absurd to ask you guys to put up a notice before the product was even in beta. But how about binding the SCC provider to only VS2003 and not affecting VS2005?

What is the technical reason for Vault 2.0.6 not working under VS2005 anyway? From the sounds of it, the interface should be the same and it should. Is it Microsoft to blame or SourceGear?

[dan]

Ah, yes, sorry, as I reread the post, I was mistaken. It is an issue when you load 2005 and then load 2003 again. That particular problem is because the 2.0 framework changed the format of its serialization, which we use for cache files, so there isn't much we can do. Losing cache files is definitely a pain, but it isn't life-threatening, so to speak - they are re-created if they are not there, although the status of the files is Unknown until you do another Get.

Most of the problems with Whidbey/Vault have been tracked down to issues with the 2.0 framework and how it differs from 1.1.

In fact, a lot of people have got Whidbey to work (with Vault 3 anyway, not sure about Vault 2), but we don't want to officially support it until we've really tested it well, and made changes in Vault to workaround any of the new incompatibility issues. The problems do change with each new Beta or CTP of Whidbey, so we are trying to make sure Whidbey Beta 2 is a good drop.

[CraigNicholson]

Why is it that you feel that SourceGear should provide you with a free upgrade to support a new Microsoft version, but that you don't feel that Microsoft should provide you with a free upgrade that continues to support SourceGear's product?

Did I say SourceGear should provide a fix to make Vault 2.0.6 work with VS2005? No I didn't. Vault 2.x was never marketed as a product that would work with anything other than VS2003. I'm asking for Vault 2.0.6 to NOT be loaded under VS2005 if it is not going to work properly.

SourceGear are responsible for the integration aspect of their product integrating with VS2003. Currently the Vault 2.0.6 IDE integration component is integrating with a product it was not designed to integrate with - namely VS2005.

[CraigNicholson]

It is an issue when you load 2005 and then load 2003 again. That particular problem is because the 2.0 framework changed the format of its serialization, which we use for cache files, so there isn't much we can do.

Is there not a way of forcing the IDE integration component to use only the .NET Framework 1.1 through a configuration file somewhere?

Losing cache files is definitely a pain, but it isn't life-threatening, so to speak - they are re-created if they are not there, although the status of the files is Unknown until you do another Get.

Well in this case when my developer opened Vault Client it threw up that error message and the file lists appeared empty until I changed where Vault stores its working files and restarted the Vault Client.

The problems do change with each new Beta or CTP of Whidbey, so we are trying to make sure Whidbey Beta 2 is a good drop.

That is understandable.

As a matter of interest, other than project Allerton, what are the plans to integrate with VS2005 and VSTS?

[dan]

Is there not a way of forcing the IDE integration component to use only the .NET Framework 1.1 through a configuration file somewhere?

There is a way to do this for the Vault GUI client, but not for the IDE, because our IDE component must use the framework required by Visual Studio - it can't load two different ones. Whidbey requires the 2.0 framework, and we can't change it.

As a matter of interest, other than project Allerton, what are the plans to integrate with VS2005 and VSTS?

3.1 will provide integration with VS2005, but we don't have plans for Vault to integrate with VSTS (either by replacing the back end with Vault, or using a Vault client as a front end), since there wouldn't be much value add for either Vault or VSTS customers in doing so.

[v2.x User...]

I do wish that v2.06 (or some 2.x version) of Vault would work with VS2005. We have about 11 licenses and I like the product much better than VSS. But I don't write the checks around here, and those that do see VSS with HTTP access as a acceptable solutions based on only 4 people here that need source control access via Visual Studio. With our current level of MSDN we get "free" VSS licenses for the devlopment team.

We can't upgrade just some of the users to the 3.x Vault, to upgrade all of the 11 licenses that use vault today would "cost to much" they told me. So looks like I'm heading back to a VSS user.

It does seem that Vault would want to keep customers in a situation like ours. It's not just loosing us for this version, but probably for good. Just does not seem like a good move. OF cource I don't know how big of a change the 2.x version would need to go through to work with VS 2005.

It was good while it lasted!

[jclausius]

I hate good byes. I prefer "Until we meet again."

While integration is not possible in v2.0.x, the stand alone GUI client will still work. So that is still possible in the Visual Studio 2005 / Vault 2.0.x world.

But, before making a final decision, investigate what functionality will be lost in the switch. VSS Internet client only supports the basics of check out / check in. I'll admit I don't know the status of all available features, but I don't think things like History, Label, Branch, Rollback, etc are available. Also check on theif Diff support that client, I think it made it in the RTM, but there was a report this would not be available either.

Knowing is half the battle.

[bbatchelder]

So far I have had good luck forcing the standalone vault client into using the 2.0 Framework, so that it can read the cache files modified with Vault under VS2005.

I know this is certainly an unsupported configuration, but it is impossible for me to upgrade to a newer version of Vault - I am stuck at v2.0.6.

So, is there anything that is known that will bite me in the ass? I have been running in this configuration for about a week now with no ill effects - but obviously the coverage of the code done in a weeks worth of normal usage is not very broad...

[jclausius]

If you started your Vault repository in .Net 2.0 and have only used it in .Net 2.0, then you "might" be OK. To be honest, you are in unsupported territory. The consequences may be very frustrating is something goes awry.

Also note, if you have the 1.1 .Net Framework installed, you should be able to control which .Net Framework the Vault client /server uses.

The Vault server, use aspnet_regiis.exe /i from within the 1.1 .Net Directory.

As for the client, you should be able to control this with an xml element to the VaultGUIClient.exe.config file. The Vault Visual Studio plugin will not work for this.

In this configuration, Vault client/server run against the 1.1 .Net Framework, and you can use the .Net 2.0 Framework for your other needs.