Visual Studio: Get Latest on Web Site project misses files

[cpoirier]

I have Visual Studio 2013 setup with SourceGear Vault Client 6.1.0 integration, and the option "Get everything when opening a solution or project" enabled. When I open a Web Site project, the Get Latest dialog appears and I click OK, but newly added folders/files will not get downloaded onto my computer.

I suspect what is happening is:
- There is a local solution file on my computer that contains the list of files/folders for the web site.
- On loading the web site, it does a get latest based on the list of files in the solution file, which doesn't contain the new folder yet.
- If it instead did a get latest version based on the root folder of the web site in Vault, it would get the new folder/files.

The issue can be worked around by:
- Get latest version on the root of the web site from Visual Studio after the project has opened.
- This will get the files from Vault, but they won't show up in the solution explorer yet.
- Do a refresh of the solution explorer to see the new files.

Is there something that can be done to fix this situation without having to do the work-around?

[Beth]

When opening things in Visual Studio, VS reads the .sln and .proj files to determine what to download. If the items are not listed in those two files, a Get command is never sent to Vault on those items.

When adding things to a source controlled project, it's better to add them to the solution or project while they are open in Visual Studio. Then VS will send a command to Vault to add them.

For adding after they are already in Vault, you need to create any new folders with the exact name as in Vault. Then you can use the Add Existing Items and VS will recognize that the files are already in. You can't just add a full folder with all its files at once in VS.

[cpoirier]

Hi Beth,

This is basically what I had described in my post, but Visual Studio handles web sites different from other project types. If this was a class library, console application, or anything else that's opened as a "Project" in Visual Studio, then your solution is correct, and this is what we do here for these types of projects. However, the project in question is opened as a Web Site in Visual Studio, which means that the project file is saved elsewhere and is not in Vault; Visual Studio opens this from Vault as a directory, not by directly referencing a .csproj/.sln file.

It seems like there could be an improvement to the Vault integration so that when opening a Web Site, it gets everything in the directory that was opened; and for other project types, it would get the files based on the list in the project file.

In the meantime, it seems like if we added the web site project file to Vault and just used "Open Project" instead of "Open Web Site", that this would resolve the issue. Would you agree?

[Beth]

The thing with VS integration is that there is a set interface that third parties connect to which determines how this works.

If the solution is really just a website and not a web application, then it will not have any type of .proj file, but only a .sln file. Do you know if the solution file is in Vault and is a bound file?

Are you using the Vault Classic or Vault Enhanced client from inside Visual Studio? That can be found in the VS Tools - Options - Source Code Control - plugin.

[cpoirier]

This is a web site, the solution file is in my Documents/Visual Studio 2013/Projects/ directory, and it's not in Vault. We're using the standard client. The solution file does contain some source control related settings:

SccProjectName = "$/path/to/web/site"
SccAuxPath = ""
SccLocalPath = "."
SccProvider = "MSSCCI:SourceGear Vault Standard Classic Client"


SccNumberOfProjects = 1
SccWebProject0 = true
SccProjectUniqueName0 = http://localhost/web/site/
SccProjectName0 = $/path/to/web/site
SccLocalPath0 = d:\\lawdepot_com\\pubroot\\web\site\
SccProvider0 = MSSCCI:SourceGear\u0020Vault\u0020Standard\u0020Classic\u0020Client
CanCheckoutShared = false
SccProjectEnlistmentChoice0 = 2

There is also a .suo file in the same directory.

[Beth]

I tested a website with the Classic Client and it picked up on the files that were in it's directories, but they were on disk. Can you perform a Get on the new times from Vault and then open your website?

I will wipe out the website on disk next and try again.

[cpoirier]

Yes, doing a get in Vault client and then opening in Visual Studio works. I can also manually do a Get Latest Version in Visual Studio and refresh the solution explorer to see the new files. It's only when Visual Studio automatically does a Get Latest Version when loading the web site that I'm not getting the new files.

[Beth]

I just ran a test with no files on disk, and files in Vault. I used the Open Website and selected Source Control, and all my files came down and it picked them up for being controlled.

Might need to take a closer look tomorrow morning if it doesn't work that way for you.

[cpoirier]

This is not quite what I'm doing. You're opening the website fresh, which does work for me. To test my situation:
- On your computer, close Visual Studio.
- On another computer or as a different user, open the web site and add a folder and a file within it. Close Visual Studio.
- On your computer again, open Visual Studio and open the web site from Local IIS (not from source control). This will do a Get Latest Version when opened, but will not get the new folder/file.

[Beth]

On Step 2, are you opening it from disk or from Vault? Is the project bound to Vault and do you check in the newly added folder and file?

[cpoirier]

On step 2, the project would be opened from Vault, and it is bound to Vault, and the new folder/file are checked in.

[Beth]

Now I've reproduced it. I need to look at this a bit more to see what is happening.

[cpoirier]

Hi Beth,

Do you have an update about this issue?

[Beth]

I hadn't found a way to deal with it without the .sln file involved as of yet. If one treats it like a web project and everyone uses the .sln inside Vault, then it does load new stuff.

I also logged a bug on this.
F: 19581