I am working on a web application that is used for migrating other web
applications to production. The application currently loads each dll in the
target application using Assembly.LoadFile and then calls
GetCustomAttributes on the assembly to ensure it was not built in debug mode.
The problem with this approach is that it leaves the assembly loaded until
the worker process times out or is otherwise unloaded.
I need to be able to determine if the assembly was built in debug mode
without loading the assembly. Because we, by policy, build Release mode
with "Generate Debugging Information" set to true, we have a .pdb file even
in release so checking for the existence of the .pdb is not an option.
I assume the approach would mean to open the file as a binary file, parse
the appropriate metadata elements, and then close the file. Any ideas on how
to do read the metadata like this or on alternative methods to accomplish the
goal that leaves the target assembly files closed and unloaded?
Thanks in advance,
Dale

Signature
Dale Preston
MCAD C#
MCSE, MCDBA
Stephen Gennard - 28 May 2006 00:38 GMT
Hello Dale,
I had a very similar problem while developing a MsBuild task and I resorted
to using a separate AppDomain.
It now works a treat!
--
Stephen
> I am working on a web application that is used for migrating other web
> applications to production. The application currently loads each dll
[quoted text clipped - 20 lines]
>
> Dale
Dale - 28 May 2006 01:50 GMT
I appreciate the suggestion, Stephen.
I thought about that but in a web application that solution has all of the
same timing issues and risks as multi-threading a web app - waiting to get
the results without locking up the worker process.
I'd sure like to find a way to just read the metadata if possible.
Otherwise, you are most likely correct in your solution.
Thanks,
Dale

Signature
Dale Preston
MCAD C#
MCSE, MCDBA
> Hello Dale,
>
[quoted text clipped - 30 lines]
> >
> > Dale
Stephen Gennard - 28 May 2006 20:46 GMT
Hello Dale,
Have you tried just loading the assembly into a byte[] and using Assembly.Load(byte[]);
This may prevent the file lock.
--
Stephen
> I appreciate the suggestion, Stephen.
>
[quoted text clipped - 46 lines]
>>>
>>> Dale
Dale - 29 May 2006 01:19 GMT
That's a great suggestion. I feel a little silly for not seeing it myself.
Thank you. I'll give it a try next week.

Signature
Dale Preston
MCAD C#
MCSE, MCDBA
> Hello Dale,
>
[quoted text clipped - 54 lines]
> >>>
> >>> Dale
Greg Young - 28 May 2006 09:01 GMT
http://www.mono-project.com/Cecil should help you out.
Cheers,
Greg Young
MVP - C#
>I am working on a web application that is used for migrating other web
> applications to production. The application currently loads each dll in
[quoted text clipped - 22 lines]
>
> Dale
Dale - 29 May 2006 01:21 GMT
Thanks for the tip. I just checked out Cecil and loaded it in a project so I
could view it in the object browser. It definitely has the functionality I
need and the nice thing is I don't have to reinvent the wheel.
I am going to try Stephen Gennard's suggestion of using
Assembly.Load(Byte[]) first because that will work with the existing
application pretty easily but it is nice to have the Cecil suggestion in the
wings.
Thanks to all for helping me solve this problem.
Dale

Signature
Dale Preston
MCAD C#
MCSE, MCDBA
> http://www.mono-project.com/Cecil should help you out.
>
[quoted text clipped - 28 lines]
> >
> > Dale
Greg Young - 29 May 2006 02:39 GMT
There is a bigger problem which is not being mentioned about the
Assembly.Load method ..
If you are loading theses assemblies into your own appdomain, there is no
way to unload them after! The memory for the assembly will still be used by
the asp.net worker process .. using cecil this memory will not be lost as
you are working directly with the assembly (i.e. only dealing with the
metadata)
Cheers,
Greg Young
MVP - C#
> Thanks for the tip. I just checked out Cecil and loaded it in a project
> so I
[quoted text clipped - 49 lines]
>> >
>> > Dale
Dale - 29 May 2006 17:46 GMT
Good point. Of course, I live with that condition now as well, where the
application uses Assembly.Load with the assembly file path passed as a
parameter.
Since this application resides on a shared server with many other
applications, memory usage is a critical issue but when patching a production
application, you know how management will likely respond - do the quick fix
not the right fix. :)
But I think I will just estimate both solutions and let them make the call.
Thanks again,
Dale

Signature
Dale Preston
MCAD C#
MCSE, MCDBA
> There is a bigger problem which is not being mentioned about the
> Assembly.Load method ..
[quoted text clipped - 63 lines]
> >> >
> >> > Dale