Subversion и использование IIS для разработки ASP.NET

Вы не можете просто указать IIS на C: \ Localsource \ Projects \ ProjectName и установить разрешения?

Хммм - Хорошее замечание. Когда я приехал сюда, он был настроен таким образом, и Visual Studio всегда создает веб-сайты в папке wwwroot, поэтому я предположил, что wwwroot - это именно то место, куда они должны были пойти.

Может, мне придется подумать о том, чтобы немного переставить ...

Спасибо!

Хорошо, я могу быть здесь дураком, но ... Зачем вам нужно добавлять папку IIS (т.е. вывод базы кода) в ваш репозиторий?

Обновлять

Я думаю, мне следует прояснить это немного подробнее ... Я хочу сказать, что я не уверен, почему ASPX в любом случае отделен от проекта? Что не так с веб-проектом и проектами библиотеки классов п в решении, добавленных в ваш репозиторий .. Затем вы публикуете каждый новый выпуск ..

Если это просто случай «может быть проще откатить опубликованный результат», то так тому и быть, мне было просто любопытно, поскольку я не видел, чтобы многие люди действительно работали таким образом.

Развертывание решений в этой структуре также было бы намного проще.

Папка IIS не является продуктом базы кода, это часть приложения. Это не вывод CGI или что-то в этом роде, а на самом деле скрипты для запуска приложения!

Это страницы .aspx, которые будут иметь пользовательские элементы управления и HTML для фактического запуска приложения. Это часть приложения, но отделена от решения VS Studio.

Самый простой способ - получить решение, а затем C: \ Localsource \ Projects \ ProjectName \ WEBSITE.

Направьте IIS также на эту папку.

В решении в Visual Studio у вас может быть проект библиотеки классов, который обычно находится в каталоге под файлом .sln.

В этом случае у него также есть веб-проект в решении, но НЕ под файлом .sln в структуре каталогов файлов.

Он будет подключаться к этому проекту через HTTP, а не через локальный путь к файлу.

IIS будет управлять этим как http: // локальный / webapp и по умолчанию поместит его в c: \ inetpub \ wwwroot \ webapp. Файлы в папке webapp не будут находиться в репо, поскольку они не входят в иерархию решения и библиотеки классов. Это его вопрос, как в этом разобраться.

Мой ответ - переместить http: // локальный / webapp так, чтобы он указывал на папку, которая находится под файлом .sln и рядом с каталогом библиотеки классов, тогда все это может быть помещено в репо.

Разделение библиотеки классов и веб-приложения - лучший способ облегчить повторное использование кода и отделить логику от веб-сайта.

Я думаю, вы можете разделить это на две проблемы, следуя эта рекомендация от Dillorscroft.

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

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

Во-вторых, что касается разработки компонентов, которые используются на сайте, им нужны свои собственные проекты разработки, так как это результат, который попадает на сайт разработки, а не все исходники, библиотеки и т. д., Из которых создается компонент. с участием. Таким образом, у них будет свое собственное дерево разработки проекта (представьте, что вы строите библиотеку, которая будет использоваться другими проектами разработки, хотя в этом случае другие проекты являются веб-страницами). Таким образом, единственное, что должно отображаться в IIS, - это «развернутый» компонент на сайте разработки.

Кажется, у вас есть три важных вопроса:

1. Как обрабатывается разработка тестов, которые должны соответствовать веб-сайту, и где это контролируется версией (при условии, что они не принадлежат самому веб-сайту)

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

3. Легко переносить разработанные компоненты из проектов, которые их создают, на сайт разработки и регистрировать их там.

Мое решение для (2) и контроля версий веб-сайта разработки - использовать интеграцию Visual Source Safe с расширениями IIS и FrontPage, которые помещают сайт под контроль версий. Компоненты, созданные из других проектов разработки, сопоставляются с серверным проектом с помощью совместного использования VSS.

Что касается SVN, я предполагаю, что (1) вы хотите увидеть, существует ли адаптер SVN, который IIS распознает как внешнюю систему управления версиями, и, в любом случае, (2) есть дисциплина, которая берет на себя доставку компонентов из их строительных проектов. в общий проект веб-сайта.

Роб,

Почему вы считаете файл .aspx выходом из базы кода?

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

Просто интересно?