Как работать с несколькими версиями сборки в личных папках с помощью config? - PullRequest
Новая
       44

Как работать с несколькими версиями сборки в личных папках с помощью config?

4 голосов
/ 12 марта 2009

У меня есть сценарий, в котором у меня есть несколько версий одной и той же сборки, которые мне нужно хранить в личных папках приложения, в такой структуре: 

.\My.dll          // latest version, say 1.1.3.0
.\v1.1.1\My.dll   // version 1.1.1.0
.\v1.1.2\My.dll   // version 1.1.2.0

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

Сборки имеют строгое имя, и я использую эту конфигурацию в моем app.config: 

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="My" 
                publicKeyToken="xxxxxxxx" culture="netural" />

                <bindingRedirect oldVersion="1.0.0.0-1.1.1.0" 
                    newVersion="1.1.1.0" />
                <bindingRedirect oldVersion="1.1.3.0-1.1.65535.65535" 
                    newVersion="1.1.3.0" />

                <codeBase version="1.1.1.0" href="v1.1.1\My.dll" />
                <codeBase version="1.1.2.0" href="v1.1.2\My.dll" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

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

Обновление: Итак, я обнаружил ошибку, которая, как предположил Кент, была опечаткой. culture="netural" должно быть culture="neutral". Тем не менее, без опечатки, решение прекрасно работает при использовании codeBase элементов, которые указывают на каждую версию. Похоже, что зондирующий элемент не работает в этом сценарии.

Ответы [ 2 ]

1 голос
/ 19 марта 2009

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

У меня есть три версии сборки, и приложение-потребитель ссылается на более старую версию, чем та, которая находится в его выходном каталоге. CLR находит записи перенаправлений и codeBase и загружает правильную (более старую) версию.

Я могу отправить вам свое решение по электронной почте, если вы укажете адрес электронной почты.

Kent

0 голосов
/ 18 марта 2009

Можете ли вы использовать пробепат? мы используем это, чтобы заставить неконтролируемых (например, сторонних распознавателей, таких как MSTest) искать сборки, где они нам нужны. 

<?xml version ="1.0"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="v1.1.1;v1.1.2;"/>
        </assemblyBinding>
    </runtime>
</configuration>

См. здесь для получения дополнительной информации

...