VS 2012 запускает приложение, основанное на неправильном пути
У меня есть приложение, которое находится под контролем источника (TFS 2012 также) на c:\Dev\MyApp\Main.
Поскольку я разрабатывал новую функцию, я решил открыть ветвь на c:\Dev\MyApp\BranchNewFeature.
Я разработал, и когда я решил, что пришло время протестировать, это было похоже на то, что я вообще ничего не делал. Я ударил F5, и я вижу базовую версию приложения... Вглядываясь в нее, я заметил очень любопытный факт: когда я проверяю IIS Express, "путь запуска" для приложений является старым (c:\Dev\MyApp\Main).
Может ли кто-нибудь помочь мне заставить IIS Express указать новый путь? (C:\Dev\MyApp\BranchNewFeature)
Ответы
Ответ 1
Я столкнулся с той же проблемой. Чтобы исправить это, я использовал cheesemacfly, чтобы обновить C:\Users\%USERNAME%\Documents\IISExpress\config\applicationhost.config
, чтобы указать на новый каталог.
Очевидным недостатком этого решения является то, что вам нужно сделать это несколько раз, если вы планируете часто переключаться между вашими новыми веткими. Похоже на ошибку в VS2012...
Ответ 2
Перезапуск VS, похоже, устраняет эту проблему. Это просто альтернативное решение, так же как его норма для всех продуктов Windows - закрыть и перезапустить, и это будет работать!
Вот что произошло:
Я столкнулся с такой же проблемой после того, как я работал над веб-проектом в ветке с использованием VS2013. Как упоминал выше Крис Гиллум, я открыл приложение applicationhost.config, когда я перезапустил VS, и файл автоматически обновился с правильным путем. Итак, это определенно кажется ошибкой в Visual Studio.
UPDATE:
Я видел эту проблему много раз, так как я опубликовал этот ответ. И я нашел альтернативу перезапуску VS. Вот что я делаю сейчас:
IISExpress автоматически обновит сайт, и вам не нужно перезапускать VS. Надеюсь, это поможет кому-то.
Ответ 3
При открытии решения Visual Studio, которое содержит веб-проект IISExpress, обновляется конфигурация элемента applicationHost.config <site>
. Если вы затем откроете решение для отдельной ветки, возможно, что конфигурация <site>
будет перезаписана, чтобы указать на эту отдельную ветку.
Например, скажем, у вас есть две ветки решения, содержащие веб-проект, настроенный на использование IISExpress на порту 4000. Когда вы открываете решение для Branch1, applicationHost.config будет обновляться с помощью элемента <site>
, регистрирующего сайт на localhost: 4000, указывающий на папку для Branch1. Когда вы начинаете отлаживать свое решение, ваш браузер открывает localhost: 4000, и все работает отлично.
Если вы затем откроете решение для Branch2, applicationHost.config будет снова изменен, переопределив элемент <site>
, чтобы вместо этого localhost: 4000 теперь указывал на Branch2. Теперь, если вы "Начните отладки" в открытом решении Branch1 или в открытом решении Branch2, localhost: 4000 будет указывать на Branch2, так как это то, что в файле applicationHost.config.
Чтобы обойти эту проблему, настройте две ветки на использование разных портов, а затем Visual Studio будет управлять двумя отдельными элементами applicationHost.config <site>
, по одному для каждой ветки. Вам нужно помнить о том, чтобы настроить новый номер порта каждый раз, когда вы создаете новую ветку.
Ответ 4
Если вы ищете для этой же проблемы в Visual Studio 2015, файл applicationhost.config переместился в скрытую папку: $SolutionDirectory/.vs/config.
Ответ 5
У меня была аналогичная ситуация, когда я скопировал проект. После запуска проекта он отобразил исходный проект в браузере, а не мою скопированную, отредактированную версию. Моим решением было удалить все созданные сайты из файла конфигурации:
C:\Users\%USERNAME%\Documents\IISExpress\config\applicationhost.config
Затем мне нужно было щелкнуть правой кнопкой мыши проект в Visual Studio, нажмите Properties
, затем перейдите на вкладку Web
, на этой вкладке я изменил порт, указанный в Project Url
, и сохранил. Затем Visual Studio спросила, хочу ли я добавить проект обратно в файл конфигурации хоста приложения. Я нажал кнопку "Да" и запустил проект, внезапно все было в порядке.
Моя особая проблема не была ошибкой в Visual Studio, а скорее несоответствием конфигурации.
Ответ 6
У меня была подобная ситуация, и я искал ответ, когда нашел эту статью. Я думал о применении этого исправления, но чувствовал, что это было много усилий каждый раз, когда вам нужно снова или снова объединиться.
Я немного поработал, и я считаю, что нашел более легкое решение. Я обнаружил, что в Visual Studio 2013, если вы откроете Свойства проекта и нажмите на веб-вариант, вы увидите раздел "Серверы" с кнопкой "Создать виртуальный каталог".
Если вы нажмете эту кнопку, вы получите вопрос об этом, указывающий на другой каталог, в котором находится проект, хотел бы его исправить. Когда вы нажимаете "да", это делает исправление для вас, и когда вы отлаживаете сейчас, он вытащит из правильного местоположения.
Ответ 7
В VS 2015 мне не пришлось напрямую редактировать конфигурационный файл. Я открыл разветвленный проект и перешел на страницу "Свойства" в рамках проекта. Перейдите на вкладку "Веб" и выберите "Серверы" > "URL проекта".