GUID в DLL (.Net)

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

Чтобы ответить на второй вопрос (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-интерфейс неуправляемого самоанализа, чтобы сделать то же самое вещь, но без необходимости выпускать что-либо после.

Answer 4

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

Answer 5

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