I understand that I can redirect a user on an exception by setting the customErrors element in the Web.config
<customErrors mode="On" defaultRedirect="/WebTest/ErrorPages/AppError.html">
</customErrors>
I could also do a Response.Redirect in the Application_Error event in the Global.asax file.
What are the differences between these 2 approaches and which one is preferred?
If you don't want to do anything with the error (such as logging), you'd better simply use the configuration file. It's simpler and easier to reconfigure. Moreover, using the configuration file has the advantage of supporting RemoteOnly type, where you can easily see the exception on the server for diagnostics purposes but others won't be able to see it.
In general, there's no point in writing code for something that's perfectly configurable and is built in the system. Code is more prone to errors than configuration options.
I am not sure of anything official, but I find using the config file easier for local testing versus production behaviour.
Related
I have run into an issue that when my web application's web.config compilation debug is set to true I am getting a vulnerability error on a security scan.
What I want to determine is if there is a way to have some type of web.config conditional block change the debug setting to use the correct value on debug builds and release builds. I have read that setting the property in each web page itself will do this and don't know if this is in fact true and are there any problems with this?
I would suggest <deployment retail=”true”/>.
You put this element into your machine.config on the production server and it overrides debug=”true” in your web.config and pages. In other words, you can happily use the debug and trace functionality on your developer machines but can be sure it is turned off on the production server. Scott Guthrie recommends this as best practice.
Is anyone aware of any situations in which an ASP.NET 2.0 webservice might be unable to read the appSettings values from the web.config? I seem to have exactly that problem - the code thinks the appSettings is empty when it isn't.
In more detail: This code:
Dim settings = ConfigurationManager.AppSettings
Dim count = settings.Count ' always gives zero
Incorrectly shows that there is no data in the app settings.
My web config looks like this
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<!-- lots of other stuff -->
<appSettings>
<add key="SomeKey" value="Some Data" />
<!-- other keys -->
</appSettings>
</configuration>
I've verified that the code can see the web.config file (by the simple device of commenting out everything in the file, and seeing that when I try to run the service, it complains that the web.config is invalid).
The code is production code which does in principle work, just not apparently on my machine - so I'm guessing the problem has something to do with my environment, it's almost certainly not a problem with the code.
Ah, it seems the reason was absurdly simple. I just needed to recompile the VB code! What happened was that, because I was (correctly, as it happens) convinced there was nothing wrong with the VB code, I focused all my efforts on fiddling with the web.config and with the IIS settings (because those were the things that might conceivably be different between my machine and the known working live program). Eventually I gave up on that, and decided to temporarily work around by changing the VB code to use hardcoded values instead. As soon as I did that and rebuilt, I found that the program now picked up the appSettings correctly (and my hack became unnecessary).
So, my guess is that somehow the VB code became detached from the web.config, and needed recompiling to re-attach it. I'm somewhat puzzled because I thought that ASP.NET would automatically detect changes to the web.config and so recompile anyway, but evidently not.
If anyone can satisfy my curiosity by explaining what might have been going on in ASP.NET that could result in an explicit code-recompile being necessary to read the web.config correctly, then I'll mark that as the answer to my original question. (If noone does after a day or so, I'll mark this post as the answer).
I've got this in my web.config and it's being hosted by the DiscountASP.net ISP
<customErrors mode="On" defaultRedirect="">
<error statusCode="404" redirect="404.aspx"/>
<error statusCode="500" redirect="404.aspx"/>
</customErrors>
I am hosting the site on DiscountASP.net and they also tell you to config it this way. I'm using Enterprise Library but I don't think that should make a difference. I don't believe I need to config anythign for a 404 in EL.
When my page loads with an error, my 404.aspx doesn't show and I get the default custom errors off message. I do not know why I don't get my 404.aspx page showing and get this instead:
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
Have you tried using a relative path to see if that makes a difference?
<error statusCode="404" redirect="~/404.aspx"/>
Alternately, try an absolute path:
<error statusCode="404" redirect="http://www.domain.com/errors/404.aspx"/>
EDIT: As others have pointed out, and based on your comment to another answer, the 404 error page should be displayed when someone navigates to a page that doesn't exist, whereas general errors on a page could be captured by the defaultRedirect. So if you're testing the 404 then make sure you're testing with a nonexistent page. To test the defaultRedirect then have one of your pages throw an exception etc.
Is it possible that you are overriding this in another web.config, say in a sub folder? Or we can go the other way. Are you sure this is in the application root?
Is there any reason why you don't want to use the defaultRedirect for 500 errors?
You are FTP-ing the files correct? Try uploading the file as a binary file instead of text. You might be suffering from an encoding problem. I'm willing to bet right now that nothing you are doing in your web.config is working.
I found a solution here.
The real catch was using this:
Response.TrySkipIisCustomErrors = true;
I toggled customErrors=On in web.config, set the defaultRedirect for my custom Error.aspx page. However, this is only to prevent application errors from spitting out code - I'd still like IIS to handle 404s etc. with its default handlers, since they work fine.
Any way to specify in my ASP.NET app or IIS for IIS to take priority?
I know I could add the formatting in my Error page...but I'd just be replicating what exists in IIS.
It didn't tried it (I don't have visual studio on that box) but maybe if you set your customErrors to handle only error 500 (server error), that'll work. Just a guess.
Let me know if it works
You can do it in the web.config file
<customErrors = "On">
<error statusCode = "404" redirect = "route_name"/>
</customErrors>
Don't forget to register the route in the Global.asax.cs
What is the fastest way to execute a method on an ASP.NET website?
The scenario is pretty simple: I have a method which should be executed when a web page is hit. Nothing else is happening on the page, the only rendered output is a "done" message. I want the processing to be as fast as possible.
Every single hit is unique, so caching is not an option.
My plan is to use an HttpHandler and configure it in web.config (mypage.ashx) rather than a regular .aspx page. This should reduce the overhead significantly.
So my question is really: Is there a faster way to accomplish this than using HttpHandlers?
Depending on what you're doing, I wouldn't expect to see a lot of improvement over just using an HttpHandler. I'd start by just writing the HttpHandler and seeing how it performs. If you need it to be faster, try looking more closely at the things you're actually doing while processing the request and seeing what can be optimized. For example, if you're doing any logging to a database, try writing to a local database instead of across a network. If it's still not fast enough, then maybe look into writing something lower level. Until that point though, I'd stick with whatever's easiest for you to write.
For reference, I've written an ad server in ASP.NET (using HttpHandlers) that can serve an ad (including targeting and logging the impression to a local database) in 0-15ms under load. I thought I was doing quite a bit of processing - but that's a pretty good response time IMHO.
Update after several months:
If you clear all the HttpModules that are included by default, this will remove a fair amount of overhead. By default, the following HttpModules are included in every site via the machine-level web.config file:
OutputCache
Session (for session state)
WindowsAuthentication
FormsAuthentication
PassportAuthentication
RoleManager
UrlAuthorization
FileAuthorization
AnonymousIdentification
Profile
ErrorHandler
ServiceModel
Like I said above, my ad server doesn't use any of these, so I've just done this in that app's web.config:
<httpModules>
<clear />
</httpModules>
If you need some of those, but not all, you can remove the ones you don't need:
<httpModules>
<remove name="PassportAuthentication" />
<remove name="Session" />
</httpModules>
ASP.NET MVC Note: ASP.NET MVC requires the session state module unless you do something specific to workaround it. See this question for more information: How can I disable session state in ASP.NET MVC?
Update for IIS7: Unfortunately, things aren't quite as simple in IIS7. Here is how to clear HTTP Modules in IIS7
I'm not sure what your exact scenario is, but if all your page is doing is processing some data, you don't really need an aspx page or an http handler at all. You could write an ASMX web service or WCF service to do what you need and this would most likely be less overhead. The WCF service doesn't even have to be hosted in ASP.NET. You can host it from a Windows service or console app, and call it in-proc using named pipes. This would probably reduce the overhead for calling the data processing code significantly.
If you really have to use asp.net, you can also just hook into AuthorizeRequest step and intercept the request from there, do your processing and write your Done response directly.