GAC, Machine.Config installation can't read errors
Elton
take the plunge and add it to the GAC and the machine.config file. I'm
using the 2.0 version recently posted.
I added the dll to the GAC using good 'ol drag and drop.
I've modified
C:\WINNT\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
following the example in the 2.0 project. (This is a W2K/IIS 5 box)
I've created a sql database, and removed the ELMAH entries from app
that originally had them.
Errors are recorded in the database and I'm getting the emails, however
trying to view them on-line doesn't work. I get a 404 error. I've
tried the default path and a number of variations.
Here is the section from machine.config
<httpHandlers>
<!-- Allows you to view ELMAH errors @
http://<YourVirtualRoot>/elmah/default.aspx -->
<add
verb="POST,GET,HEAD"
path="errlog.aspx"
type="GotDotNet.Elmah.ErrorLogPageFactory, GotDotNet.Elmah,
Version=2.0.50727.42, Culture=neutral, PublicKeyToken=89e7ba9b9c08cfca"
/>
</httpHandlers>
I get a 404. Here is the db entry:
<error host="SL-WEB" type="System.Web.HttpException" message="The file
'/errlog.aspx' does not exist." source="System.Web"
detail="System.Web.HttpException: The file '/errlog.aspx' does not
exist.
 at System.Web.UI.Util.CheckVirtualFileExists(Vi
Any help is appreciated, as is the original tool!
Thanks!
Atif Aziz
Elton
Here is the whole entry. Sorry for the formatting....
C63B0616-AA25-447B-89CA-2F858B086643,/LM/W3SVC/17/Root,SL-WEB,System.Web.HttpException,System.Web,The
file '/errlog.aspx' does not exist.,,404,2006-07-25
22:04:53.563,8,<error host="SL-WEB" type="System.Web.HttpException"
message="The file '/errlog.aspx' does not exist." source="System.Web"
detail="System.Web.HttpException: The file '/errlog.aspx' does not
exist.
 at
System.Web.UI.Util.CheckVirtualFileExists(VirtualPath
virtualPath)
 at
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath
virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean
allowBuildInPrecompile)
 at
System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext
context, VirtualPath virtualPath, Boolean noBuild, Boolean
allowCrossApp, Boolean allowBuildInPrecompile)
 at
System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath
virtualPath, HttpContext context, Boolean allowCrossApp, Boolean
noAssert)
 at
System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath
virtualPath, Type requiredBaseType, HttpContext context, Boolean
allowCrossApp, Boolean noAssert)
 at
System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context,
String requestType, VirtualPath virtualPath, String
physicalPath)
 at
System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext
context, String requestType, VirtualPath virtualPath, String
physicalPath)
 at
System.Web.HttpApplication.MapHttpHandler(HttpContext context, String
requestType, VirtualPath path, String pathTranslated, Boolean
useAppConfig)
 at
