Web Site projects, TFS and branches can mess up your workspace…

Yet another issue experienced when working on multiple branches in TFS: working with branched Visual Studio Web Site Projects (not to be confused with Visual Studio Web Application Projects) could indeed result in the creation of messy mappings in your workspace. This is due to the way Visual Studio manages the Virtual Directories behind Web Site Projects.

Click to Read More

My colleagues reported indeed some troubles when working with Visual Studio 2010 on Visual Studio Solutions containing Web Sites (not Web Applications) branched, e.g., from an existing TFS folder $/TeamProject/Main/Website onto a new branch $/TeamProject/Dev/WebSite (They still have indeed a few such Web Site Projects. Those cannot be upgraded into Web Applications as they use a framework that relies on various typical features of web sites, not supported by web applications. In addition, note that on the development workstations, the web sites are hosted in IIS due to some prerequisites of that framework, a.o. some limitation on the host header name and port).

Assume now that $/TeamProject is mapped withing a local workspace on C:\TFS\TeamProject, that there is no other mapping in this workspace and that one checks-in a new Web Site created in C:\TFS\TeamProject\Dev\WebSite. By default, the resulting server items will be located in  $/TeamProject/Dev/WebSite. And as you should know, a virtual directory named “WebSite” will have been created in IIS by Visual Studio and mapped on C:\TFS\TeamProject\Dev\WebSite behind the scene – mapping which is saved in the Visual Studio suo file).

Next, assume that one does a reverse integration of the Dev branch on the Main branch, that one checks-in the pending changes and that one opens next the Visual Studio Solution located in C:/TFS/TeamProject/Main (opening de facto also the web site)

Using Web Application Projects instead of a Web Site Projects, Visual Studio would alert the user that a Virtual Directory already exists with the same name but with another physical path (C:/TFS/TeamProject/Dev/WebSite in this case). And the user would be prompted to possibly redefine this Virtual Directory with the new location (i.e.: with C:/TFS/TeamProject/Main/WebSite). If the user refuses, the Web Application won’t be loaded in Visual Studio. If he agrees, the Virtual Directory is remapped on the new location.

But with Web Site Projects, it’s slightly different…. Visual Studio prompts the user to reuse the Virtual Directory. If the user refuses, a new Virtual Directory with the same name but suffixed with “_1” is created and mapped on the new physical path (opening again the web site from yet another physical location would results in suffixes “_2”, “_3”, etc…). This new name is unfortunately an issue for my colleagues, if they want to run the web site, again due to some constraints of the framework in use.

Instead, if the user accepts to reuse the Virtual Directory (expecting a behavior similar to the one experienced with Web Application Projects), Visual Studio will not redefine the physical location of the Virtual Directory; it will create new mappings in the workspace to get the sources from TFS in the physical location currently defined for the existing Virtual Directory. I.e.: the definition of the workspace will be like:

  • $/TeamProject                          ==>  C:/TFS/TeamProject
  • $/TeamProject/Main/WebSite ==>  C:/TFS/TeamProject/Dev/WebSite
And the Virtual Directory “WebSite” will be kept mapped on the physical location C:/TFS/TeamProject/Dev/WebSite.

Guess what if the user reopens later the solution in C:/TFS/TeamProject/Dev to implement new features on the web site in the Dev branch ? He will actually check-in his changes under the branch $/TeamProject/Main/

Upgrade to Web Applications is not an option at all – it was already investigated years ago and the cost was to high. But I could possibly investigate the use of the Visual Studio Development Web Server instead of IIS, although it is a prerequisite for the framework used in those web sites projects.

As a temporary solution, I suggest all users to delete any existing Virtual Directory before opening a Solution containing Web Sites Projects. If they have already reused an existing Virtual Directory, I suggest them to clean the messy mappings in their workspace and delete next the existing Virtual Directory. If they have a Solution working with a Virtual Directory suffixed with _1, I suggest them to delete their .suo file (otherwise Visual Studio will always recreate a Virtual Directory with that name when opening the Web Site Projects) and delete that Virtual Directory.

Notice: in some case (if not deleting/recreating correctly the Virtual Directory and the suo), you could have Visual Studio Solution files opened from various branches referencing the same Virtual Directory, obviously mapped on only one physical path, but without extra mappings in the workspace… And Visual Studio won’t prompt you to use the existing Virtual directory when opening a solution. In such a case, delete the suo file of that solution.




One response to “Web Site projects, TFS and branches can mess up your workspace…”

  1. vletroye Avatar

    It appeared that I could not configure the Web Site Projects to be hosted in the Visual Studio Development Web Server (WebDev) instead of IIS. This option is not available for Web Sites… And Visual Studio uses IIS as default web server as far as this one is available.

    An option would be to use WebDev as a “Custom Server” (on another port).

    Unfortunately, the option “Use Custom Server” was disabled in all Web Site Projects’ “Property Page”… This was due to the “web location” of the Web Site Projects: they were all “HTTP” web sites (The “web location” of a Web Site Project can be specified at creation time: File System, HTTP or FTP).

    Fortunately, this setting is easy to modify in the Visual Studio Solution File. Here is the difference between a File System Web Site and a Http Web Site:
    Project(“{E24C65DC-7377-472B-9ABA-BC803B73C61A}”) = “FSWebSite”, “:FSWebSite”,
    Project(“{E24C65DC-7377-472B-9ABA-BC803B73C61A}”) = “HttpWebSite”, “http://hostname.domain/HttpWebSite”,

    With something like this defined in the machine’s host file: hostname.domain

    Once the Web Site Projects have a File System “web location”, we can “Use custom Server” via the “Start Options” (Right Click the Web Sites in the Solution opened within Visual Studio and select “Start Options”). My idea was basically to set “http://hostname.domain:8080/FSWebSite” as a Base Url and start WebDev (installed in C:Program FilesCommon FilesMicrosoft SharedDevServer10.0) Like this:

    WebDev.WebServer20.exe /port:8080 /path::

    Without a Virtual Directory as parameter (/vpath:xxx)… in order to host all the Web Site Projects within the same WebDev, each one in a subfolder; Each Web Site Project is indeed in a subfolder of the Solution. Ex.:
    – C:/TFS/TeamProject/Dev/FsWebSite
    – C:/TFS/TeamProject/Dev/HttpWebSite
    – C:/TFS/TeamProject/Dev/OtherWebSite
    The purpose is to support the “site switch” mechanism in place to navigate between the sites. Indeed, this mechanism does not support navigation between site with specific ports 🙁

    But there are too many resulting issues…
    – First, hyperlinks like ~/ does not work anymore as they used to reference the root of the Virtual Directory (I.e.: 🙂 which is now one level above the expected folder (I, 🙂
    – Next, WebDev does not support Forms Authentication which is used by various Web Sites, with custom Role and MemberShips Providers.
    – Also, we have to manually run WebDev or add a dummy Library Project with a post Build Event to start it. This Library Project must be moved in first position in the “Build Order” tab of the “Project Dependencies” (Right-Click the Solution in Visual Studio and select the “Project Build Order” menu).

    Possibly, we could disable IIS. In such a case, WebDev would become the default server. This would solve the first and last issues mentioned above (“hyperlinks like ~/” and “how to start WebDev”). But we would have one specific and distinct port per Web Site, which is a issue for the framework currently used in those Web Sites.

    Conclusion: Workaround not yet found 🙁

Leave a Reply

Your email address will not be published. Required fields are marked *