locked
Unspecified error when doing Get Latest Version RRS feed

  • Question

  • When I do Get Latest Version from within Visual Studio on a complete solution or project I get the following error:

    Unexpected error encountered.
    Error: Unspecified error.
    File: vsee\lib\path\cvapipath.cpp
    Line number: 2459

    When I do Get Latest Version on an individual source file, it works correctly.

    When I do Get Latest Version on a project from within the VSS client, it also works correctly.

    I got the following setup:
    Visual Studio 2005 Team Edition for Developers.
    Visual Sourcesafe 2005
    C# solution containing services, web services and libraries.

    Patrick
    Monday, November 14, 2005 7:56 AM

Answers

  • Hi Jacob,

    The code in cvapipath is generic (does string manipulation for file names), and is invoked from everywhere in the source control package. The only thing I can tell from the error is that for some reason we are trying to unrelativize two paths that cannot be unrelativized one to another (different protocols or 2 paths on different drives, instead of one full-path and one relative path)
    Without more information I really can't tell what's wrong and what are the paths that cause the issue (see my other post for how to obtain a minidump)
    Also, I'd need a description of the solution/web (e.g. what type of web filesystem/localdisk/etc, where is the web, where is the solution, does the web have virtual folders, etc.).
    You can also try to narrow the issue further, by doing a Get one folder at a time from that web project, and you may find one that causes the problem, so we can focus further on what makes that folder different.

    Thanks,
    Alin
    Thursday, November 24, 2005 8:28 PM
    Moderator

