Vault to Fortress upgrade, problem re-binding

[Nihimon]

[8/20/2008 10:55:28 AM] Version Check: This Fortress client is version 1.1.2.18185
[8/20/2008 10:55:29 AM] Version Check: Your Fortress server is version 1.1.2.18185
[8/20/2008 10:55:29 AM] Version Check: The most recent Fortress release is version 1.1.2.18185

I'm having trouble re-binding a VS 2008 solution to the Fortress VS Enhanced client after an upgrade from Vault (4.1). I tried following the instructions at http://support.sourcegear.com/viewtopic ... highlight= but I'm hitting a wall. We upgraded to Fortress saving our current repository database. I'll lay out the steps I'm taking:

1) Get Latest from Repository for entire solution (from Fortress client).
2) Open Visual Studio 2008 and set the Source Control Provider to None.
3) Open the solution from VS 2008, say "Yes" to permantly remove bindings when prompted with "Source Control Provider not found" error (since we've already uninstalled the server and clients for Vault)
4) Save and Close VS.
5) Re-open Solution in VS and set SCP to VS Enhanced Fortress client.
6) Change SCP bindings and bind solution. At this point, everything looks fine...



7) Save all and close VS.
Re-open Solution in VS.
9) View SCP Bindings. This is where I hit the wall...



I'm not sure why, but I can't get the bindings to stick. When I Refresh Source Control Status, things look even stranger...



Note the red-circle next to the Solution name. The tool-tip is from hovering over this circle.

[lbauer]

You said you tried following the instructions in the KB article. Did that not work for you? You mention doing a get with the standalone client. That is mentioned in the KB article, but only for users who Get the project after it has been properly bound to source control. Please review the steps and let us know if they still don't work for you.

Open the solution in Visual Studio. Cancel out any connect to server dialogs.

Ensure that all project files and the solution file are NOT exclusively checked out by anyone (including yourself).

Open the "Change Source Control" dialog (File->Source Control->Change Source Control...).

Select all bound projects and click the "Unbind" button at the top of the dialog.

When it asks to confirm, click "Unbind".

Click OK to close the "Change Source Control" dialog.

Do a Save All in Visual Studio (File->Save All) to save the solution and project files. (If prompted to overwrite files that are readonly, overwrite the solution file and all project files.)

In Tools->Options, set your "Current source control plug-in" to "SourceGear Vault Visual Studio Enhanced Client".

Open the "Change Vault Bindings" dialog (File->Vault Source Control->Change Vault Bindings).

Select all projects that were formerly bound, and click "Bind...".

At this point, you will be prompted to log into the server and select the repository where the projects exist. Enter your username and password to log in.

In next dialog that comes up (titled "Bind"), click the "..." button to browse to the projects' Deepest Common Ancestor in the repository. Select the folder and press OK on the "Select a repository folder" dialog. Then press Bind on the "Bind" dialog.

You are then returned to the "Change Vault Bindings" dialog. Make sure that all projects that were selected have been marked "valid" in the status column. If any projects are invalid, you will need to unbind them or re-bind them individually.

Once all bound projects are valid, press OK on the "Change Vault Bindings" dialog. This will add changes to the project files to your Pending Change Set.

Perform a Check In to commit these changes to Vault. This can be done by right-clicking on the solution and choosing "Checkin" from the context menu.

After the checkin, you may be prompted to reload the solution and relogin to Vault.

[Nihimon]

My initial Get was to Get Latest as it was when it was still bound to the Vault VS Enhanced client. I didn't expect doing the Get from Fortress to fix everything. If you read through the steps I followed, you'll see that I completely removed all source control binding from the solution, then re-applied them. At that point, everything looked right and all the projects showed Valid. However, upon hitting OK, even if I immediately re-opened the binding dialog, it showed the projects as Not Bound. So hitting OK changed the status from Valid to Not Bound. I don't think this is the way it's supposed to work.

I should add that after...

Once all bound projects are valid, press OK on the "Change Vault Bindings" dialog. This will add changes to the project files to your Pending Change Set

... my Pending Changes is still empty, and attempting to Check-In the solution resulted in the error message "There were no items found for check-in."

So, these steps are not working for me.

Edited: Please note that the big difference the two pictures are meant to illustrate are that the first one shows all the Projects marked Valid, while the second shows all the Projects marked Not Bound.

[lbauer]

I followed your steps, step by step, but could not reproduce the problem. My projects remained bound. It's not clear why yours don't stay bound.

What types of projects are these?

I'll need to consult with a developer for more ideas.

[Nihimon]

The project types are Windows Application, Class Library and Setup Project. I'll see if I can find a simpler example of the same problem.

[Nihimon]

A little more info on our situation.

