Just got ELMAH running, and so far it seems great. I am wondering two things:
I am using ELMAH from multiple applications, all logging to the same table in MSSQL. Will I be able to drop the .axd file in any project to browse all the logs, or will I need a custom solution? (The latter seems more likely, so I can have filtering options, but I'm just trying to verify.)
Is elmah.axd somehow customizeable? I'd rather modify it than write my own, so that I could add the ApplicationName column to its listing.
We just released our ELMAH based exception reporting solution on codeplex: http://aspexceptionreporter.codeplex.com/
One of the features is that it logs errors of multiple web sites to a central location. The project includes a web site to view and search through the errors.
ELMAH, by default, is set up to figure out under which application it is running and will filter the displayed errors based on that application. So, as for your question 1, no, you won't be able to call the .axd from an app and see the errors for all apps. At least not without some extra work. See also this related question.
As for question 2, the default viewer is not designed to be "customized". By that, I mean there aren't any markup parameters you can give it to change the columns it displays. ELMAH itself is open source, though, so you can easily download the source and build a customized version. I would start by having a look at ErrorLogPage.cs, which is the class that "Renders an HTML page displaying a page of errors from the error log."
Related
As I try to build this project, I keep coming up with an error.
Description, where the eight '*' are always something different with every build:
An error occurred when merging assemblies: ILMerge.Merge: ERROR!!: Duplicate type 'myTypeName' found in assembly 'App_Web_********'.
and the file is
aspnet_merge
What do I need to do in order to resolve this (annoying) error?
A couple of things you can try is after right clicking on your project, select Publish Web App. Then under settings (settings for me, might be different for you), find your File Publish Options and click Configure. You'll see the dialog below.
Try the first or second option, Do not merge OR Do not merge. Create a separate assembly for each page and control
I know this is something that has plagued me in the past so good luck. Update us if you find any better or if something better works for you.
I am using elmah to handle exceptions. Now my needs have been increased and I want to log some warnings after few statements like NLog.
Here i want to add data in SQL database. I also want to add one column in elmh table, which tells me which row is belongs to error and which belongs to warning, because I need to render them separately.
Eg. ElmahError.axd and ElmahWarn.axd.
I may need to override elmah class to achieve this, but is there any other library which gives both features, error handling and logging?
What is the best way to get this done?
If you want to log warnings in ELMAH, you will need to log it as an exception. You can create a custom exception named WarningException or something. With that said, ELMAH is created for errors and doesn't really fit well with other severities.
Adding custom data to ELMAH isn't possible either. Unless you fork the ELMAH source code and create a custom build of course. You will need to extend the Error class among others.
I'm the founder of the cloud-based error management system elmah.io. We support all severities known from other logging frameworks. With my experiences developing elmah.io, I will recommend you to use ELMAH what it's good for (logging errors) and combining it with a logging framework of choice. We use Serilog to get structured logging in Elasticsearch, but NLog, log4net etc. should do the job as well.
The challenge is to determine whether ASP.NET is enabled within IIS7 in a reliable and correct way.
Enabling/Disabling is done in this case by going into:
Server Manager ->
Roles ->
Web Server (IIS) ->
Remove Role Services ->
Remove ASP.NET
The natural place to determine this should be within the applicationHost.config file. However, with ASP.NET enabled or disabled, we still have the "ManagedEngine" module available, and we still have the isapi filter record in the tag.
The best I can find at the moment is to check if the <isapiCgiRestriction> tag includes the aspnet_isapi.dll, or that the ASPNET trace provider is available.
However these aren't detecting the presence of the ASP.NET config directly, just a side effect that could conceivably be reconfigured by the user.
I'd rather do this by examining the IIS configuration/setup rather than the OS itself, if possible, although enumerating the Roles & Services on the server might be acceptable if we can guarantee that this technique will always work whenever IIS7 is used.
Update
Thanks for the responses. Clarifying exactly what I want to do, I'm pulling settings from a variety of places in the server's configuration into a single (readonly) view to show what the user needs to have configured to allow the software to work.
One of the settings I need to bring in is this one:
The one highlighted in red.
I don't need to manipulate the setting, just reproduce it. I want to see whether the user checked the ASP.NET box when they added the IIS role to the server, as in this example they clearly didn't.
I'd like to do this by looking at something reliable in IIS rather than enumerating the role services because I don't want to add any platform specific dependencies on the check that I don't need. I don't know if it will ever be possible to install IIS7 on a server that doesn't have the Roles/Services infrastructure, but in preference, I'd rather not worry about it. I also have a load of libraries for scrubbing around IIS already.
However, I'm also having trouble finding out how to enumerate the Roles/Services at all, so if there's a solution that involves doing that, it would certainly be useful, and much better than checking the side effect of having the ASPNET trace provider lying around.
Unfortunately, if you don't check the ASP.NET button, you can still get the ManagedEngine module in the IIS applicationHost.config file, so it's not a reliable check. You can also have ASP.NET mapped as an isapi filter, so checking them isn't enough. These things are especially problematic in the case where ASP.NET was installed but has been removed.
It looks like the best solution would be to examine the Role Services. However, API information on this is looking pretty rare, hence the cry for help.
The absolute way to know if they checked that or not is to search the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components
In there you should see two values set to 1, ASPNET and NetFxEnvironment and NetFxExtensibility. This registry key is the IIS Setup key that contains all the components that have been enabled in IIS.
Determining if asp.net is even an installed feature (prerequisite for enabling it) can be done through PowerShell, which implies there is .net api out there for it if you dig hard enough. The PowerShell methods:
Import-Module servermanager
Get-WindowsFeature web-asp-net
Which will return an object of type Microsoft.Windows.ServerManager.Commands.Feature. The installed property is boolean and indicates whether or not the feature is installed.
So do you want the easy way? Make a nice pretty .aspx page that displays as HTML with an error block in a div in a placeholder saying "You need to install ASP.NET" and have it change on ASP.NET being installed to instead say "ASP.NET is installed" and then just have the tool launch this webpage in the default browser after copying it to the directory identified in IIS as the *:80 site (or create the directory mapping in IIS programmatically by altering the XML and then removing it later)
May not be the most elegant but it does ensure that testing shows what features are truly installed versus what's in an XML file.
Because that will scream "do it the lazy ignorant way" I'll remind you that the only way for me to know in javascript what features I can use is to test them before I try to use them, or assume they're there and watch it blow up. My point is, it doesn't matter what gets reported in a file, it matters what you can actually use. Just because C:\Windows\Micrsoft.Net\Framework\v3.xxxxxxxx exists and has files doesn't mean the dll's are registered in the GAC, does it?
I'm currently using Microsoft Code Contracts in an ASP.NET MVC application without any issues but I can not seem to get it quite running in a basic ASP.NET Web site. I'm not entirely sure it was made to work with this type of project (although it shouldn't matter) so I wanted to bring it up to everyone.
I can compile the contracts just fine but the code skips over them since I'm assuming it hasn't been enabled through the Properties Page like you would do in other project types (ie ASP.NET MVC). I've gone to the property page of the project (which displays a dialog instead of the typical properties page) in my ASP.NET web site but it does not yield the same menu options and as such, doesn't have a section devoted to Code Contracts.
Also, I have Microsoft Code Contracts properly enabled within a class library project that I use to separate my business logic from the web site. The contracts compile fine but when a contract is violated, it throws a rather uninformative "Exception of type 'System.ExecutionEngineException' was thrown" error with no inner exception. My contract specifies a message to display upon violation but it is nowhere within the exception. It simply halts the execution of the process (which I believe is the default functionality for Microsoft Code Contracts).
I can't find anywhere that explicitly states that a particular project type can or can't (or shouldn't) be used with Contracts so I just wanted to see if anyone has had this issue.
Thanks for any help!
I had the same problem and this is how I solved it:
In the Referenced Class Libraries, right click -> properties -> code contracts.
Make sure "perform contract checking" is checked. I had mine set to "Full"
Contract Reference Assembly: make sure it is set to "Build"
Save your changes.
In the Referenced Class Libraries that have no contracts in their code, set the Contract Reference Assembly to "Do Not Build".
Then in the MVC project, have the Code Contracts "perform contract checking" checked. I had mine set to "Full".
Hope that helps somebody.
This sounds less like a Contracts and more like a build/config issue. Have you tried to deploy a prebuilt website? Are you sure that your website code sees the contracts code? Is the ASP.NET runtime using the CLR 4.0, or does it see the earlier Microsoft.Contracts.dll? Etc.
When an ASP.NET application errors out and generates the yellow-screen display, I'd like to create some kind of link from the error page which would jump directly to the correct line of code in Visual Studio.
I'm not sure how to approach this, or if there are any tools already in existence which accomplish it - but I'd love some feedback on where to start.
In the event that generating a new error page is necessary, is it possible to replace the standard yellow screen across an entire webserver, rather than having to configure the customized error output for each application?
You would probably need to embed an ActiveX control in the page for something like that to be possible.
The yellow screen of death is served by the default ASP.NET HTTPHandler.
In order to intercept it, you would need to add another HTTPHandler in front of it that intercepts all uncaught exceptions.
At that point, you could do whatever you want for your error layout.
Creating a way to directly jump to Visual Studio would be tricky. I could see it done in IE via a COM/ActiveX object.
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
The yellow screen of death is just a 500 error as far as the server is concerned, you can redirect to a custom screen using the error section of the web.config. To make a whole server change in the same manner you could probably override it at the iis level? Or perhaps even set the default behaviour in the machine.config file (not 100% sure about that one though)
If you let it bubble up all the way to IIS you will not have any way to access the Exception information. Its better to catch the Exception before the YSOD and serve your own.
This can be done at the application level.
Don't forget that you need the Program Debug Database (pdb) file to find the source code line number. An application in release mode won't have the same level of information as a debug release.
The easiest, laziest thing I could think of would be to have the process happen thusly:
The yellow screen is modified so the line is source code is clickable. When clicked it delivers a small text file with the source file name and line number.
A small program on the PC is tied to the extension of the small file the yellow screen let you download. The program uses visual studio's extensibility model to open the source file and goto that line. The program may need to know where your source code is.
A simple Google search
gives helpful pointers on how to manipulate VS with an external program such as this post on MSDN.
If you want to go snazzier, then there are certainly other methods, but I'd rather write out a quick and dirty program, and get it out of my way so I can be about my business.
Don't let the tools become projects...
-Adam