System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously)"
time="2006-07-25T18:04:53.5625-04:00" statusCode="404">
Atif Aziz
hints than those that were available in your original mail. It seems
like ASP.NET is looking for a physical file to back up the virtual path
and therefore bombs with a 404. It looks like this might be a problem to
do with the order in which the handlers are getting processed. Did you
put the httpHandler entry at the top of the handlers list in
machine.config or right at the bottom? It should go somewhere before the
entry for *.aspx, otherwise you will get a 404. The safest place is to
put it right after the opening of the <httpHandlers> section.
-----Original Message-----
From: el...@googlegroups.com [mailto:el...@googlegroups.com] On Behalf
Of Elton
Eric
which is in the same directory like machine.config.
There are also all the predefined http handlers.
Atif Aziz
so I am jotting down my understanding here since there seems to be no
real good documentation on this in MSDN.
Normally, it shouldn't matter where you put the <system.web> stuff
because it gets picked up even from machine.config for ASP.NET 2.0. For
example, if you configure the ELMAH module in machine.config, it gets
picked up and works just fine. This means that the ELMAH handler factory
is definitely getting picked up too if you put it in machine.config. The
question is then why do you get a 404 nonetheless? Obviously the order
matters so it's crucial to understand where ELMAH's handler ends up in
the collection of handlers depending on which file you put it in. The
MSDN documentation doesn't seem to explain anywhere (at least, not to my
knowledge and searches) how the order of processing takes place between
web.config and machine.config so one is left alone to experiment. If I
work through the observations so far, I would say that machine.config is
processed first and then comes the *root* web.config. Consequently, the
root web.config must be inheriting handlers and modules from
machine.config. This would normally mean that the ELMAH handler in
machine.config comes first in the collection and you shouldn't be
getting a 404! But there's a slight and subtle twist that turns
everything upside down. You see, unlike other collections, the handlers
collection is an *inversed* collection such that inherited items go at
the end. This means the ELMAH handler inherited from machine.config
actually ends up *after* those in the root web.config. When a request
comes along for "elmah.aspx", you get a 404 because the *.aspx entry
matches first and its handler goes looking for an ASPX file on disk to
compile but can't find any. The setup is a bit unfortunate because it
makes configuring any handler in machine.config completely useless and
arguably even incompatible with the model back in ASP.NET 1.x.
In conclusion, it seems that for ASP.NET 2.0, the safest place for the
handler configuration is in the root web.config that sits next to
machine.config. Even there, it the ELMAH handler factory must go before
the *.aspx entry (or whatever extension you choose).
-----Original Message-----
From: el...@googlegroups.com [mailto:el...@googlegroups.com] On Behalf
Of Eric
Sent: Thursday, July 27, 2006 1:26 AM
To: ELMAH
Subject: Re: GAC, Machine.Config installation can't read errors
Eric
I thought, it was known that in 2.0 machine.config and web.config are
merged together.
And because the web.config is only useful for web applications and the
machine.config is used for each application type,
it's seemed clear to me, that the machine.config is parsed first.
It's not only the safest place, it's also the only place where you
should put web application settings.
Atif Aziz
I thought, it was known that in 2.0 machine.config and web.config are
merged together.
<<
That's true, but it's not really indicated in the documentation like
that and so it did puzzle me for a while until I decided to sit down and
figure it out what really must be going on behind the scenes. And as we
discovered in this case, the details matter. I believe that web.config
was introduced as a separate file for reasons of size and performance. I
don't mind that as long as it doesn't create new and surprising behavior
or it is documented as a breaking change (which it isn't).
-----Original Message-----
From: el...@googlegroups.com [mailto:el...@googlegroups.com] On Behalf
Of Eric
Sent: Thursday, July 27, 2006 11:37 AM
To: ELMAH
Subject: Re: GAC, Machine.Config installation can't read errors
Eric
http://msdn2.microsoft.com/en-us/library/ms178685.aspx
There are also some books which have some explanations (ASP.NET 2.0
Applications - Advanced Topics)
Atif Aziz
places where there was only machine.config mentioned for ASP.NET 2.0. I
finally did end up at the link you've sent below, but here's what I felt
was still missing that would've help to understand the *observed*
behavior in the first place:
1. A mention that handlers are reverse-inherited. In contrast, modules
are forward-inherited so they work even from machine.config.
2. A mention that says handlers in machine.config can simply *never*
work because of point #1. The wildcard handlers in web.config will
always take precedence.
What finally gave away was the CollectionType override on
HttpHandlerActionCollection class:
http://msdn2.microsoft.com/en-us/library/system.web.configuration.httpha
ndleractioncollection.collectiontype.aspx
Query this property at run-time and you get this value:
ConfigurationElementCollectionType.AddRemoveClearMapAlternate
The documentation for this type of collection says, "Same as
AddRemoveClearMap, except that this type causes the
ConfigurationElementCollection object to sort its contents such that
inherited elements are listed last." At this point, everything fell in
place. :)
The important lesson to take away I guess is that if you don't want
surprises then just don't mess with the machine.config for ASP.NET 2.0
even if it's legal to put web-related stuff in there, even if it is
inherited, and even if it should logically work as it did for modules.
Thanks anyhow for digging the link and posting it here.
-----Original Message-----
From: el...@googlegroups.com [mailto:el...@googlegroups.com] On Behalf
Of Eric
Sent: Thursday, July 27, 2006 1:33 PM
To: ELMAH
Subject: Re: GAC, Machine.Config installation can't read errors
Elton
us mortals:
1)<configSections>
<sectionGroup name="gotdotnet.elmah">
must come immediately after the <configuration> tag.
2) Add the ELMAH hander at the TOP of the <httpHandlers> section.