On Monday, we checked in all of our work, made sure nothing was checked out in Vault, backed up the database and uninstalled the Vault Server. A co-worker tried installing the Fortress server, but had some problems and didn't get those resolved until today. In the meantime, another co-worker and I continued development by working offline. After Fortress was finally installed on the server, we uninstalled our local Vault Clients, installed the Fortress Client, and began trying to get our solutions back online using Fortress.

The solution I'm trying first has a commonly used library which is included in most other solutions. Based on my prior experience with Vault and other SCPs, I know it's important that this project be bound correctly before trying to bind the other solutions that include it.

I'm very anxious to get this resolved, as none of us relish the idea of working without source control. Any assistance would be greatly appreciated, including remote assistance if that's an option.

[ian_sg]

Aside: For anybody else who stumbles upon this thread, this is a better set of instructions for rebinding when upgrading from Vault to Fortress than the others previously mentioned.

I'm not sure what's happened (I was also unable to reproduce the problem, even using that mix of project types), but I suggest these steps:

1) Open the solution (offline if necessary) and unbind it. Close Visual Studio.
2) Re-open the same solution. Ensure you're completely unbound: you should get no prompts to login nor the "Go Online" menu option. Close Visual Studio.
3) Delete the entire Fortress client cache folder.
4) Delete the Visual Studio Enhanced Client's settings file: %USERPROFILE%\Local Settings\Application Data\SourceGear\VsipSccClient\VsipClientProjectSettings.xml
5) Re-open Visual Studio. Turn on the diagnostic logging in the source control options (in case this doesn't work).
6) Open the solution and bind it.
7) Close Visual Studio, re-open the solution. If everything's not well, send me the diagnostic log (%TEMP%\VaultVsipClient2008.txt). If all's well, turn logging back off and get back to work.

[Nihimon]

After re-binding, when I clicked OK on the Change Bindings dialog, I got the following message:



This message was then repeated for the LacksValley2.Utilities class library project. Then I got the message:



and



I didn't get any of these errors previously.

How should I get the log file to you? I don't see any options to attach files.

Edited: Just to add, I read over the better instructions you mention, and that is exactly the process I followed initially.

[ian_sg]

I probably don't need the log to understand what's going on now.

Try this:

1) Using the standalone client, do a get latest of the solution. (EDIT: The important thing here is that you have the latest versions of the .sln and all 3 project files.)
2) Repeat the unbind/rebind process (steps 1, 2, and 6 from before).

Assuming this works, check in the changes and have other developers get latest via the standalone client before opening it in Visual Studio again.

If this doesn't work, you can email me the log (ian at sourcegear dot com) in case I do need it, we can skip a roundtrip.

[Nihimon]

Ok, I'm not going to try to understand why it's working now, but thanks

[ian_sg]

I think in the beginning you had a bizarre working folder assignment that was confusing things, but I had you essentially reset everything just to be safe.

The second issue was that you didn't have the latest version of the project files when you rebound, and we didn't handle that well.

In general, the steps you initially followed are correct and I'd expect them to work for your other solutions.

[Nihimon]

They're not working now on the 2nd solution I'm trying. I'm going through the same steps again to see if I can make it work. I'll let you know.

[Nihimon]

Solved!

The process I followed was:

1) Get latest from Fortress
2) Check out .sln file and each project file (.csproj, .vdproj, etc.) Don't overwrite if you've made changes.
3) Close Fortress and delete the cache folder at %USERPROFILE%\Local Settings\Application Data\SourceGear\Fortress_1\Client (the folder with a name that looks like a guid)
4) Manually edit each project file (not the .sln file) and remove 4 lines that look like:
<SccProjectName>...
<SccLocalPath>...
<SccAuxPath>...
<SccProvider>...
5) Open the solution in Visual Studio with the source control provider set to Fortress and re-bind the solution.

You will need to resolve any files marked "Needs Merge" and any renegades, etc., but this will get you there. If you have a bunch of solutions to convert, you can repeat steps 1 & 2 for each solution, then delete the cache folder once, then repeat steps 4 & 5 for each solution.

Good luck, and I hope this helps the folks at SourceGear figure out why this doesn't work the way it should.

Edited: Clicking "Yes" when prompted to "Permanently Remove Bindings" does not effectively remove the bindings. Certain project types are not fixed, and if you have a project that is included from another location, for example a Utility library that is bound to source control under its own solution as well as being a project reference in other solutions, then that project will also have its bindings removed, even if they've already been corrected. So, I believe manually removing the bindings is the only safe way to do this.

[ian_sg]

I'm glad to hear you got it working, though I'm sorry it was so difficult.

I would like to investigate, but as mentioned yesterday, we were unable to reproduce the behavior you described. Did you have logging turned on when you had these difficulties? Would you mind sending that to me? You can email it to ian at sourcegear dot com.

Thanks.

[Nihimon]

Sent.