IIS Express на общей машине разработки (rdp)

Question

У меня есть проблема, которая, как мне показалось, может быть распространенной, искала ее в Интернете, но ничего не нашла.

Мы используем общую машину разработки, и каждый разработчик подключается через RDP и имеет свой собственный профиль,рабочий стол и т. д.

Проблема, с которой я сталкиваюсь, связана с IIS express.Так как он настроен на уровне пользователя (applicationhost.config внутри documents / iisexpress / config) и настроенный порт должен совпадать с тем, который объявлен в файле .csproj, два разработчика не могут работать на одном и том же порту, так как он выдает ошибку«порт уже используется».

Таким образом, чтобы заставить его работать, мы должны вручную изменить порт как в csproj, так и в applicationhost.config для каждого разработчика, но это только временное исправление, как когда мыПередав наши изменения в SVN, файл csproj объединяется, поэтому мы должны выполнять этот процесс каждый раз, когда кто-то фиксирует / обновляет.

Мой вопрос: есть ли чистый способ использования IIS Express с Visual Studio 2010 наобщая машина разработки?

Спасибо.

Answer 1

Частично проверенный ответ. Не уверен, как это будет работать на многопользовательской рабочей станции. Это может дать вам или кому-то еще здесь стимул для правильного решения, которое лучше всего работает в вашей существующей среде.

Похоже, что Visual Studio хранит всю веб-конфигурацию в csproj / vbproj, а IISExpress сохраняет свою конфигурацию в% userprofile% \ Documents \ IISExpress \ config \ ApplicationHost.Config.

Обычно мы храним файлы csproj в системе управления версиями, но игнорируем файл csproj.user, чтобы у каждого пользователя были уникальные настройки, такие как веб-конфигурация.

• Каждый пользователь, который входит в систему, должен иметь свой профиль.
• Каждый профиль должен иметь свою собственную копию исходного кода.
  • Каждая исходная копия каждого пользователя будет содержать собственный файл csproj.user.
• Игнорировать. ** proj.user * файлы в вашем контроле исходного кода.

Скопируйте веб-настройки в csproj.user, сняв флажок с опции Применить настройки сервера ко всем пользователям , а затем передайте управление исходным кодом.

Каждый пользователь, который извлекает копию источника, должен будет настроить свои веб-настройки, использовать уникальный порт, который не используются другими пользователями, и снять флажок выше, чтобы их конфигурация не передавалась другим пользователям.

При этом каждый профиль будет иметь свой собственный IIS Express ApplicationHost.Config, настроенный с портом, который отличается от других профилей. Каждая копия исходного кода пользователя будет иметь csproj.user, для которого настроен тот же порт в конфигурации IIS Express их профиля.

Для справки:

Я попытался изменить ApplicationHost.Config IIS Express, чтобы использовать порт, отличный от ожидаемого Visual Studio, и Visual Studio не может подключить отладчик к IIS Express.

Как работает конфигурация IIS Express: http://msdn.microsoft.com/en-us/library/ms178109.aspx

Answer 2

Я думаю, что вы можете создавать субдомены для каждого пользователя, вносить необходимые изменения и проводить тестирование. Таким образом, каждый пользователь может использовать свой собственный поддомен и порт и, следовательно, работать независимо от общего IIS Express.

Answer 3

Вам, вероятно, не понравится мой ответ, но вот мои мысли:

Как вы заметили, конфигурации привязаны к профилю пользователя, а не к серверу; Это связано с тем, что IIS Express не предназначен для использования в качестве общего сервера разработки. Вы должны использовать полный IIS.

Я не вижу никакой выгоды или причины использовать один и тот же физический блок для разработки. Следует признать, что я не знаю всех деталей вашего сценария с ресурсами лицензирования или рабочей станции, но, похоже, вы мало выигрываете от того, что все RDP включены в комплект для использования Visual Studio - каждому человеку по-прежнему нужна лицензия, производительность будет будьте медленнее, и вы не должны работать над одним экземпляром проекта.

Вы должны серьезно рассмотреть все ваши настройки для разработки:

Каждый разработчик должен использовать Visual Studio на своей рабочей станции и выполнять там отладку / тестирование с помощью IIS Express (с одинаковыми портами и настройками на всех машинах - очень просто).

Оттуда ваши разработчики должны проверить свой код в системе контроля версий и изучить конфликты, которые могут возникнуть или не возникнуть. Я не уверен насчет SVN, но автоматизацию MSBuild, доступную в TFS, можно использовать для настройки политики непрерывной сборки, которая развертывается в общей установке IIS, чтобы ваш объединенный код тестировался и мог использоваться из полной установки IIS, упомянутой выше.

Все остальное будет обходной путь / хак, который позже укусит вас в задницу.

Answer 4

Лучший вариант, который вы можете использовать, - воспользоваться Функцией импорта , встроенной в MSBuild.

По сути, вы должны создать отдельную цель сборки для каждого пользователя. Затем вы можете напрямую импортировать эту цель из этого ссылочного файла. Затем я бы порекомендовал создать этот файл на сервере (для каждого пользователя), но оставить его вне контроля исходного кода.

Это должно позволить каждому пользователю иметь собственный порт IIS, не конфликтуя с другими.