Ну, проблема в том, как организовать сборки для нескольких WCF служб, размещенных в одном домене, когда службы могут использовать разные версии одних и тех же ссылочных сборок?
Дело в том,что у меня есть серия служб WCF , которые в настоящее время размещены в одном и том же домене, но бремя обновления одной из этих служб огромно из-за того, что я не могу быть уверен, что не сломаю другие службы, когдаделать это.Следовательно, требуется, чтобы я обновлял все другие службы с помощью новой версии сборки или сборок, которые я собираюсь опубликовать.
Обновление службы - в моем случае - было бы изменить одно илибольше сборок в папке bin .Проблема в том, что другие сервисы могут нуждаться в таких же сборках.Я хотел бы иметь возможность определять подпапки с именем службы, и в каждой из этих папок есть подпапка bin , файл .svc и все другие вещи, связанные ссервис.Таким образом, я мог бы изолировать службу в том же домене.
Я искал решение и нашел сообщение в блоге Скотт Хансельман о проверке, но, похоже, это относится к .NET 1.1 , ASP.NET ...
http://www.hanselman.com/blog/PermaLink.aspx?guid=4d0ef4fb-f8ae-4355-a658-3c0432c98dbe
К сожалению, я не могу заставить его работать в моем сценарии (.NET 4.0 ).Кроме того, я не уверен, что это будет масштабироваться так, как мне нужно.Даже если бы я мог заставить это работать, тогда это будет отдельный Домены приложений , и если нет, это было бы проблемой?Мне нужна полная изоляция службы, но она по-прежнему находится в том же домене.
Спасибо, Джейкоб.
Обновление
Собственно, яполучил немного дальше.Я попытался поместить [ServiceName] .svc.cs и интерфейс в его собственный проект и скомпилировать его, а затем слегка изменить файл .svc , чтобы он ссылался на только что созданную сборку какописанный Hanselman .Если я пропущу оператор Import , также упомянутый в его посте, и выполним другие биты, то он действительно сработает.
Единственное, если у меня есть список путей, что-то вроде...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Tasks\bin;Products\bin"/>
</assemblyBinding>
</runtime>
... тогда можно ли быть уверенным, что используемые сборки находятся в нужной папке и не разрешены в порядке их появления в списке?Примером может служить случай, если ProductsService использует ту же сборку, что и TaskService , но в другой версии, тогда, если сборка разрешается в том порядке, в котором они отображаются в privatePath строка выше, тогда он будет использовать неправильную сборку, я думаю?Тогда он не полностью изолирован в конце концов.
Если я прав в этом предположении, то, возможно, ответом будет сильное имя?
Еще раз спасибо, Джейкоб.