How to get the 4-part name of an assembly via reflection

[Guest]

Trying to use reflection to obtain the 4-part name of a strong named assembly
(assembly, version, culture, publickeytoken) and immediately release the
reference. I’m currently doing the following:

Assembly projectAssembly =
Assembly.ReflectionOnlyLoadFrom(projectAssemblyFullPath);
fourPartName = projectAssembly.FullName;
projectAssembly = null;

The problem is that the reference to the assembly is still being held after
I set it to null which isn’t ideal… this is keeping Visual Studio from
building the project as it can’t overwrite the assembly in the \bin\debug
directory (this is a plugin-like project I’m working on). Looking for any
method to force a release of the assembly or another process to obtain this
4-part name. Ideas?

 

[Jesse Houwing]

* AC [MVP MOSS] wrote, On 25-7-2007 14:40:

Trying to use reflection to obtain the 4-part name of a strong named assembly
(assembly, version, culture, publickeytoken) and immediately release the
reference. I’m currently doing the following:

Assembly projectAssembly =
Assembly.ReflectionOnlyLoadFrom(projectAssemblyFullPath);
fourPartName = projectAssembly.FullName;
projectAssembly = null;

The problem is that the reference to the assembly is still being held after
I set it to null which isn’t ideal… this is keeping Visual Studio from
building the project as it can’t overwrite the assembly in the \bin\debug
directory (this is a plugin-like project I’m working on). Looking for any
method to force a release of the assembly or another process to obtain this
4-part name. Ideas?

If you load it into a new AppDomain in your plugin, you can dispose of
that after you're done with it. Disposing an AppDomain should also
release all assemblies loaded into that domain. My guess is that you
could also use the Microsoft.Cci Assembly that comes with FxCop, but
that might be harder to accomplish given that there is little
documentation for it's API.

Jesse

 

[Guest]

Hmm... I'm a bit unclear how to do this. Maybe a bit more context helps...

The plugin is running within the context of VS 2005. I need to quickly
relfect an assembly to grab the 4-part name and then release it. The problem
is that I can't dump the app domain because that dumps VS 2005. As long as
it's got a handle to the assembly loaded, VS can rebuild the project really
killing my solution.

Maybe there's another way to get the 4-part name w/o reflection?

--
-AC [MVP MOSS]
http://www.andrewconnell.com
http://www.andrewconnell.com/mvp
http://www.andrewconnell.com/blog

* AC [MVP MOSS] wrote, On 25-7-2007 14:40:

Trying to use reflection to obtain the 4-part name of a strong named assembly
(assembly, version, culture, publickeytoken) and immediately release the
reference. I’m currently doing the following:

Assembly projectAssembly =
Assembly.ReflectionOnlyLoadFrom(projectAssemblyFullPath);
fourPartName = projectAssembly.FullName;
projectAssembly = null;

The problem is that the reference to the assembly is still being held after
I set it to null which isn’t ideal… this is keeping Visual Studio from
building the project as it can’t overwrite the assembly in the \bin\debug
directory (this is a plugin-like project I’m working on). Looking for any
method to force a release of the assembly or another process to obtain this
4-part name. Ideas?

If you load it into a new AppDomain in your plugin, you can dispose of
that after you're done with it. Disposing an AppDomain should also
release all assemblies loaded into that domain. My guess is that you
could also use the Microsoft.Cci Assembly that comes with FxCop, but
that might be harder to accomplish given that there is little
documentation for it's API.

Jesse

 

[Jesse Houwing]

* AC [MVP MOSS] wrote, On 25-7-2007 17:50:

Hmm... I'm a bit unclear how to do this. Maybe a bit more context helps...

The plugin is running within the context of VS 2005. I need to quickly
relfect an assembly to grab the 4-part name and then release it. The problem
is that I can't dump the app domain because that dumps VS 2005. As long as
it's got a handle to the assembly loaded, VS can rebuild the project really
killing my solution.

Maybe there's another way to get the 4-part name w/o reflection?

You need to create a new (temporary) AppDomain in you process. You can
then use a class you've loaded in your new AppDomain to load the
assembly in the new domain, get the info with reflection and return it
your old AppDomain. Then from the old AppDomain unload the temporary
AppDomain.

I don't have the code handy and it needs some experimenting to get it
right. Maybe someone can jump in and help you further.

Jesse

 

[Guest]

Ah... now that sounds like the trick. I'm sure I can figure this out with the
SDK... thanks Jesse!

--
-AC [MVP MOSS]
http://www.andrewconnell.com
http://www.andrewconnell.com/mvp
http://www.andrewconnell.com/blog

* AC [MVP MOSS] wrote, On 25-7-2007 17:50:

Hmm... I'm a bit unclear how to do this. Maybe a bit more context helps...

The plugin is running within the context of VS 2005. I need to quickly
relfect an assembly to grab the 4-part name and then release it. The problem
is that I can't dump the app domain because that dumps VS 2005. As long as
it's got a handle to the assembly loaded, VS can rebuild the project really
killing my solution.

Maybe there's another way to get the 4-part name w/o reflection?

You need to create a new (temporary) AppDomain in you process. You can
then use a class you've loaded in your new AppDomain to load the
assembly in the new domain, get the info with reflection and return it
your old AppDomain. Then from the old AppDomain unload the temporary
AppDomain.

I don't have the code handy and it needs some experimenting to get it
right. Maybe someone can jump in and help you further.

Jesse

 

[Jesse Houwing]

* AC [MVP MOSS] wrote, On 25-7-2007 20:22:

Ah... now that sounds like the trick. I'm sure I can figure this out with the
SDK... thanks Jesse!

You're welcome. Good luck

Jesse

 

[Mattias Sjögren]

Maybe there's another way to get the 4-part name w/o reflection?

System.Reflection.AssemblyName.GetAssemblyName(projectAssemblyFullPath)

You could argue that that is actually using Reflection, but at least
it doesn't require loading the assembly.


Mattias