Требуется пояснение: как среда выполнения .NET разрешает ссылки на сборки из родительской папки? - PullRequest
Новая
       13

Требуется пояснение: как среда выполнения .NET разрешает ссылки на сборки из родительской папки?

1 голос
/ 20 января 2009

У меня есть следующая структура вывода исполняемых файлов в моем решении: 

%ProgramFiles%
    |
    +-[MyAppName]
          |
          +-[Client]
          |     |
          |     +-(EXE & several DLL assemblies)
          |
          +-[Common]
          |     |
          |     +-[Schema Assemblies]
          |     |     |
          |     |     +-(several DLL assemblies)
          |     |
          |     +-(several DLL assemblies)
          |
          +-[Server]
                |
                +-(EXE & several DLL assemblies)

Каждый проект в решении ссылается на разные сборки DLL, некоторые из которых являются выходами из других проектов в решении, а другие являются сторонними сборками. Например, [Client] EXE может ссылаться на сборку в [Common], которая находится в другой ветви каталога.

Для всех ссылок "Локальное копирование" установлено в значение false, чтобы отразить расположение файлов в окончательно установленном приложении.

Теперь, если я взгляну на свойства ссылок в IDE Visual Studio, я увижу, что «Путь» каждой ссылки является абсолютным и соответствует фактическому выходному местоположению сборки. Это понятно и правильно. Как и ожидалось, решение компилируется и работает просто отлично.

Чего я не понимаю, так это того, почему все работает, даже когда я закрываю IDE, переименовываю каталог [MyAppName] и запускаю [Client] EXE вручную? Как среда выполнения находит сборки, если пути ссылок не совпадают с теми, которые были в момент компоновки?

Для ясности - это именно то, что мне нужно: полудисперсный набор файлов приложений, которые работают нормально, независимо от того, где находится каталог [MyAppName] или даже как он называется. Я просто хотел бы знать, как и почему это работает без какого-либо конкретного разрешения пути с моей стороны.

Я прочитал ответы на этот похожий вопрос , но до сих пор не понимаю.

Помощь очень ценится!

Ответы [ 4 ]

1 голос
/ 25 апреля 2009

AFAIK единственное решение состоит в том, чтобы иметь по крайней мере "заглушки" exes в MyAppBase, а затем определять подкаталоги как источники для DLL в app.config для каждого приложения.

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

0 голосов
/ 05 мая 2010

Может быть, общая папка была указана в качестве параметра binpath при компиляции?

(см. Зондирование частного бинпата)

http://msdn.microsoft.com/en-us/library/15hyw9x3%28VS.71%29.aspx

Матф

0 голосов
/ 20 января 2009

Рассматривали ли вы использование GACutil для добавления ваших общих сборок в Global Assembly Cache

0 голосов
/ 20 января 2009

Вот как .Net находит нужные сборки: http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

Шаг 4 - это то, что вам может быть интересно прочитать: http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

...