I'm not very experienced in this area - so I've got a few questions. Firstly, do all .Net created DLLs have their own GUID? If not, my question is how do I get one and associate it with the DLL.
Then the question is, how do I get the GUID of that dll - ie. given a DLL path (c:\some\path\to\a\file.dll) how do I determine its GUID? Also, is there an easy way to go the other way (GUID -> DLL) - I've read a bit about this but a lot of it refers to VB6 DLLs and COM stuff...does this still apply to .Net DLLs?
Update: Thanks for the answers. Maybe I'm asking the wrong question. I want to have a unique ID for each of my DLL files, so that I can reference them in a database. I want to be able to take the unique ID stored in the database, and then easily find the DLL and do some stuff with it. From what the answers have said maybe I shouldn't be using a GUID, is there a .Net way to do this then?
To answer the second question (Guid -> assembly) this is simple if the dll is already loaded and you just want to find which one had a guid (if any) you can simply do
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
}
If you want to do it without it being loaded you would either need to load it into a temporary app domain, check it, then drop the app domain or use the unmanaged introspection api to do the same thing but with no need to release anything after.
I think you may be getting confused between managed assemblies and COM components. COM uses GUIDs to identify components and interfaces in the form of class IDs (CLSID) and interface IDs (IID). The information is stored in the registry and is used to create COM object instances. .Net does not use this mechanism to identify assemblies and classes. The analogous registration situation is where assemblies are strong named and stored in the GAC. There are several places that GUIDs are used in .Net - including COM interop - but assembly identification is not one of them.
The [assembly: Guid("...")] attribute is typically defined in your AssemblyInfo.cs file. By default, when you create a new project Visual Studio automatically provides a Guid for you, but this is really only useful if you are going to expose your assembly to COM. The .NET Framework itself does not use this value for determining how to load an assembly or in any way interact with it.
As a Visual Studio user have a look at the AssemblyInfo.cs where the assemblies GUID is defined
[assembly: Guid("abc...")]
I think the question we have to ask is why do you think you need a GUID for your assembly? You don't load by GUID or register a CLSID unless it's COM-usable.
