Путь к DLL, установленной в GAC

Как я могу получить (физический) установленный путь к DLL, которая (может быть) зарегистрирована в GAC? Эта DLL представляет собой элемент управления, который может размещаться не в приложении .Net (включая IDE, отличные от VS ...).

Когда я использую System.Reflection.Assembly.GetExecutingAssembly (). Location, он дает путь к папке GAC в winnt \ system32 - или в режиме разработки в VS дает путь к VS IDE.

Мне нужно получить путь, по которому фактически установлена ​​физическая dll - или папка bin / debug или (release) для VS.

Причина в том, что в этой папке есть XML-файл с настройками конфигурации, которые используются как в режиме разработки, так и во время выполнения.

Или как лучше всего справиться с этим сценарием? У меня есть сомнительное сетевое расположение, которое я использую для режима проектирования в настоящий момент ... (Не думайте, что папка ApplicationData собирается его вырезать (но есть версия .Net, установленная через ClickOnce, и можно использовать Clickonce Data папка) )


file c# dll gac
person kpollock    schedule 18.12.2008    source источник
comment
См. wikipedia.org/wiki/Global_Assembly_Cache   -  person stomy    schedule 30.04.2019

Ответы (4)


arrow_upward
24
arrow_downward

Если что-то помещается в GAC, оно фактически копируется в место под% WINDIR% \ assembly, например

C:\WINDOWS\assembly\GAC_32\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll

Я предполагаю, что вы видите что-то подобное, когда проверяете Местоположение рассматриваемой сборки, когда она установлена ​​в GAC. Это действительно так. (В .NET 1.1 была указана «база кода», когда вы просматривали свойства сборки GAC, но это было только для того, чтобы показать вам, где находится исходный файл при запуске gacutil - на самом деле он не указывал, что будет загружено. ) Подробнее об этом можно узнать здесь.

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

person Travis Illig    schedule 19.12.2008
comment
Я с самого начала хотел использовать стандартную папку ApplicationData в соответствии с вашим вторым предложением, но это должно быть в следующем выпуске, слишком поздно, чтобы делать это сейчас. У меня сейчас есть несколько возможных путей ... - person kpollock; 22.12.2008
comment
Указанный выше путь не будет работать для фреймворков ›= 4. Путь к GAC был изменен в .Net framework 4. Это% WINDIR% \ Microsoft.Net \ assembly \ GAC_MSIL. Должен быть общий и правильный способ получить это местоположение. - person Ven; 18.09.2018

arrow_upward
3
arrow_downward

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

Чего вы пытаетесь достичь, внедряя в GAC? Если это просто ради CLR для решения задач, то есть альтернативный способ решения вашей проблемы.

Не устанавливайте gac dll, а добавьте следующий ключ в реестр (это место реестра просматривается CLR при попытке разрешить сборки)

32 bit OS : HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\foo

64 bit OS : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\foo

Для клавиши foo (используйте ваше любимое имя вместо foo) вы увидите имя клавиши «По умолчанию». Дважды щелкните по нему и установите значение там, где существует ваша сборка. (желательно абсолютный путь)

Теперь из Visual Studio ваш клиент должен видеть ваши сборки в диалоговом окне «Добавить ссылку» и использовать его.

Теперь перейдем к вашей реальной проблеме,

Assembly.GetExecutingAssembly() вернет путь к местоположению, в котором находятся установленные DLL. Найдите там XML-файл. :)

Примечание. В разделе реестра 4.0.30319 - это версия .NET Framework, на которую ориентировано ваше приложение. Вместо этого используйте ту версию, на которую ориентировано ваше приложение.

person Soundararajan    schedule 06.12.2011

arrow_upward
3
arrow_downward

Есть ли у вас возможность встроить ресурс в эту DLL? Таким образом, на самом деле не имеет значения, где находится DLL на диске, потому что файл XML будет следовать за ней. Затем вы можете сделать что-то вроде этого:

Stream s = Assembly.GetExecutingAssembly().GetManifestResourceStream("MyProject.MyXmlFile.xml");
XmlDocument d = new XmlDocument();
using (StreamReader r = new StreamReader(s))
{
    d.LoadXml(r.ReadToEnd());
}
person BFree    schedule 18.12.2008
comment
Это то, что мы делали, но этот файл представляет собой файл настроек конфигурации, а это означает, что нам пришлось выполнить несколько сборок для разных сред. Идея состоит в том, чтобы сделать одну сборку и настроить файл конфигурации для управления настройками, зависящими от среды. - person kpollock; 18.12.2008

arrow_upward
2
arrow_downward

Если вы ищете физическое место, где ваша GACed DLL сохраняется в файловой системе, попробуйте следующее: start -> run -> c: \ windows \ assembly \ gac Если вы не найдете там папку, связанную с вашей DLL , вы можете создать папку «Вверх» в проводнике Windows, чтобы отображать все в c: \ windows \ assembly как структуры папок. Затем вы можете найти свою DLL в GAC_MSIL или в любой другой папке ...

Привет, Шри

person Community    schedule 06.08.2009
comment
извините, если я не понял, но я имел ввиду в коде! Это очень старый вопрос, на который в значительной степени отвечает отмеченный выше ответ. - person kpollock; 07.08.2009