Check in web service that are already under source control for VS2003

Check in web service that are already under source control for VS2003

• coolerelf

  Hello Alin
  
  It is very clear for me that we do not need to mess with he source control binding information in the solution and project files.
  
  When my colleague fetches everything from the server to his local computer. We both have the same directory structure and he opens the solution file the problems begin. VS2005 thinks then that the web site is on another location. Namely C:\sandbox\location1\WebApps\Sample\Sample, but the original location is C:\sandbox\location1\WebApps\Sample.
  
  Then we did the following tests:
  
  1
  We removed all the binding information from the solution file and reopened the solution and everything works fine. So we came to the conclusion that the source control binding was invalid.
  
  2
  We fetched the original solution file again and we copied the suo file to the PC of my colleague and opened the solution file everything works fine. When I removed the suo file from my computer I have the same problem as my colleague.
  
  
  According to online help of MSDN it is not needed to check in these suo files. So what should we do check in these suo files or NOT
  
  
  We only have these problems with web site projects. All other project types (library, control library, ..) are working fine
  
  Thankx in advance
  
  Raymond
  
  
  

• Mrdecav

  If you modify the bindings in the solution/projects you're pretty much on your own... It's easy to break scci integration this way. Again, use the suo from other machine and you're messing with the enlistment information, so you're again on your own.

  I don't know at what bindings settings are you looking when you say "But with the source control bind information it is not correct".

  Some bindings like SccProjectName, SccProvider are controlled by the source control provider (MKS).

  The bindings controlled by VisualStudio are SccLocalPath, SccProjectUniqueName, SccProjectFilePathRelativizedFromConnection, and they are calculated depending on all files in the projects, on the exact location on disk of the projects and the solution, on the order the projects have been added to source control, whether they have been added with the solution or not, etc. I can't tell you how these bindings should look like without an exact description of the solution (project types, project and solution location on disk, what files are shared between projects, whether the project links to files outside the project's folder, etc).

  Alin

  
  

• neobash

  From what you're saying, VS conversion seems to have done what it was supposed to do.

  When converting a VS2003 Web project to a VS2005 project-based website, the source control settings for the website are discarded. You should have seen a warning dialog about this at the end of the conversion.

  If you want source control for the website you have to rebind it manually to source control, and the recommendation is to bind it to a different folder than where your VS2003 web files are (otherwise a Get... operation in the web root will download the VS2003 project file, and next time you'll open the solution you'll get again the conversion wizard).

  It may be possible that MKS doesn't allow you to bind it to a different folder, in which case you should probably delete the vbproj and vbproj.vspscc files from the database in the root of the website and use Bind instead of AddToScc to add the website to source control.

  Alin

  
  

• AstralPilot

  Hi,

  I'd suggest you dont't mess with the bindings stored int he solution or project files, as it is easy to set them incorrectly and break source control integration.

  To answer your question, the bindings may be stored differently, depending on:

  - the order you add the projects to source control

  - whether you bind the projects to source controll one by one or grouped (or whether you add the whole solution to source control, and add more projects later to it that you checkin)

  - the project names reported by the source control provider

  - the exact file paths of all the files contained in the projects and solutions

  I'm not sure what MKS providr returns for bindings, but from VS point of view It is possible that both configurations listed above are correct.

  You may be able to understand why they are differet by using File/SourceControl/ChangeSourceControl dialog (display ServerBinding, LocalBinding and RelativePath columns), look which lines are gouped and share the same connection, etc.

  Alin

  
  

• Pyramus

  Thanks for youre answer. But now I have another question regarding the source control information inside the sln file.
  
  First I will explain the server structure of two different web sites, both web sites have Web Deployment project that belongs to the same solution file
  
  location1\WebApps\Sample\<name>.sln
  location1\WebApps\Sample\<name>.amx
  location1\WebApps\Sample\App_code\<name>.cs
  location1\WebApps\SampleDeploy\<name>.wdproj
  
  location2\WebApps\Demo\<name>.sln
  location2\WebApps\Demo\<name>.amx
  location2\WebApps\Demo\App_code\<name>.cs
  location2\WebApps\Demo\Deploy\<name>.wdproj
  
  When we check both solutions in the source control block will be inserted in the solution files, buth when view the solution files with a notepad. We noticed that both files do not have the same entries. The lines that are in black are identical. The lines in color are different
  
  List1: Solution file of location1
  SccNumberOfProjects = 3
  SccProjectName0 = d:/mks_projects/location1/WebApps/project.pj
  SccLocalPath0 = ..
  SccProvider0 = MSSCCI:MKS\u0020SCC\u0020Integration
  SccProjectFilePathRelativizedFromConnection0 = Sample\\
  SccWebProject1 = true
  SccProjectUniqueName1 = .
  SccLocalPath1 = ..
  SccProjectFilePathRelativizedFromConnection1 = Sample\\
  SccProjectEnlistmentChoice1 = 2
  SccProjectUniqueName2 = ..\\SampleDeploy\\Sample_VS80.wdproj
  SccLocalPath2 = ..
  SccProjectFilePathRelativizedFromConnection2 = SampleDeploy\\
  
  List2: Solution file of location2
  SccNumberOfProjects = 3
  SccProjectName0 = d:/mks_projects/Location2/WebApps/WebApps.pj
  SccLocalPath0 = .
  SccProvider0 = MSSCCI:MKS\u0020SCC\u0020Integration
  SccWebProject1 = true
  SccProjectUniqueName1 = .
  SccLocalPath1 = .
  SccProjectEnlistmentChoice1 = 2
  SccProjectUniqueName2 = ..\\DemoDeploy\\Demo_vs80.wdproj
  SccProjectName2 = d:/mks_projects/Location2/WebApps/WebApps/DemoDeploy/project.pj
  SccLocalPath2 = ..\\DemoDeploy
  
  How is it possible that these files are different Is this the problem of our source control provider or VS2005
  
  

