GUID в библиотеках DLL (.Net)

Я не очень опытен в этой области, поэтому у меня есть несколько вопросов. Во-первых, все ли DLL, созданные .Net, имеют собственный GUID? Если нет, мой вопрос в том, как мне его получить и связать с DLL.

Тогда вопрос в том, как мне получить GUID этой dll, т.е. учитывая путь к DLL (c:\some\path\to\a\file.dll), как определить его GUID? Кроме того, есть ли простой способ пойти другим путем (GUID -> DLL) - я немного читал об этом, но многие из них относятся к библиотекам DLL VB6 и материалам COM... это все еще применимо к .Net DLL. ?

Обновление: спасибо за ответы. Может быть, я задаю неправильный вопрос. Я хочу иметь уникальный идентификатор для каждого из моих файлов DLL, чтобы я мог ссылаться на них в базе данных. Я хочу иметь возможность получить уникальный идентификатор, хранящийся в базе данных, а затем легко найти DLL и что-то с ней сделать. Судя по ответам, возможно, мне не следует использовать GUID, есть ли тогда способ .Net для этого?


person robintw    schedule 28.01.2009    source источник
comment
Ну, как вы собираетесь их «найти». Где они хранятся, в gac на вашей локальной машине? если это так, то они должны быть строго названы, если это просто файлы, то наверняка база данных хранит путь к ним, и в этот момент guid не имеет смысла, кроме как на этапе проверки...   -  person ShuggyCoUk    schedule 29.01.2009


Ответы (5)


Чтобы ответить на второй вопрос (Guid -> сборка), это просто, если dll уже загружена, и вы просто хотите найти, у какой из них был guid (если есть), вы можете просто сделать

using System;
using System.Reflection;
using  System.Runtime.InteropServices;

static Assembly FindAssemblyForGuid(Guid match)
{
    foreach (var a in AppDomain.CurrentDomain.GetAssemblies())
    {
        object[]  attributes = a.GetCustomAttributes(typeof(GuidAttribute)) ;
        if ( attributes.Length > 0 ) 
        {
            foreach (GuidAttribute g in attributes )
            {
                if (g.Value == match)
                    return a;
            }
        }
    }
    return null; // failed to find it
}

Если вы хотите сделать это без его загрузки, вам нужно либо загрузить его во временный домен приложения, проверить его, а затем удалить домен приложения, либо использовать неуправляемый API самоанализа, чтобы сделать то же самое, но без необходимости выпускать что-либо после.

person ShuggyCoUk    schedule 28.01.2009

Я думаю, вы можете запутаться между управляемыми сборками и COM-компонентами. COM использует идентификаторы GUID для идентификации компонентов и интерфейсов в виде идентификаторов классов (CLSID) и идентификаторов интерфейса (IID). Информация хранится в реестре и используется для создания экземпляров COM-объектов. .Net не использует этот механизм для идентификации сборок и классов. Аналогичная ситуация с регистрацией, когда сборки имеют строгие имена и хранятся в GAC. Есть несколько мест, где GUID используются в .Net, включая COM-взаимодействие, но идентификация сборки не входит в их число.

person Stu Mackellar    schedule 28.01.2009
comment
Спасибо за ваш ответ, я обновил вопрос сейчас, чтобы, надеюсь, сделать то, что я искал, немного яснее. - person robintw; 29.01.2009

Атрибут [assembly: Guid("...")] обычно определяется в файле AssemblyInfo.cs. По умолчанию, когда вы создаете новый проект, Visual Studio автоматически предоставляет вам Guid, но на самом деле это полезно только в том случае, если вы собираетесь предоставлять свою сборку для COM. Сама платформа .NET Framework не использует это значение для определения того, как загружать сборку или каким-либо образом взаимодействовать с ней.

person Scott Dorman    schedule 28.01.2009

Как пользователь Visual Studio, посмотрите AssemblyInfo.cs, где определен GUID сборки [assembly: Guid("abc...")]

person Sebastian    schedule 28.01.2009

Я думаю, вопрос, который мы должны задать, заключается в том, почему, по вашему мнению, вам нужен GUID для вашей сборки? Вы не загружаете GUID или не регистрируете CLSID, если только он не используется COM.

person ctacke    schedule 28.01.2009