All replies

  • Hi,

    I've checked the issue on VSTS(Visual Studio 2005 Team Suite) and I could not see the problem. Could you explain what do you mean by complete solution or project? I will also see if this issue is specific
    to "Visual Studio 2005 Team Edition for Developers".

    Thanks,
    Daniel

    Monday, November 14, 2005 9:41 PM
    Moderator
  • Hi Patrick,

    I'd try narrowing down the issue.
    I understand you get the error when doing GetLatest version on the solution.
    Try doing GetLatestVersion one by one for each project, see if you can reduce it to one project. Then try on groups of files/folders in that project, see if that could be narrowed down even further.
    In one report of a similar exception, Unbinding/Rebinding the solution seemed to help. In other reports (VC project with folder set to SCCFiles=False), toggleing the SccFiles property of the folder was the workaround.

    What could also help is to collect a minidump like described in http://www.alinconstantin.net/webdocs/scc/UnspecifiedError.htm
    and send it to us for analysis...

    Thanks,
    Alin
    Tuesday, November 15, 2005 1:56 AM
    Moderator
  • Hi Alin,

    I am working on a solution with five projects. I get the same error as Patrick when I am doing a get latest on the web project in the solution. All other projects is working fine. If I do a get latest in the sourcesafe application everything is working fine as well. When I try to unbind and rebind the samme error occurs.

    Looking forward to hear from you.

    Thanks,
    Jacob.
    Thursday, November 24, 2005 12:45 PM
  • Hi Jacob,

    The code in cvapipath is generic (does string manipulation for file names), and is invoked from everywhere in the source control package. The only thing I can tell from the error is that for some reason we are trying to unrelativize two paths that cannot be unrelativized one to another (different protocols or 2 paths on different drives, instead of one full-path and one relative path)
    Without more information I really can't tell what's wrong and what are the paths that cause the issue (see my other post for how to obtain a minidump)
    Also, I'd need a description of the solution/web (e.g. what type of web filesystem/localdisk/etc, where is the web, where is the solution, does the web have virtual folders, etc.).
    You can also try to narrow the issue further, by doing a Get one folder at a time from that web project, and you may find one that causes the problem, so we can focus further on what makes that folder different.

    Thanks,
    Alin
    Thursday, November 24, 2005 8:28 PM
    Moderator
  • Hello Alin,

    I am also getting this same error. I have a solution with 12 projects in it (1 ASPNET), and I get the error when trying to Get Latest on the web project itself. I can Get any file or folder listed under the web project, but when the IDE attempts to perform a Get on the web project itself it fails with the same cvapipath error. I have tried re-creating the web application itself in IIS, and it still doesn't work.

    The web application itself is stored locally off of my scc root folder, with a virtual path / application in IIS pointed towards it. I manually checked paths in the solution file and they all seem to be correct.

    What specifically can I send you to give you more detailed information?

    Thanks in advance,
    Randy B
    ICI
    Software Developer
    Thursday, December 1, 2005 5:50 PM
  • Hi Randy,

    See my previous posts.
    I'll need a minidump when the exception is thrown, and a copy of the solution file, plus a good descriptions of the solution structure (where are the projects on disk, in the database, what are their bindings (see Change Source Control dialog), etc.
    Also, if there is something particular for that website, that might help reproduce the problem (e.g. no files in the webroot, or has sub-folders that are virtual folders pointing to what location on disk, etc)

    Thanks,
    Alin

    Thursday, December 1, 2005 7:34 PM
    Moderator
  • Hi Alin,

    Actually, I went ahead and just re-created my solution from scratch (we keep projects under scc but solutions are kept local only) and that fixed the issue. 

    Before I did that, I tried completely removing just the web application from my local system (virtual folder, temp aspnet files, physical files on local disk) and re-adding it to my old solution via "Add Existing Web..." from the vss location.  That did not fix my issue, I still got the same error from a Get on the web project.

    So whatever the problem was, it seems re-creating the solution file fixed it.  This problem occured as a result of a move from VS 2005 Beta2 on one PC to VS 2005 Team Developer on another PC, so it is likely there was something out of sync between the two.

    Thanks,
    Randy B
    Friday, December 2, 2005 12:11 AM
  • Hi,

    I also tried the above solution with success.

    We keep our solutions on the scc hive, I zipped the entire project directory and deleted it. Then went into scc and did a 'get latest version' to the same working directory, when running the solution now I can get the latest version problem-free.

    Thanks.

    Matt W.
    Tuesday, December 6, 2005 9:47 AM
  • Had the same problem every time I added one specific project to the solution; found

    "NUMBER_OF_EXCLUDED_FILES" = "1"
    "EXCLUDED_FILE0" = "c:\\Program Files\\Common Files\\System\\ado\\msado15.dll"

    had somehow got into the vsproj.vspscc file; when I changed it back to

    "NUMBER_OF_EXCLUDED_FILES" = "0"

    the problem went away. Maybe "c:\\Program Files" not being under the solution root was the cause of the problem?

    Friday, January 20, 2006 3:23 PM
  • Hi dealogic,

    > Maybe "c:\\Program Files" not being under the solution root was the cause of the problem?

    Since you mention you edited the *.vspscc file, the cause is likely the file not being under the project's root (not the solution, which uses *.vssscc hint files).

    I've seen the "Error: Unspecified error. File: vsee\lib\path\cvapipath.cpp Line number: 2459" message appearing when one of the excluded files cannot be relativized to the project's folder (e.g. the excluded file was on a different drive from the project)

    Can you tell us what type of project do you have and how did that file excluded (automatically, or did you excluded it when the project was uncontrolled, etc).

    Thanks,

    Alin

    Friday, January 20, 2006 6:41 PM
    Moderator
  • Alin,

    I was attempting to run my version of Visual Studio 2005 as a Debugger as your article explains (http://alinconstantin.homeip.net/webdocs/scc/UnspecifiedError.htm) and was unable to get it to work. I was able to get the Debug->Processes to show up as a menu item under Tools, but it is always disabled and I can't seem to change the settings properly to be able to select this option in Visual Studio 2005 (version 8.0.50727.42).

    I am having the same issue as the others in this post. I can do a Get Latest Version of all projects except the Web Project. I cannot Get Latest Version from the Solution file either. If I Get Latest Version from either the Web Project or from the Solution file I get the following:

    Unexpected error encountered.
    Error: Unspecified error.
    File: vsee\lib\path\cvapipath.cpp
    Line number: 2459

    I did not find that any of my Project files had any Exceptions listed as dealogic posted.

    Any help would be appreciated.

    Mark Dahl

    Friday, January 20, 2006 7:43 PM
  • Hi Mark,

    I suspect the current Profile you're using may have something to do with the command not being available. I'd try using the Tools/Import and Export Settings menu item to import settings from either General Developemnt or Visual C++ Development settings (save your current currnent windows configuration when prompted so you can restore it  back later) 

    Alin

    Friday, January 20, 2006 8:11 PM
    Moderator
  • I am getting the same problem - it occurs whenever getting latest version for a web project (within a solution of several class libraries). 

    I'm going to go and try the minidump you suggest, but i was wondering if there has been any light shed on a solution to this?
    Friday, February 3, 2006 3:33 PM
  • Patrick,

    After following the instructions that Alin offered in his article and sending him a minidump, Alin suggested some fixes for my problem that fixed the issue.

    Here are some things that we changed that fixed things:

    1. Our web project had the same name as one of our VB projects, so we changed the name of the VB project to "Name Client" and our web project to "Name Web"
    2. Because the names were the same, the VB Project's Publish Location (as default) was set to the http://localhost/Name and some of the Web Projects files were being overwritten. We changed the Publish Location of the Client to a network directory.
    3. After we fixed the above and still had troubles, we noticed our .suo files were all different and oddly so, so we placed the .suo file from the working developer's computer. This fixed the problem initially (for one open of the project), but it was broken after that for all other developers. Alin then suggested we remove the .suo file from SourceSafe and remove it from the other developer's computers. While the previous sentance was our last fix for this issue, the next two changes have been required to fix it for new developers as well.
    4. We set the working directory for our web project in SourceSafe to the C:\Inetpub\wwwroot\Name, so that we did not have two directories for the files on our computers. We did this because even after changing the names of the projects, some of the files from one project appeared to be overwriting files in another - these were primarily SourceSafe files themselves which caused the .sln file to be confused when trying to determine changed files in the directory.
    5. We continued to have the same problem with the SourceSafe files and could not figure that out, so we looked at the IIS properties of our web and the Local Path was set to the folder of our VB project, which again was writing over our VB files. We then removed all the files and webs from IIS and from our hard drives (of course we had a backup) related to the Web Project. This did not fix the problem because when Visual Studio added the web, the Local Path was still set to the VB Project folder. We manually set the Local Path in the IIS properties to the C:\Inetpub\wwwroot\Name folder and reset permissions on the folder (as they were wrong too).

    The only sad thing about the above is every developer we add in, the defaults for SourceSafe uses these settings that cause this problem and we have to follow steps 2, 4 and 5 for every developer added to our project. I wish SourceSafe would somehow forget the original setup and use the existing setup for most machines.

    I don't know if this will be helpful for anyone or not, but since Patrick asked for some feedback, I figured I would pass some along.

    Mark Dahl

    Friday, February 3, 2006 5:51 PM
  • Patrick (and anyone else getting this error for web projects),

    A couple of weeks ago I took a look at some dumps Mark kindly provided, and it turned out that in his case the error was caused by a mistake of sharing the <solution>.suo file amongst developpers working on the project. In his case, the suo file was incorrectly manually added to the VSS database and gotten on other developpers machines.

    If you're doing the same mistake, stop! The suo file is NOT supposed to be checked in the VSS database, and is NOT supposed to be shared between different machines (or between different enlistments on the same machine).

    Working with web projects is supposed to be easier: one developper creates the solution with the website and adds it to source control using the File/SourceControl/AddSolutionToSourceControl menus, and all other developpers are supposed to open the solution from source control using the File/Open/Project/FromSourceControl. VisualStudio will take care of creating the necessary web projects enlistments, creating virtual folders in IIS, and the current enlistment paths will be stored in the suo file for future openings of the solution.

    Also, once VisualStudio has created an enlistment, altering the location (e.g. using IIS to "retarget" the website to a different folder) will invalidate the data from the suo file, causing mismatches between where VisualStudio thinks a project should be and where it is in reality, and will cause VisualStudio to display "unspecified error" messages. If you ended up doing this you should reopen the solution from source control and let VisualStudio manage the web enlistments locations.

    If you think you've done nothing described above, you can send me a minidump of the error (see here how to get it http://www.alinconstantin.net/webdocs/scc/UnspecifiedError.htm), and a copy of your solution (sln) and solution options file (suo) and I can take a look what's wrong.

    Thanks,

    Alin

    Friday, February 3, 2006 8:56 PM
    Moderator
  • Ok,

    Thanks for the help - this wasn't my problem, but it did point me towards the solution.  We have just installed VS 2005 and sourcesafe 2005.  We converted out solution to .net 2.0 last week and added it into the new source control DB.

    Our solution has a structure something like this:

    Solution file and class libraries: C:\Work\Dev
    Asp.net web site: C:\Work\DotNetWeb
    Asp web site: C:\Work\AspWeb

    When I initially got the latest version of the solution from source control, the bindings had been lost, so the web projects were created under the same root directory as the rest of the solution - to solve this, I deleted the local web files, changed the binding in source safe and got the latest version of the two projects individually - this must not then have been recorded properly with the rest of the solution.  This was when we started having problems in getting the latest version through the IDE.

    I deleted all the local files, got it all again from source safe (this time with the correct bindings from the start) and the problem has been solved.  I don't know if this is a bug, but possibly a more enlightening error message might be useful...

    Incidentally, i haven't been able to find a .suo file under any of the project directories in our solution - where should this be?
    Monday, February 6, 2006 9:51 AM
  • Patrick,

    Your .suo file is normally in the same directory as your solution file. As long as it is not in SourceSafe you should be okay - as Alin said in his earlier post. This file is user specific from what I understand.

    As far as whether this is a bug or not, we found it annoying that after fixing all our troubles SourceSafe still defaulted to the solution file's original structure when we added another developer to the project. Since all the other developer's have the same setup for where their local files are kept, why does SourceSafe assume something else when another developer (computer) is added to the mix. At least we know what is happening now (files from two projects end up in the same folder) and we know that the only way to fix it is with VSS 2005. We had to install 2005 (and remove the previous version) on the new developer's computer. Then in VSS 2005 we had to set all the working folders for our web and other files manually - this is partially because we were using the wwwroot directory to store the local copies of the web files, although this is not the only problem. Do an initial Get Latest Version from VSS and then the files seem to line up okay after that. Now that we know the problem, it can be fixed in about 30-60 minutes, but a lot of work, when you would think that VSS would default to all the other developers' settings before defaulting to place two seperate project files into the same directory.

    Hope that helps anyone else out there.

    Mark Dahl

    Monday, February 6, 2006 5:12 PM
  • Mark,

    SourceSafe does not assume anything about your solution structure.

    The structure created in the VSS database when adding a project to source control is created by the source control integration package. The idea is to group all connections belonging to a solution under a common .root folder. The default structure resembles as much as possible something like

          $/Solution.root/SolutionConnectionAndLocalDiskWebSites/

          $/Solution.root/HttpWebSite1/

          $/Solution.root/HttpWebSite2/

    When opening from source control a solution, on a new machine the default local structure is established by the web projects package. They tell scci to place the files in websites as local subfolders of the solution, and for http websites they create virtual folders in IIS pointing to the local folders (subfolders of the solution).

    All these defaults can be changed, but you should have a good understanding of how to use ChangeSourceControl dialog (as a replacement for AddToScc), and how to pre-create the websites on a new machine to force during OpenFromScc the web projects package to place the web files in the desired location. Since this is not very well documented, I'd recommending going with the defaults...

    The scc integration does not use VSS's working folders. As much as possible, you should NOT mix scc integration with commands done from VSSExplorer. Recursive Gets done from .root folder are most of the times wrong.

    Alin

    Monday, February 6, 2006 7:53 PM
    Moderator
  • Alin,

    As I had stated previously, intially we had a WebProject named 'X' and a VBProject named 'X' as well. We changed the names of these projects as follows: WebProject 'X Web' VBProject 'X Client'. The intent was to be sure that files from both projects did not end up in the same folder. However, anytime we use the VS2005 (Visual Studio) to do a get of the project, the folders (even though the name is changed) places files in the same 'X' directory under the root solution folder. VSS 2005 (SourceSafe) defaults the folder mapping to place the Web and VB Project in the same folders as well. I would think that the solution would default to go to a folder named 'X Web' or 'X Client' instead of 'X' for both cases. We even manually moved the 'X Web' files into a 'X Web' folder within VSS 2005 and there are still defaults setup with the 'X Client' project to post to the wwwroot folder of the Web Project - this is after changing the Project file in VS2005 to use another web folder and checking that in.

    My reasons for continuing to give information about this situation is to let you know that there is still a problem. All developers are working fine now, but we have had to go through the steps mentioned in the previous post to get any new developer fully involved in this project.

    Mark Dahl

    Monday, February 6, 2006 8:17 PM
  • Mark,

    > However, anytime we use the VS2005 (Visual Studio) to do a get of the project, the folders (even though the name is changed) places files in the same 'X' directory under the root solution folder.

    During open from source control, the web project package always generates the name of the default location based on the "original path" that's stored in the solution file. While that can be changed manually, I wouldn't recommend it.

    Instead, I would suggest regenerating the solution file. I'd probably start by deleting one of the solutions files from the local drive (on a machine that has the projects 'X Web', "X Client" in the desired configuration), add the projects to the solution (the projects will likely be controlled), then use the File/SourceControl/ChangeSourceControl dialog to bind the solution file in the right location in scc database (and if necessary the rest of the project). Ok the dialog, accept any prompts, etc, checkin, and I think the next time a new user will open the solution from source control and will enlist in the solution you will not have all these problems of having to rename the projects/webs.

    Alin

    Monday, February 6, 2006 9:42 PM
    Moderator
  • Closing Visual Studio and Deleting .sou file worked for me for 2 different "Unspecified Errors" . One for the error being discussed here and the other was when we Select File->Source Control->Change Source Control from the Menu of Visual Studio.

    -Pankaj

    Tuesday, February 7, 2006 11:01 PM
  • Deleting the *suo file is NOT what you should be doing. Do that and you're on your own with the support...

    By trashing the suo file you are discarding the translation table for web projects (and if you use TFS provider also for projects on different drives). Without the translation table, the IDE will build the original web project as referenced in the sln file (how it was for the first user that added the solution to source control).

    If you're lucky, your solution may still open and build. However, you may build unknowingly the wrong website (possible another coworker's enlistment).

    If you're unlucky, the original website may point to a machine that doesn't exist anymore, or to a location where there isn't a website on your machine. The web project will appear as unavailable and solution build will fail.

    The rule is DON'T DELETE the suo files, and DON'T SHARE them between different users/machines/enlistments. You should instead use OpenFromSourceControl and let the IDE recreate the suo and establish correct enlistments for the websites. 

    Alin

    Tuesday, February 7, 2006 11:18 PM
    Moderator
  • I agree its not the recomended solution but in our case it was last resort and works smooth (just an easier option than recreating the whole solution again). We do not share sou files but we do create our virtual directories in IIS manually as initial setup. Then the first time we open project from source control (when it builds sou file) it warns us of finding an existing website at the locaiton specified in solution. We select to overwrite files and it works great. All developers in team have exact same setup (virtual directory paths) on their machines so the paths in Solution file works same for all. We have had this setup for 2 years now and it has been working great except for these upspecified errors that seem to come up randomly (have not been able to pinpoint a pattern yet) since we migrated to VS 2005 when it was released.

     

    Wednesday, February 8, 2006 12:40 AM
  • I run into this issue every few weeks.  Removing all *.scc files from your working directories and refreshing the files from VSS fix the problem.

    1. Close VS 2005 & VSS 2005 client.
    2. Search your working folder for all *.scc files.
    3. Delete all *.scc files.
    4. Open VSS 2005 client and get all project files recursively.
    5. Open VS 2005 project.
    6. You should be able to Get Latest now.

    -Rick

    Thursday, May 11, 2006 7:24 PM
  • Hi Rick,

    Your "solution" should not be a recommendation for other users.

    Deleting *.scc files can get you into trouble later. Here is what you can "achieve" by doing this:

    - checkout local version will be broken, so if you had files changed without being checked out, you'll either lose your changes or other team mate changes

    - undo checkout on files already checked out will have to get you latest version instead of the version you started modifying

    - synchronizing files deleted and renamed on server will be also broken

    - Get... command will get all the files instead of only the files that have newer versions in the scc database.

    - deleting mssccprj.scc files can cause your projects/solutions to be uncontrolled next time you open them in VS, so you'll have to rebind them to scc.

    Deleting *.scc files (created by Sourceafe, therefore VSS specific) is not the way to resolve "Unspecified error" messages from scc integration (which is probably why you run again into this issue again every few weeks). That message means the integration code has some conflicting settings. My suggestion is to reopen the solution from source control, and if you have web projects in your solution, don't mess around with their location on disk or in IIS after the solution was open from scc.

    Alin

    Thursday, May 18, 2006 6:44 PM
    Moderator
  • Recreating the solution and adding the projects back one-at-a-time worked for me as well.

    Thanks for the help, guys!

    /BB
    Tuesday, August 29, 2006 4:54 PM
  • Just delete the .suo file and re-open the solution. It should work now.
    • Proposed as answer by SM-Updated Monday, November 1, 2010 2:02 PM
    Thursday, May 24, 2007 3:42 PM

  • Hi there,

    I had the same problem and simply deleting my solution's .suo file worked for me.

    Hope this helps,

    Max.
    • Proposed as answer by SM-Updated Monday, November 1, 2010 2:02 PM
    Friday, September 28, 2007 1:36 PM
  •  

    Hi Everyone,

     

    I had the same problem to the one mentioned in the beginning.

     

    What you can also try doing before deleting any files:

    1. Go into IIS on the website/virtual directory of the project go in to properties.
    2. Under the Virtual Directory Tab. In Application Settings, just click remove and then add the application again.

    This fixed my problem, without having to remove any files. Seems that it was something to do with the projects binding in IIS that caused my error.

     

    Anyway, good luck.

     

    Nick

     

     

    Wednesday, November 7, 2007 10:14 AM
  • We also had a similar issue, deleted the .suo file and the problem went away.

    Friday, January 25, 2008 4:46 PM
  • Be careful if you try fixing this by deleting the suo file though...

     

    I think I've seen one case when such unspecified error appeared because the translation path in the suo for web projects was not corresponding anymore with the reality. The web project in IIS was http://localhost/Project, which was a virtual node pointing to a folder like C:\Project. The user decided to move the project files from C:\Project to another folder, say C:\MyProject\Project, and fix the virtual folder in IIS to point to the new folder. All looked good except that the C:\Project translation path (where the enlisment used to be) stored by source control in suo file was not maching anymore the reality and caused UnspecifiedError messages.

     

    Deleting the suo file might fix the problem or not, but it might introduce other problems. You'll miss the translation path, in the suo, which means VS will try opening the web project using the path specified in the sln file. This may succeed, or may fail (if your enlistment was created in a different location); if you succeed you may unknowingly be opening another developer's website instead of your enlistment, and you may be overwriting other user's changes. Make sure the web project that was opened is indeed your web project enlistment - if not, I suggest reopening the solution from source control.

     

    Alin
    Friday, January 25, 2008 7:31 PM
    Moderator
  •  Hi...

    I got follwing error

    ========================
    The solution appears to be under source control, but its binding information cannot be found. It is possible that the MSSCCPRJ.SCC file or another item that holds the source control settings for the solution, has been deleted. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control.
    ==========================

    i tried to change "source control of this project" but it dosen't worked.all options in this change source control dialog box are disabled.so how can i bind this project with the database......?

    ================================

    one more question==

    from where we can add .vss and .scc files into the project.

    i search for this files in my project but this files are not found in my project


    what can i do....

    ===============================


    please reply me.......

    i m in troble because of this error..

    waiting for u r reply..

    Thanks in Advance....
    Monday, September 29, 2008 5:59 AM