|
|
You're in the
dotnet clr
group:Reading assembly manifest without loading assembly
dotnet clr:
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 -- Dale Preston MCAD C#
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 -- Dale Preston MCAD C# MCSE, MCDBA [quoted text, click to view] "Stephen Gennard" wrote:
> 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 > > 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 > > > >
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 [quoted text, click to view] > 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 >
http://www.mono-project.com/Cecil should help you out.
Cheers, Greg Young MVP - C# [quoted text, click to view] "Dale" <dale0973@nospam.nospam> wrote in message news:D13CA1E4-EDB2-4D8E-B23F-428969A43739@microsoft.com... >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 > -- > Dale Preston > MCAD C# > MCSE, MCDBA
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. -- Dale Preston MCAD C# MCSE, MCDBA [quoted text, click to view] "Stephen Gennard" wrote:
> 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. > > > > 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 > > > > "Stephen Gennard" wrote: > > > >> 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 > >>> 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 > >>> > >
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 -- Dale Preston MCAD C# MCSE, MCDBA [quoted text, click to view] "Greg Young" wrote:
> http://www.mono-project.com/Cecil should help you out. > > Cheers, > > Greg Young > MVP - C# > "Dale" <dale0973@nospam.nospam> wrote in message > news:D13CA1E4-EDB2-4D8E-B23F-428969A43739@microsoft.com... > >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 > > -- > > Dale Preston > > MCAD C# > > MCSE, MCDBA > >
Hello Dale,
Have you tried just loading the assembly into a byte[] and using Assembly.Load(byte[]); This may prevent the file lock. -- Stephen [quoted text, click to view] > 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 > > "Stephen Gennard" wrote: > >> 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 >>> 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 >>>
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# [quoted text, click to view] "Dale" <dale0973@nospam.nospam> wrote in message news:2FECBBA1-E0D5-4865-B055-1F8AF18F6402@microsoft.com... > 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 > -- > Dale Preston > MCAD C# > MCSE, MCDBA > > > "Greg Young" wrote: > >> http://www.mono-project.com/Cecil should help you out. >> >> Cheers, >> >> Greg Young >> MVP - C# >> "Dale" <dale0973@nospam.nospam> wrote in message >> news:D13CA1E4-EDB2-4D8E-B23F-428969A43739@microsoft.com... >> >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 >> > -- >> > Dale Preston >> > MCAD C# >> > MCSE, MCDBA >> >> >>
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 -- Dale Preston MCAD C# MCSE, MCDBA [quoted text, click to view] "Greg Young" wrote:
> 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# > > "Dale" <dale0973@nospam.nospam> wrote in message > news:2FECBBA1-E0D5-4865-B055-1F8AF18F6402@microsoft.com... > > 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 > > -- > > Dale Preston > > MCAD C# > > MCSE, MCDBA > > > > > > "Greg Young" wrote: > > > >> http://www.mono-project.com/Cecil should help you out. > >> > >> Cheers, > >> > >> Greg Young > >> MVP - C# > >> "Dale" <dale0973@nospam.nospam> wrote in message > >> news:D13CA1E4-EDB2-4D8E-B23F-428969A43739@microsoft.com... > >> >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 > >> > -- > >> > Dale Preston > >> > MCAD C# > >> > MCSE, MCDBA > >> > >> > >> > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |