Там, где я нахожусь, у нас есть большое количество программ, которые могут работать, все из которых используют функции из набора сборок, расположенных на сетевом ресурсе: такие вещи, как запись в общий системный журнал, строки подключения к БД, некоторые общие бизнес-объекты и функции и т. д.
Нам нравится эта настройка, потому что она упрощает развертывание исправлений ошибок и новые функции: просто обновляйте сборки на общем диске, и каждое приложение, которое их использует, обновлено. Нужно сломать бинарную совместимость? Это не сделано легко, но все же не имеет большого значения: просто добавьте новую папку с новым номером версии. Subversion знает, где находится каждая версия, поэтому исправления ошибок могут быть развернуты в коде, дублирующемся в каждой версии. Скорее всего, сначала будет проведено некоторое обсуждение, чтобы убедиться, что это действительно необходимо, и поэтому мы можем объединить несколько изменений в один новый набор, но необходимость сделать это вообще была довольно редкой на данный момент.
Для поддержки этого у нас есть несколько пользовательских шаблонов проектов, которые автоматически включают ссылки на общие библиотеки, и снова: нам действительно нравится эта настройка.
Теперь, наконец, о сути вопроса & mdash; многое из того, что мы делаем, - поддержка большого количества небольших устаревших классических ASP-страниц. Они, наряду с новыми разработками, также постепенно переходят на .Net. Мы действительно хотим иметь возможность использовать такую же структуру поддержки для этих веб-приложений, которые используют наши другие приложения. Традиционно считается, что приложение ASP.Net не может ссылаться на сборки за пределами GAC или своего собственного небольшого виртуального каталога. Таким образом, чтобы использовать наш общий код на наших страницах ASP.Net, лучшее, что мы могли бы сделать, - это установить его в GAC на веб-сервере и на каждой машине разработчика, а также убедиться, что каждое обновление этого кода распространяется и в этих местах. Мы находим это неприятным.
Учитывая, что мы можем дать учетной записи ASPNet необходимые разрешения для чтения из общей сетевой папки, в которой находится общий код, и что мы все равно будем создавать некоторые пользовательские шаблоны проектов для этих приложений (так что они могут автоматически включать некоторые параметры в например, web.config или подкласс обычного класса страниц asp.net в качестве отправной точки) Кто-нибудь знает какие-либо нетрадиционные знания, которые говорят, что мы можем ссылаться на эти сборки из их текущего местоположения в конце концов?