Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / May 2006

Tip: Looking for answers? Try searching our database.

Reading assembly manifest without loading assembly

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Dale - 27 May 2006 17:44 GMT
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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.