Entry Assembly in ASP.NET Application?

[Philipp Schumann]

Hi,

In a class library that may be consumed by .exe as well as web applications,
I need to determine the "main" or "entry" assembly of the current
application. Unfortunately, Assembly.GetEntryAssembly() doesn't produce the
main assembly of a currently executing web application, for example
"c:\inetpub\wwwroot\my.site.dll" (which would be better than a temporary
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\my.site\934aac6a\e239367\kmbnrlfj.dll" or whatever path -- which I
don't get either, GetEntryAssembly simply returns null in a web context).

Any ideas?
Many thanks,
Phil

 

[Scott Allen]

How about Process.GetCurrentProcess().ProcessName? Is that the info
you are after?

 

[Philipp Schumann]

Hi Scott,

thanks, but for a web application, this would probably be inetinfo.exe or
the ASP.NET worker process. What I want is the Assembly that provides the
entry point for the application, which is a DLL in web applications.

 

[Scott Allen]

Right, ok.

I can see GetEntryAssembly returns null for me too.

Perhaps this is a questions of which assembly is really the 'entry'
assembly. Would the entry assembly be the assembly created when the
code behind files were compiled? Or the assembly created when the
first request arrives and ASPX pages are codegen'ed and compiled? I'm
not sure what the answer would be.

 

[Philipp Schumann]

Hi Scott,

well, generally speaking I wouldn't be sure, but for my special case, I'm
looking for the former and completely ignore the latter case. Although quite
often, both seems to be the case anyway - people have app-specific
code-behind logic in a web app DLL, but that app also has aspx and ascx
associated with it, which can be changed on the fly, with the appropriate
assemblies

 

[Philipp Schumann]

being re-compiled during the next web request...

Hi Scott,

well, generally speaking I wouldn't be sure, but for my special case, I'm
looking for the former and completely ignore the latter case. Although
quite often, both seems to be the case anyway - people have app-specific
code-behind logic in a web app DLL, but that app also has aspx and ascx
associated with it, which can be changed on the fly, with the appropriate
assemblies