Unable to Retrieve Project - Please Help!

[lbauer]

I haven't been doing very well on my estimating, so I hesitate to give another date. It is scheduled for the next maintenance release of SourceOffSite.

[BrianDrab]

Probably a smart move. Thank you.

[jclausius]

Brian,

I've been working on these issues related to files outside a solution folder for the IDE client.

I'd like to go over a scenario:

If I set up a solution w/ a C# based app, and a Setup project ALL under the same solution folder, and then ADD a file to the Setup project in the App dir from a directory OUTSIDE of the solution, I can add this with the SOS 5.0.1 client. Visual Studio will create a "mapping" for the "Longest Common Path" (LCP). Once added, that user can use the solution just fine.

However, if I do an OPEN from Source Control as a *different* user, the paths for the LCP become mangled by Visual Studio. All files are retrieved except files from OUTSIDE the solution. I tried a copy of the exact same project using Visual SourceSafe, and obtained the same results. Something within Visual Studio, not the IDE client is causing the names to be mangled.

I am going to have QA verify my results, but could you look over the configuration of my solution? Does my description match the behavior your are seeing? If you've tried it with a VSS client on a machine which has local access to the VSS database, does it give you the same results?

[BrianDrab]

Brian,

I've been working on these issues related to files outside a solution folder for the IDE client.

I'd like to go over a scenario:

If I set up a solution w/ a C# based app, and a Setup project ALL under the same solution folder, and then ADD a file to the Setup project in the App dir from a directory OUTSIDE of the solution, I can add this with the SOS 5.0.1 client. Visual Studio will create a "mapping" for the "Longest Common Path" (LCP). Once added, that user can use the solution just fine.

However, if I do an OPEN from Source Control as a *different* user, the paths for the LCP become mangled by Visual Studio. All files are retrieved except files from OUTSIDE the solution. I tried a copy of the exact same project using Visual SourceSafe, and obtained the same results. Something within Visual Studio, not the IDE client is causing the names to be mangled.

I am going to have QA verify my results, but could you look over the configuration of my solution? Does my description match the behavior your are seeing? If you've tried it with a VSS client on a machine which has local access to the VSS database, does it give you the same results?

I would be happy to however I will need the answer to a few questions first.

1. You say you set up a Solution w/ a C# based app, and a Setup project ALL under the same solution folder, and then ADD a file to the Setup project. When you are adding the file to the Setup project, was the rest of the project already under Source Control?

2. When you say open from Source Control as a different user, do you mean a different user on the same macine, a different user on a different machine, both?

3. When you ask if your description mathes the behavior that I am seeing, do you mean when I first posted this or do you mean as it stands now with 5.0.1?

[jclausius]

1. You say you set up a Solution w/ a C# based app, and a Setup project ALL under the same solution folder, and then ADD a file to the Setup project. When you are adding the file to the Setup project, was the rest of the project already under Source Control?

No. When you reference a file OUTSIDE of the solution, the entire solution has to be ADDED and nothing should be currently under source control. This is a limitation of Microsoft's design. It turns out when an outside file is referenced, Visual Studio will change the VSS paths to the files. It will compute an LCP, and then place that ENTIRE path within the VSS database. If a project is under source control, the paths will already be set, and this configuration will fail.

2. When you say open from Source Control as a different user, do you mean a different user on the same macine, a different user on a different machine, both?

Same machine. Different VSS user.

3. When you ask if your description mathes the behavior that I am seeing, do you mean when I first posted this or do you mean as it stands now with 5.0.1?

If you were to try it with VSS or with SOS 5.0.1, you should see everything under source control, except the file which falls outside of the solution folder after you shutdown and restart Visual Studio. And, this would be the case with VSS as well as SOS 5.0.1

Note, my testing was on VS 2005, and I will be investigating to see if there are differences in VS 2008.

[jclausius]

Brian:

I've figured what I think may be a solution with SOS 5.0.1.

Here is my setup:

d:\projects\proj1 - main solution folder
d:\projects\proj1\proj1 - main c# based app
d:\projects\proj1\setup1 - main setup project
d:\test\file1.txt - file outside of the project, included in setup1.

1) I added everything through SOS.

2) I received the warning regarding the longest common path (LCP) for d:\. And I do believe one restriction will be that the files outside of the solution must at least be on the same drive. At least they are for this example.

3) Added everything to SOS under $/x. This created a repository which looked like the following:
$/x/proj1.root/
$/x/proj1.root/proj1/ - MAPPED to D:\
$/x/proj1.root/proj1/projects/
$/x/proj1.root/proj1/test/
$/x/proj1/root/proj1/projects/proj1 (contains proj1.sln)
$/x/proj1.root/proj1/test/file1.txt
$/x/proj1/root/proj1/projects/proj1/proj1 (contains proj1.csproj)

4) I edited the .vdproj file with a text editor. If you notice, the .vdproj is full of absolute paths to files. In order for Visual Studio to find the files, the paths must be relative paths, like "linked files" in other project types. So, d:\test\file1.txt became "..\\..\\test\\file1.txt" and then checked in the file.

5) Next, as a DIFFERENT user on a different machine, I opened up SOS, and set a working folder of C:\ to $/x/proj1.root/proj1/, and then closed the client.

6) Then, I opened VS 2005, verified the source control option was set to SourceOffSite 5 client, and then ran a File -> Open From Source Control. This brought up a repository view, and I chose, $/x/proj1.root/proj1/projects/test/proj1, and clicked OPEN. This prompted me for a couple of logins for the different projects, and when completed the entire project (including the setup files) were on disk. Subsequent opens from within Visual Studio can be made at c:\proj1\projects\proj1\proj1.sln. The "linked" files were found at c:\proj1\test\file1.txt.

In the end, if you are going to work with projects which fall outside your solution, you will need to re-add them so Visual Studio can re-map things with the LCP and create repository paths which can virtually map those items to a path on disk found under the entire solution. The behavior of this layout is controlled by Visual Studio, and details can be found at http://msdn.microsoft.com/en-us/library ... 71%29.aspx

[BrianDrab]

jclausius -

I'm unable to reproduce the "mangling" of the LCP that you mention. I've signed on to the same machine with a different user and VSS is able to retrieve the project without a problem. If I however attempt to use SOS to retrieve the project, we get the Plugin error that I mentioned previously and Visual Studio completely crashes. Our developers are very frustrated.

Capture.JPG (24.69 KiB) Viewed 18552 times

It's easily reproducible. I created a VB Windows Project named SOSTest and added a Setup package as another project. I then added a file OUTSIDE the working patch to the setup project. Then I added to Visual Source Safe.

So basically I have this:

SOSTest Solution
...SOSTest Project
...SOSSetup
.......In the file editor I'm picking an icon file from c:\images

[jclausius]

What do the contents of the .vdproj file look like? Did you edit the path as I did above and then try to add it using SOS (as above)?

I agree it is a pain, and I'm trying to find the quickest way to get this kind of setup configured.

[BrianDrab]

The Source path looks as follows:

"SourcePath" = "8:C:\\Images\\favicon.ico"

I didn't create it as a relative path and test it. I wasn't sure what to change it to.

Maybe you can do a quick support session on my machine and show me. It may be easier.

[jclausius]

What is the location of your .sln and the location of the .vdproj.

Also, if you do not want the info on a public forum, send mail to support at sourcegear dot com, and mention my name along with the title of this thread.

Thanks.

[BrianDrab]

Following is the directory structure.

Solution File Location
c:\Dev\VSS\Develop\Visual Basic .NET 2008\SOSTest Solution\SOSTest Solution.sln

Project#1 Location
c:\Dev\VSS\Develop\Visual Basic .NET 2008\SOSTest Solution\SOSTest

Setup Project Location
c:\Dev\VSS\Develop\Visual Basic .NET 2008\SOSTest Solution\Setup1

Icon File Location
c:\Images\favicon.ico

[jclausius]

I don't remember which, but the files will be in the format of:

a) a relative path in relation to the .vdproj. In that case, it would be ..\\..\\..\\..\\..\\..\\Images\\favicon.ico
or
b) a relative path path in relation to the .sln. In that case it would be ..\\..\\..\\..\\..\\Images\favicon.ico

The first thing to do is make sure the path is correct. If you start with all projects unbound, and make the change to the .vdproj, see if you can re-open the solution, without any errors. Once it opens and all files are in the project, you'll know the relative path is correct. Then try the ADD to see if it makes it in. Once added, an OPEN (just one time only) from a different computer should get the files. Note, subsequent "opens" of the solution will just be made by opening the .sln from disk.

