VS 2012 launching app based on wrong path

Question

I have a app which is under source control (TFS 2012 also) on c:\\Dev\\MyApp\\Main.

Because im developing a new feature I decided to open a branch on c:\\Dev\\MyApp\

Answer 1

Restarting VS seems to fix this problem. This is just an alternative solution, just as its a norm with all Windows products - close and restart, and boom it'll work!

Here's what happened: I faced the same problem after I worked on a web project in a branch using VS2013. As Chris Gillum mentioned above, I had the applicationhost.config open while I restarted VS, and the file got auto-refreshed with the correct path. So, this definitely seems to be a bug in Visual Studio.

UPDATE:

I've seen this issue numerous times since I posted this answer. And I've found an alternative to restarting VS. Here's what I do now:

1. Right click IISExpress Icon and click on "Show all Applications"
2. Select the Site Name from the list
3. Click (and open) the Config file

4. Search for and fix the physical path to your workspace under the following section:

   <sites>
       <site name="MyWebSite" id="XXX">
           <virtualDirectory path="/" physicalPath="FIX_THIS_PATH" />
       </site>
   <sites>
   

IISExpress will automatically refresh the site, and you do not need to restart VS. Hope this helps someone.

Answer 2

I had a similar situation where I had copied a project. After running the project it displayed the original project in the browser rather than my copied, edited version. My solution was to remove all the effected sites from the config file:

C:\Users\%USERNAME%\Documents\IISExpress\config\applicationhost.config

I then had to right click the project in Visual Studio, click Properties then click the Web tab, on this tab I changed the port specified in the Project Url and saved. Visual Studio then asked if I wanted to add the project back to the application host configuration file. I clicked yes and run the project, suddenly all was fine.

My particular problem was not a bug in Visual Studio but rather a configuration mismatch.

Answer 3

When you open a Visual Studio solution that contains an IISExpress web project, the applicationHost.config <site> element configuration is updated. If you then open a solution for a separate branch, it's possible that the <site> configuration will be overwritten to point to that separate branch.

For example, let's say you have two branches of a solution containing a web project configured to use IISExpress on port 4000. When you open the solution for Branch1, the applicationHost.config will be updated with a <site> element registering a site at localhost:4000 pointing to the folder for Branch1. When you 'Start Debugging' your solution, your browser opens localhost:4000 and everything works just fine.

If you then open the solution for Branch2, the applicationHost.config will be modified again, overriding the <site> element so that localhost:4000 now instead points at Branch2. Now, if you 'Start Debugging' in either the open Branch1 solution or the open Branch2 solution, localhost:4000 will be pointing to Branch2, since that's what's in the applicationHost.config file.

To work around this issue, configure the two branches to use different ports and then Visual Studio will manage two separate applicationHost.config <site> elements, one for each branch. You'll need to remember to configure a new port number each time you create a new branch.

Answer 4

In VS 2015, I didn't have to edit the config file directly. I opened the branched project and went to Properties page under the Project. Go to the Web tab and edit Servers > Project URL.

Answer 5

In case you get here searching for the same issue in Visual Studio 2015, the applicationhost.config file has moved to a hidden folder: $SolutionDirectory/.vs/config.

Answer 6

I ran into the same issue. To fix it, I used cheesemacfly's suggestion, to update C:\Users\%USERNAME%\Documents\IISExpress\config\applicationhost.config to point to the new directory.

The obvious downside with this solution is that you need to do this repeatedly if you plan on switching between your new branches often. Seems like a bug in VS2012...