• K.V.Bharath

  How did you migrated your VS2003 web project To a (folder-based) website or to a WAP (web application project)

  If you have migrated to a website, you should be able to bind the website to any source control folder you like using File/SourceControl/ChangeSourceControl dialog (and it's strongly recommended to add or bind them to a different folder than where the VS2003 web files were stored).

  If you migrated to a WAP, I think you should checkout all the files, add the files from disk that should be in the project and they aren't, then checkin the project.

  Alin

  
  

• RobertoG

  Hi,

  I need to get some more information to be able to help...

  What source control provider are you using

  To reproduce your problem on my computer, what steps would I need to take

  Thanks,

  Brad Peterson

  
  

• Winston Pang

  
  We converted the project by opening the project file in VS2005 and let the convert wizard do his job. This will lead to folder based web site.
  
  For source control we are using MKS
  
  
  

• Navaneeth

  > So what should we do check in these suo files or NOT

  Definitely NOT. They contain user-specific settings for VisualStudio, and they should not be shared. From source control point of view, they contain enlistment information from your machine, offline status, etc. You should not checkin the suo file or copy it on colleagues machines because it will affect all other teammates (and may cause them to see unspecified errot messages)

  I don't know exactly how MKS works and I dont know your exact solution structure to help you more. From the VisualStudio point of view, the rules of working with websites are:

  - one user has to add the solution to scc, all others have to open the solution from source control (not from local disk!), using functionality from VisualStudio

  - When adding to scc and enlisting in a localdisk website, VS will try to keep the website files in the same relative location to the solution as they were for the first user who created the project

  - For localhost websites, if MKS forces you to get the website files on the local disk before opening the solution from source control in VS, you should use IIS Manager and pre-create the web projects as virtual folders in IIS pointing to the location on disk where the website files are. Then open the solution from source control, and VS should find the projects in IIS and prompt you to reuse the existing location.

  Alin

  
  

• rajgz

  Have you tried binding the web project to a different folder in the scc database

  Is the app_code by any chance a virtual folder Files in virtual folders cannot be added to source control.

  For the asmx files that fail to be checked in I think you should talk with MKS support - VS's behavior is pretty much dependent on the source control provider implementation of the MSSCCI functions. It sounds like MKS reports those files as uncontrolled (so VS wants to add them to scc as new files), but when VS calls SccAdd MKS complains that they are already controlled.

  Alin

  
  

• JD3027

  We are using localdisk websites and this is our directory structure.
  location1/WebApps/Sample (contains the sln and the asmx files)
  location1/WebApps/Sample/app_code (contains the cs files)
  location1/WebApps/Sample/bin (contains the references)
  
  > When adding to scc and enlisting in a localdisk website, VS will try to keep the website files in the same relative location to the solution as they were for the first user who created the project
  
  This is correct when we remove the source control bind information from the solution file. But with the source control bind information it is not correct. Then vs assumes that the files are located on the following location:
  location1/WebApps/Sample/Sample
  
  
  Why does it work correct when I use my suo file on my colleagues computer
  
  

• lSalamon

  I bind the web project to a different folder and everything works fine. Then I compared the two solution files.
  
  The files are NOT the same. The solution file that was generated from the conversion does not have the elements in RED
  
  ProjectSection(WebsiteProperties) = preProject
  SccProjectName = "c:\SandBox\TstRaymond\project.pj"
  SccAuxPath = ""
  SccLocalPath = "."
  SccProvider = "MSSCCI:MKS SCC Integration"
  ..
  EndProjectSection
  
  GlobalSection(SourceCodeControl) = preSolution
  SccNumberOfProjects = 2 (the original value was 1)
  ..
  SccWebProject1 = true
  SccProjectEnlistmentChoice1 = 2
  EndGlobalSection
  
  After I added the elements manually to the solution file. Every thing works fine.
  
  My conclusion is that the conversion of Visual studio is in correct
  
  Raymond
  
  
  
• Check in web service that are already under source control for VS2003