Many people like to integrate Source Control in VS.NET IDE.
Here are some common issues related to integrated VSS in VS.NET IDE.
What benefits will VSS and VS.NET IDE?
benefit:
(1) CHECKOUT / Checkin can be directly in the IDE.
(2) When you open the Solution for the first time on a new machine, you can automatically create an IIS virtual directory for Web Project.
(3) VS.NET automatically judges that the files whose users are not added to VSS, such as SUO, *. VBProj.user, etc., avoiding problems that cause mutual interference from individual environments after manually adding these files.
(4) The file rename is particularly convenient, especially when the ASPX file is changed, and the ASPX.vb and related RESX files in the VSS can be renamed.
Disadvantages:
(1) VS.NET's Source Control Add-in has bugs, often errors, especially when adjusting the Solution structure. The correct Folder rename operation step is complicated, so adjusting the Solution structure is particularly troublesome.
(2) Operation is more careful, there is a certain training / learning cost.
(3) When you open the Solution, because you need to communicate with the VSS Server, the speed is slow, and the network bandwidth and server resources are taken.
(4) The working directory of the web project is always under WWWROOT, which is inconsistent with the project hierarchies in SourceSafe.
(5) Want to temporarily modify a file debugger, especially inconvenient (because prompt should checkout), especially modifying the Project file (for example, when a temporary file test is added).
(6) Creating a project, when the first add to source control, VSS will automatically create a VSS Folder with the Solution of Solution, such as: Originally wants to add purchase.sln below $ / ... / src, but the result Yes Add to $ / ... / src / purchase. For Web Project, when Open from Source Control, the working directory becomes subdities below INETPUB / WWWROOT, and the working directory of the people who create Project is originally in a directory below ... / src / below.
(7) VS.NET has many bugs, resulting in error or inconvenience. such as:
In the Change Source Control dialog, a few Projects are often bundled together, selecting one of the other several, and cannot set the binding road.
When UNBIND, it is often unable to select, so it is very difficult to prepare an independent, unbound development environment.
When Check IN, sometimes some unconnected files, let you choose whether Check IN, but in fact, those files do not have Check Out at all.
Want to bind VSS to vs.net IDE, what must you prepare?
(1) Install the VSS client
Installer on the file server: // Xafile / Share / MSDN / VSS / EN / VSS60D
CD Key: 111-1111111
(2) Delete IIS VDs that may be renamed
This machine IIS is best not available to the VD (virtual directory) of yourself, otherwise, you may be prompted when you open the SOLUTION. The working directory of VD_1 is prompted. In addition, INETPUB / WWWROOT below the same name directory is also deleted, so as not to go wrong, although this case VS.NET does not prompt the VD_1 style working directory.
(3) Open Solution from VS.NET, must be opened directly from the local hard drive by selecting the File - Source Control - Open from Source Control command, you cannot use the traditional method GET directly to open from the local hard drive, otherwise IIS VD will not be created automatically.
How can a Solution that have not been bound? How can I achieve the binding correctly?
Insurance practice:
(1) Get an empty Solution from the Solution of All Projects from the Solution.
(2) Use VS.NET File - Source Control - Add to Source Control Command
Note: In the Add to Source Control Project dialog, the default has a Project name, such as SOLUONNAME.ROOT, you should empty this content, otherwise you will see the Directory Structure of $ / SolutionName.Root / SolutionName in VSS.
(3) Add the original Projects to Solutions with the add existing project command.
(4) Check in those add incoming Projects.
At this time, VS.NET will prompt the RESX file to encode UTF-8, which cannot be changed with VSS control, etc., do not use it.
What files in the Solution changes before and after the binding? What did you have any files that have not been generated?
(1) Key to change only SLN files, will add a globalsection after the original content, such as:
Global
GlobalSection (SourceCodecontrol) = PRESolution
Sccnumberofprojects = 53
ScclocalPath0 =.
Cancheckoutshared = false
SolutionuniqueId = {EFD7F1A3-3977-4BE8-AFFC-D33AB7D8546C}
Sccprojectuniquename1 = ..//../Webframework//src//frameworks.etp
SccProjectName1 = / u0022 $ / webprojects / webframework / src / u0022, / u0020j ...
SccLocalPath1 = ..//../webframework//src
Cancheckoutshared = false
......
Endglobalsection
Endglobal
(2) There is no substantive content that automatically generated Solutionname.vsscc files.
(3) Automatically generated ETPNAME.VSPSCC or ProjectName.vspscc files do not have substantive content. It is important to look at it:
"Project_file_relative_path" = "relative: windowsapplication1"
(4) VBProj files increase a small amount of new content.
ProjectType = "local" ProductVersion = "7.10.3077" Schemaversion = "2.0" ProjectGuid = "{F894CF6B-BAC2-4F54-ACFA-DF317FFBBDBE}" Sccprojectname = "SAK" SccLocalPath = "SAK" Sccauxpath = "SAK" SccProvider = "SAK" > The red word part is new, nor is it important. These contents may lead to "Seem to Be Under Source Control But ..." in the future. With VBProj files, a * .vbproj.Webinfo file will be generated in the local directory, the content is: It seems more important, but it has not been found to cause problems due to this file. note: SccProjectName in the C # project file (csproj) is not "Sak", for example: Sccprojectname = '"$ / webprojects / webframework / src / applicationblocks", kgbeaaaa' This is very different from the VB.NET project. (5) The ss.ini file may have change, which is the root of many problems, so it is especially be careful! SS.INI is a VSS personal profile, this file is in the VSSDB / DATA / TOE / Directory. Its content is mainly SSEXP current project, window status, etc., more important content is the local working directory corresponding to each VSS Folder / Project. Pay special attention to check if there are several lines in this file after Open From Source Control. Among them, Web Project will definitely change the working directory, it is still normal. such as: [$ /] DIR (XA-App-Luo2k3J) = C: / MProject [$ / WebProjects / Purchase1.0 / src / purchase / purchaaseservice] DIR (XA-App-Luo2k3J) = C: / INETPUB / WWWROOT / LeyService / PurchaaseService [$ / WebProjects / Purchase1.0 / src / purchase / ApplicationUi / LeySerWeb] DIR (XA-App-Luo2k3j) = C: / INETPUB / WWWROOT / LeySerWeb The above two Projects are projects of the ASP.NET Web Application or Web Service type, so there is no problem. If other types of Project work directory also appear in this file, for example: [$ / WebProjects / Webframework / src / OtherFrameworks / NHibernate] DIR (XA-App-Luo2k3j) = C: /Study/asp.net/orm/nHibernate/src/nhibernate [$ / WebProjects / Purchase1.0 / src / purchase / dataAccess] DIR (XA-App-Luo2k3j) = C: /WebProjects/purchase1.0/src/purchase/dataAccess There is no Web project in the two directories (NHibernate and Purchase.DataAccess.order), there is two questions, there are two reasons for problems: l SLN files include Source Control binding information in a directory that does not exist at all. This Project is existing, but is not in the directory described in the binding information. l SLN or ETP contains Project in the non-lower directory, for example: c: /a/a.etp contains a C: /b/b.vbProj. Therefore, one to examine the binding information in the SLN file, which is the globalsection section; second to avoid the Project file in other paths other than the following directory in Solution or ETP. pay attention: After adjusting the Solution Structure, the PROJECT's storage path, the name, the ETP changes, but the SLN file may not be updated correctly because of the bug of VS.NET's Source Control Add-in, it will often lead to a problem. What are the file information related to the binding? What is the relationship between them? When there is a problem, what is the content of the file does not match what file? The file information related to the binding includes: l SLN files in the globalsection information l ETP or SCC * information in the Proj file l Solutionname.vssscc or information in the ProjectName.vspscc file l VSSDB / Users / UserName / SS.INI file work directory information The key role is also the most prone to problems, in fact, only the globalsection information in the SLN file. For each Project, it is mainly 5 aspects: Sccprojectuniquename1 = Projname1 // Projname1.vbproj SccprojectTopyParentuniquename36 = ... // ..... ETP Sccprojectname1 = / u0022 $ / Solution1 / Projname1 / U0022, / U0020uaaaaaaaaaaaaaaa SccLocalPath1 = Projname1 SccProjectFilePathRelatiVizedFromConnection1 = ... When there is a problem, it is between these items, or there is a difference between a certain content and the actual path. In particular, it is necessary to pay attention to the last SccProjectFilePathRelatiZedFromConnection1, which generally does not appear. If it occurs, it will generally lead to problems. The appearance of this content is often accompanied by scclocalpath =. In this case, multiple items have the same binding path, see (7) in the appendix (7). For web projects, there is a WebInfo file that describes URL information, which is inconsistent with SLN and ETP. Another check focus is the work directory setting in SS.INI, and if there is unnecessary or wrong working directory settings, it is generally binding problems. How to properly add new ETP and Project in a binding solution? Correct addition: (1) Add New Project (2) CHECK in those new projects (3) Save all files (mainly to save SLN) It is best to verify it with SSEXP, then turn off the Solution and open it again. How to add existing ETP and Project in a binding solution? Steps to add new ETP or Project no difference (of course, the first step is Add exsting project). However, if it is an ETP or Project that has been bound to the past, it is best to delete the corresponding VSPSCC file to cause problems from information such as RelativePath. A special case is that if the item added is already bound in other Solution, then you can't unbind. You can use the Add Project from Source Control command, do not use traditional add existing project. How to modify the ETP to which Project belongs is in the case of binding? For insurance, don't directly remove and add existing. Best practice: (1) Unbind Project. Then from the existing ETP Remove. (2) Delete the VSPSCC file that may exist. (3) Move the project's directory below the ETP! ! ! (4) Add existing project in the new ETP. (5) Save all then Check IN. (6) Close and open again. When adding a form to Project, you need to pay attention to what is the impact of binding? The point is: Once integrated, then all operations should be made in the IDE, do not use SSEXP.EXE to manually operate. When you add a file to the VSS DB, if an integrated operation is used, the relevant files can be automatically added or updated; otherwise, manually adding it is likely to miss some resource files, or miss any update operations. In addition, some files related to the user cannot put into VSS, including suo, *. VbProj.user, etc., manual operations are likely to add these files to each other, causing user environments to interfere with each other. What is the impact of the binding if you need to modify the name of a Folder? If you follow the MSDN document, this action will contain 20 steps! There is also a lot of manual operations. It is better to get the unbind single project, after the outside is changed, then add it in, and finally Check IN. another: For files, you can rename in the IDE, then checkin, the file name in the VSS will be automatically updated. A boundless solution, how is it more quickly unbind? Do you have to PROJECT unbind? If everything is normal, you can batch unbind in the vs.net IDE, do not need to be unbind. If you want to copy a binding Solution source code to a demo machine, how to ensure proper open solution on the demo machine, and don't see any warning or error message? The key is to correctly unbind. After unbind, files related to Source Control will be deleted, and the information about Source Control will be deleted in the project file. What is the difference between the two development modes of Web Project? What is influenced for VSS binding? VS.NET Management Web Project files There are two ways: File Share and FrontPage, the former is a new way of VS.NET, the latter is the method of Visual InterDev. l File Share: Use wwwroot $ sharing to modify the file, and its shared permissions are set to: ./ Administrators and ./vs developers have Full Control permissions. Test proves: If it is a local development environment (VS.NET and IIS in the same machine), even if this sharing can be opened normally. It can be seen that this shared is not used when developed with local IIS. l FrontPage: All files are managed using the HTTP protocol Source control requests from Visual Studio are forwarded through the FrontPage server extensions to the server installation of your source control provider (for example, Visual SourceSafe) The FrontPage access method does not support as.. Many Source Control Commands as File Share. Visem, the largest difference in the two modes is that the supported VSS operation command is not the same. In FrontPage mode, complex operations such as BRANCH / MERGE cannot be performed. note: Although in an integrated state, the File Share mode is generally used, but SLN or ETP still needs to specify the included Web Project, otherwise use the C: / INETPUB / WWWROOT / like this will cause the different machines that cannot be opened correctly. The problem. Why did you have a URL PATH when adding a new web project, and actually URL PATH? This should be the BUG of VS.NET IDE. When binding information disorders, it is best not to add new Project. Why is it http: // localhost / projectname_1 URL PATH? VS.NET always puts the WWROOT's work directory and sets the virtual directory. If there is already a renameful virtual directory in IIS, the URL PATH of the ProjectName_n style will be prompted. If you don't want to see such a tip, you should delete the local name virtual directory in advance. What is the common problem and reason for Web Project open failure? The most common questions include: (1) Problems such as Cannot Open Project The reason is that the information disorder of the globalsection section in the Solution file (SLN), the spam is not deleted, or the information about the working path is inconsistent with the actual path. (2) Work Folder information displayed in VSS In addition to the Web project, the working directory of other projects should be consistent with the structure in the VSS, but if the Solution or ETP structure is inconsistent with the Folder structure in the VSS, the VSS's useers / Username / ss.ini is uncomfortable with information about the working directory or is inconsistent with the actual situation. (3) Location prompt of the web project http: // localhost / projectname_1 This is because the virtual directory of the same name already exists in local IIS. Avoiding a problem is to delete a local renowned virtual directory before Open From Source Control. (4) Multiple project binding paths the same problem The reason is that SccLocalPath is incorrect, see (7) in Appendix (7). In order to avoid less problems, pay attention to: l Don't reuse the Open Source Control to open the Solution. This command can only be used once for a solution, if the first failed, must clean up the files from the hard disk, and delete the IIS VD and physical files. After you can use the Open from Source Control again to open it again. l Don't manually modify the Project information contained in ETP or SLN, especially the HTTP path of Web Project, do not change to C: / INETPUB / WWWROOT / path. l Do not add items of other paths outside of its lower-level directory in SLN or ETP. See Appendix for a solution for common problems. References Web Projects and source control integration in Visual Studio .NET MS-help: //ms.vsccc...1033/sccvs70/html/VetchWebProjectssourceControlintegrationInvisualStudionet_convert.htm Appendix: Steps to solve a Solution binding problem The following is the problem and solve the detailed process when using the Open from Source Control to open a Solution that has been bound, (1) Location problem of web project Tip When entering the work copy of the Web Project, a list of three web projects appears, and there should be only two. Cause: One of the Web Project-PurchaseWeb-is originally under wwwroot, and then adjust its source file to another Web Project-LeySerWeb - the secondary directory below, no longer as a separate Project, but the SLN file is about Source Control Information is not deleted in time, becoming spam. Specific steps: Open the SLN file and find the following information: ----------------- Global GlobalSection (SourceCodecontrol) = PRESolution Sccnumberofprojects = 56 ScclocalPath0 =. Cancheckoutshared = false SolutionuniqueId = {EFD7F1A3-3977-4BE8-AFFC-D33AB7D8546C} ... Sccprojectuniquename33 = http://localhost/purchaseweb/purchaseweb.vbproj SccProjectTopleVelparentuniquename33 = purchase // purchase.etpsccprojectname33 = / u0022 $ / ... / src / purchase / application overall / purchaseweb / ... SccLocalPath33 = http: // localhost / purchaseweb / ---------------- The word "33" is spam. Modified with NOTEPAD as follows: l Deleting spam with "33" words, including cazcheckoutshared = false. l Transfer the information of the last Project (labeled "55") to the position where the original "33" is located. l Change "55" to "33". l Change "56" in sccNumberOfProjects = 55 in the first line of GlobalSection (SourceCodecontrol) to "55". After the Task Manager terminates the vs.net, re-open from source control, this error is not, only the list of two web projects. (2) UNABLE TO Read Project File Problem When you re-open, confirm the location of Web Project, an error message appears: path not found: LeySerweb.vbproj. Cause: In the ETP file containing the item, the non-URL path is specified. The applicationui.etp file part is: Modify the path of the red word part to the URL address form: This problem is resolved. (3) Path Not Found Problem Forcibly termination, when reopening SLN, the prompt: $ / webproject /.../ Microsoft.ApplicationBlocks.Data Was Not Found. Was Not find. Was Like to Browse for the project? This is also because of the problem of VS.NET's bug, no timely update information. The original project is under another Folder, which is included in another ETP, and now adjusts only some of the information in SLN is updated: ---------- red word part is not correctly updated SccProjectUniqueName44 = .. WebFramework // Src // ApplicationBlocks // Microsoft.ApplicationBlocks.Data // Microsoft.ApplicationBlocks.Data.vbprojSccProjectTopLevelParentUniqueName44 = ..//..//WebFramework//Src//Frameworks.etp SccProjectName44 = /u0022 or 100/u0.0/MICROSOFT.ApplicationBlocks.Data/u0022,/u0... SccLocalPath44 = ..Webframework // src // ApplicationBlocks // Microsoft.ApplicationBlocks.DATA --------------- --------- Section of the SccProjectName44 section: / U0022 $ / WebProjects / WebFramework / src / ApplicationBlocks / U0022, / ... --------- This problem is solved. (4) Project File Not Found Problem Forcibly termination, when reopen SLN, the prompt appears: file not found: Microsoft.ApplicationBlocks.Data.vbproj Cause: The SLN is not correct, resulting in the working directory of the project in VSS separately, and is set to an incorrect path. Settings information about working directory Save in the following file: //xafile/share/project/MProject/USERS/[Username]/ss.ini Originally, just set the work directory for the SLN file, the lower directory will automatically set according to the project hierarchy, and do not require separate settings in SS.ini. Of course, the Web project is an exception because the WEB project is always under WwWroot. For other items, if there is a working directory setting information in ss.ini, it is certain that there is any problem. The settings of the working directory in s.ini are as follows: [$ / WebProjects / WebFramework / src / ApplicationBlocks] DIR (XA-App-Luo2k3J) = C: /MProject/webProjects/webframework/src/applicationblocks/microsoft.applicationBlocks.Data The red word part is a redundant part, the reason for this error, is incorrect in the SLN file: --- Sln.old Sccprojectuniquename44 = ..//../webframework//src//applicationblocks//ApplicationBlocks// Microsoft.ApplicationBlocks.Data/ /Microsoft.ApplicationBlocks.Data.vbproj SccProjectTopleVelparentuniquename44 = ..//../webframework//src//frameworks.etp SccProjectName44 = / u0022 $ / webprojects / webframework / src / applicationblocks / u0022, / ... SccLocalPath44 = ..///WebFramework//src/ApplicationBlocks//microsoft.ApplicationBlocks.Data-- The red word part is redundant. Delete the red word section, then remove the work directory settings for this project from SS.INI, this problem is solved. (5) Project Does not exist problem Forcibly termination, when reopening SLN, prompt appears: Project Does Not Exist. The reason for this problem is because the Project is not in the lower-level directory of its ETP, resulting in a separate set of working directories in SS.INI, while Open from Source Control, vs.net stills the project's file GET to the ETP file. In the lower-level directory of the directory (this should also be a BUG of VS.NET), of course, you can't find the specified CSProj file. The information in s.ini is as follows: [$ / WebProjects / Webframework / src / OtherFrameworks / NHibernate] DIR (XA-App-Luo2k3j) = C: /Study/asp.net/orm/nHibernate-0.0.5000.6/src/nhibernate The relevant information in the SLN file is as follows: Sccprojectuniquename33 = ../////..//../study/ASP.NET//orm//nhibernate-0.0.5000.6//src//nhibernate/nhibernate-1.1.csproj SccProjectTopleVelparentuniquename33 = ..//../webframework//src//frameworks.etp Sccprojectname33 = / u0022 $ / webprojects / webframework / src / otherframeworks / nhibitionnate / ... SccLocalPath33 = ..//..//..//../study//asp.net//orm/nhibernate-0.0.5000.6//src/nhibernate The red word part is inappropriate, saying "inappropriate", because the project is in addition to the directory where the ETP is located, so it cannot be said to be an error. However, because VS.NET does not follow the specified directory GET, the project cannot be opened, still the problem of vs.net. First remove the wrong working directory settings in SS.INI, then manually modify the ETP file, change the PROJECT's path to the subdirectory below ETP, save the hand-written CHECKIN this ETP file, you can solve this problem. (6) Problems in spam in SLN Modifying a directory name of a project may result in spam in the SLN file, then result in spam in SS.INI, which in turn leads to the project unacceptable. After seeing the prompt that the purchase.dataaccess.order project cannot open, check SS.INI discovery a spam: [$ / WebProjects / Purchase1.0 / src / purchase / dataAccess / purchase.dataaccess.order] DIR (XA-App-Luo2k3j) = C: /MProject/webProjects/purchase1.0/src/purchase/dataaccess/purchase.dataAccess.order Unlike other working catalogs, different spam is different: this information points to the working directory is correct, and it also meets the hierarchy of the entire Solution! Check the SLN file and find two Source Control information about Purchase.DataAccess.order.vbProj, one is spam: Sccprojectuniquename36 = purchase // DataAccess // order.dataaccess // purchase.dataaccess.order.vbproj SccProjectTopleVelparentuniquename36 = purchase // purchase.etp SccProjectName36 = /u0022 or 100/src/purchase/dataaccess/purchase.DataAccess.Order/u0022 ,/u0020yeeeaaaaaaaaaaaaaaaaaaa SccLocalPath36 = purchase // dataAccess // Order.DataAccess Cancheckoutshared = false Among them, the red word is actually modified to Purchase.DataAccess.order, and another information about the same VBProj is the modified path. This should also be a problem caused by the BUG of VS.NET. Delete this spam, and adjust the information such as sccNumberofProjects, this problem is solved. (7) Multiple project binding paths the same problem If SLN has problems, it may cause a lot of projects to Server Binding paths. The result is: In the Change Source Control dialog box, these items cannot be selected separately, select one, and other identical binding paths will be selected together. problem causes: SccLocalPath is not correct, usually scclocalpathxx =. It should be a relative path. Also, a sccProjectFilePathRelatiZedFromConnection setting is available. There is also a "symptom" yes: there will be content in the vbproj.vspscc file: "Project_file_relative_path" = "rs): purchase // businessfacade // prthase.Facade.supplierandrep" Solution: Turn the SccProjectFilePathRelatiZedFromConnection content to ScclocalPath, then delete the former, namely: Sccprojectuniquename49 = ....Supplierandrep.vbproj SccProjectTopleVelparentuniquename49 = purchase // purchase.etp ScclocalPath49 =. Cancheckoutshared = false SccProjectFilePathRelatiZedFromConnection49 = purchase // BusinessFacade // Prusse.Facade.supplierandrep // change into: Sccprojectuniquename49 = ....Supplierandrep.vbproj SccProjectTopleVelparentuniquename49 = purchase // purchase.etp SccLocalPath49 = purchase // BusinessFacade // prthase.Facade.supplierandrepcancheckoutshared = false Alternatively, ScClocalPath is not a period, with content, but the actual project file is not in the lower-level directory of the ETP, and the result will appear "..//" style relative path: SccProjectuniquename8 = ..// ... SccprojectTopleVelparentuniquename8 = ..//wwwebframework//src//frameworks.etp SccProjectName8 = / u0022 $ / webprojects / webframework / src / applicationblocks / u0022, / ... SccLocalPath8 = ..//../webframework//src/ /applicationblocks Cancheckoutshared = false SccProjectFilepathRelatiVizeDFromConnection8 = security // src // cs // security // For this situation, the SccLocalPath cannot be modified. Check that in these CSProj files of these C # Projects, there is SCCProjectName information, such as: Sccprojectname = '"$ / webprojects / webframework / src / applicationblocks", kgbeaaaa' For VB.NET projects, there is only very simple information in the VBProj file: Sccprojectname = "SAK" Therefore, there is a difference in binding information management of the C # project and VB.NET project. In any case, it is best to remove the items below the directory where the SLN file is located (of course, in addition to the web project); or put the SLN file in a directory of all project file directories. In short, it is to avoid the relative path of "..//". prompt: l As long as sccprojectfilepathrelativizedfromconnection, there is a problem! l To avoid the ETP containing Project outside the path outside the following directory, it is also necessary to avoid ETP or Project in the SLN included in the path outside the following directory. (8) SCCProjectname information loss problem In the Change Source Control dialog, it is found that Server Binding of many projects displays red waves. After exiting the IDE, it is found that there are many Work Folder settings in SS.INI, most of which is not needed (can be determined according to the working directory of the superior directory): one is wrong: [$ / Webprojects / purchase1.0 / src] DIR (XA-App-Luo2k3j) = C: /MProject/webProjects/purchase1.0/src/purchase.Unittest/purchase.test.Order Check the content below the purchase.test.order, which is the same name of Project. Then check the SLN file and find that all items that display the INVALID status are missing sccprojectname information. Solution: l Delete the working directory settings in SS.INI. l Check Out and reopen the SLN. l Re-set the server binding of Status for the INVALID. In this process, you may need to have some project files (including ETP files). l Check IN changes in SLN, ETP, VBProj, CSProj, etc. (9) CHECK IN prompts the excess file When checking in the IDE environment, the list of files shown in the dialog includes some files that do not have Checkout. The inspection found that these excess files may be: l Does Server Binding project files. l Although it is still in the original Project, it is moved to other subdirectories in VSS. l The hidden file in the project has not been added to the VSS. For example, the NHibetnate-mapping-2.0.xsx file in the figure. For these files, the meaning of Check IN is actually Add to SourceSafe. For files moving the location, you should manually delete the junk file in the VSS in the CHECK IN.