[BrianDrab]

I don't remember which, but the files will be in the format of:

a) a relative path in relation to the .vdproj. In that case, it would be ..\\..\\..\\..\\..\\..\\Images\\favicon.ico
or
b) a relative path path in relation to the .sln. In that case it would be ..\\..\\..\\..\\..\\Images\favicon.ico

The first thing to do is make sure the path is correct. If you start with all projects unbound, and make the change to the .vdproj, see if you can re-open the solution, without any errors. Once it opens and all files are in the project, you'll know the relative path is correct. Then try the ADD to see if it makes it in. Once added, an OPEN (just one time only) from a different computer should get the files. Note, subsequent "opens" of the solution will just be made by opening the .sln from disk.

OK, for future reference it was a) relative to the .vdproj. Unfortunately it did NOT work. Following is what I did as well as the results.
1. All projects were unbound and nothing was in Source Safe.
2. I modified the .vdproj of the setup project and change the absolute path to relative. The before and after lines are as follows:
Before: "SourcePath" = "8:C:\\Images\\favicon.ico"
After: "SourcePath" = "8:..\\..\\..\\..\\..\\..\\Images\\favicon.ico"

3. I was able to reopen the solution without issue.
4. I then selected File....Source Control...Add Solution to Source Control
5. Immediately I got an error about the path and the .vdproj file was changed to show the absolute path.

[jclausius]

From my note, I was testing under VS 2005. I'm not proposing this as a solution (to use VS 2005), but can you try the same test there? I'll see what I can find under VS 2008.

[jclausius]

Brian,

Let's try the SAME test under VS 2008. Please follow my steps in your environment:

1. Created a BLANK solution named Sol1. I placed it on my disk (D:\Test\BDrab), in which VS created D:\Test\BDrab\Sol1 -> which contained the .sln and .ncb
2. Added a NEW Win32 based project, and I placed it under D:\Test\BDrab\Sol1, in which VS created D:\Test\BDrab\Sol1\Proj1 -> which contained the project file as well as the project's source files.
3. Added a NEW SETUP project, and I placed it under D:\Test\BDrab\Sol1, in which VS created D:\Test\BDrab\Sol1\Setup1 -> which containded the .vdproj as well as the other setup project files.
4. I next added D:\Outside\file.txt to the Setup project's application folder.
5. Saved everything within Visual Studio.
6. Went to Tools -> Options -> Source Control to ensure SourceGear SourceOffSite 5 client was the SCC provider.
7. Next invoked the context menu on the SOLUTION, and did an Add to Source Control. It asked me to log in, choose a place for Sol1.root, and then gave me the "LCP" warning. Everything was added and appeared under version control, and I closed VS.

Next to simulate a DIFFERENT user, I :

1. Started the SOS GUI client. Found the place where I added Sol1.root. It appeared as well as a "path" under Sol1.root for \Test\BDrab\Sol1\ as well as \Outside\.
2. Next, I checked out and edited the .vdproj by hand, changed D:\Outside\file.txt to ..\\..\\..\\..\\Outside\\File.txt. Saved the file and checked it back in.
3. Finally at Sol1.root, I removed all working folder properties as well as cleared working folders for the sub-folders. This was done in order to simulate a "new" user opening the project.
4. Closed the SOS GUI client
5. And deleted D:\Test\BDrab\Sol1 from disk as well as D:\Outside\file.txt.
6. Started VS
7. File -> SourceControl -> Open From Source Control
8. Logged in, and chose to open $/Sol1.root/Sol1/Test/BDrab/Sol1, and ALSO set a working folder to D:\ at the bottom of the dialog.
9. I clicked OK, and It prompted for some log-ins, and opened within VS.
10. Everything opened within VS 2008.
11. I closed VS 2008, and re-opened D:\Test\BDrab\Sol1\Sol1.sln, and it opened within VS 2008, and all files could be used within Source Control.

Note, in the step above where I assigned D:\ to a working folder, you can use any directory you like (say D:\XYZ), but it will re-create the paths on disk relative to that Working Folder and you would be working with D:\XYZ\Sol1\Test\BDrab\Sol1 and the file D:\XYZ\Outside\file.txt