Is there a way to test if the current request (HttpContext.Current.Request) is available in the Application_Error event of the Global.asax when using Integrated Pipeline with IIS7 in ASP.NET? Currently I am using a try-catch, but it seems like there should be a way to verify rather than catching an exception.
Unfortunately, I believe the answer to your question is no. This question seems to cover what you're asking. You can use reflection, but it doesn't seem very reliable. Articles like this blog post recommend not doing this, and even say:
"Because this event is intended for global initialization activities, any logic that references a specific request is typically a design oversight."
But what does he know about the design of your site, amirite? Your only choice if you really want this is to go back down to Classic.
Related
I am making a site where users can reply to topics, open topics, etc. and when the user sends a message, I don't want to postback; it's ugly.
I'm using generic handlers right now but I am having some problems with it. Like updating GridView using UpdatePanel when XMLHttpRequest's onreadystate is changing.
I decided to use PageMethods but I also wanted to ask you.
Which is better, faster and more useful: PageMethods or Generic Handlers?
I don't think there would be much difference between the speed of Page methods and HTTP Handlers. However if you're worried about your application's performance, you should benchmark each option and choose what's best for you.
To answer the question, which is better or more useful, basically within the ASP.NET context you have three options, each with their pros and cons:
Page methods - all your code is contained in single Page, which is fine if the code is only used by that page. You should probably implement methods that return page-specific HTML snippets as Page methods. However if we are talking about reusable code, such as "Save Topic" or "Get Topics", you might want to consider externalizing this code elsewhere. I guarantee that as your application grows, you'll need those methods elsewhere in your application end as well.
Generic HTTP handlers - are lightweight, and great for code you need to call often throughout your application. Most often generic handlers are implemented to serve content, and I don't know what the best practice around this topic is, but to me POST ing to a generic handler to save data has a distinct smell. You'll also find that for related functionality (Save, Get single, Get many, etc.) you'll end up with a swarm of handlers, or a handler with a giant switch statement and a fuzzy contract based on query string and POST parameters. I wouldn't recommend this option to implement extensive AJAX application. For small bits and pieces it might suit your needs.
ASP.NET web services (or WCF) - The third option you did not mention in your questions are ASP.NET web services (.asmx). You can easily include them in your existing ASP.NET application without any additional framework dependencies. They offer a good balance between the options 1 and 2. On one hand you get reusability throughout your application, and even outside your application if you so choose, which Page methods cannot provide. On the other hand you can neatly bind together related functionality in meaningful ways, which tends to get messy with generic handlers. You can also interact with the services using SOAP XML, JSON or HTTP POST / Plaintext as needed.
And the wildcard option here is: Use ASP.NET MVC and jQuery. If you're looking to build a lean and mean web application and you generally find postbacks ugly, and you find stuff such as what exactly happens when the xmlhttprequest changes readystate interesting, it might provide you with a better experience overall. Maybe not for this project, but for the next one.
If you mean with generic handlers web service endpoints then you can make the following distinction:
You can use PageMethods if the functionality only needs to be available on that page only
You can use web service endpoints if you want to reuse the functionality.
Personally I practically always use web service endpoints (in my case ajax enabled WCF).
I cannot see why you shouldn't use generic handlers. I think they are best - simple and flexible.
I've been reading up on MVC2 which came in VS2010 and it sounds pretty interesting. I'm actually in the middle of a large multi-tenant application project, and have just started coding the UI. I'm considering changing to MVC as I'm not that far along at this point. I have some questions about the Routing capabilities, namely are they required to use MVC or can I more or less ignore Routing? Or do I have to setup a default routing record that will make things work like standard ASPX (as far as routing alone is concerned)?
The reason why I don't want to use Routing is because I've already defined a custom URL 'rewrite' mechanism of my own (which fires on session_start). In addition, I'm using jquery and opens-standards for the entire UI, and MVC's aspx overhead-free approach seems like a better fit based on how I've already started to build the application (I am not using viewstate at all, for example).
I guess my big concern is whether the routing can be ignored, of if I will have to re-implement my custom URL rewriting to work with MVC, and if that's the case, how would I do that? As a new Routing routine, or stick with the session_start (if that's even possible?).
Lastly, I don't want to use anything even remotely 'intelligent/readable' for the url - for a site like StackOverflow, the readability of the URL is a positive, but the opposite is true if it's not a public website like this one. In fact, it would seem to me that the more friendly MVC routing URL (which indirectly show method names) could pose a security risk on a private, non-public website app like I'm developing.
For all these reasons I would love to use the lightweight aspects of MVC but skip the Routing entirely - is this possible?
You could make it work without routing, but you would have to rebuild a lot of the framework and pretty much build your own routing engine. That wouldn't really make any sense as Microsoft already provide you with a great routing framework. All your url rewriting rules could easily be implemented using the routing framework anyway. You don't have to have the action name of the controller name in the url if you use the routing framework. As long as you can tell what action should be executed from the raw url it could be implemented.
My advice would be to read up on the routing framework and learn how it works. I'm pretty sure you will not regret it.
Don't bypass routing
Routing is imperative part of Asp.net MVC and ignoring it will cause more or less trouble. You could get by by using ISS7 URL Rewriting module, but it will only work if your requests have a certain format, otherwise you will end up writing rewrites for every single request that is used in your app.
The good thing is that routing is nothing you should be afraid and is quite simple to understand as long as you don't start havind some complex routing rules. Then you will delve even deeper into it and probably love it even more.
I would like to implement exception handling on a ASP.NET application. How do you suggest I implement it? Some requirements are:
User should see a friendly page when an exception occurs
Admin should get an email with exception details
I understand there are several ways of implementing exceptions (ex: Log messages in the event viewer)
What's the recommended approach?
The recommended approach really depends on what you need to do with the error information.
For simple apps, just setting up the web.config file to redirect to a friendly error page might be enough.
It's usually a good idea to record unhandled error information to a database, file, windows application log or web service by handling them with the Global.asax Application_Error event. You can also use the web.config to get your friendly page with that. Generally I wouldn't recommend using the windows error logs as they tend to be a bit obtuse, but there's nothing wrong with it.
For very detailed operational information, including warnings and info messages, tools like log4net are widely used. Usually you would go this route for products or enterprise level applications where your support teams need as much information as possible to diagnose the errors.
MSDN has a walkthrough of some of the basic error handling setups and what you can do with them.
I wrote an article on this that I think you'd really like
http://dotnetblogger.com/post/2008/12/03/ASPNET-Health-Monitor.aspx
As for the friendly page bit, I just use the built in exception handling in the web.config... since you are implementing the unknown exception stuff in the global.asax
You can also handle exceptions in try/catch blocks and add a note to it if you want. Then just bind the database to a nice gridview for admins to easily see the errors.
I have a nice reusable HttpModule that you can look at here. It can be used to easily deal with Exceptions that occur during normal user requests, and those that occur in background threads.
We need the ability to send out automatic emails when certain dates occur or when some business conditions are met. We are setting up this system to work with an existing ASP.NET website. I've had a chat with one of the other devs here and had a discussion of some of the issues.
Things to note:
All the information we need is already modelled in the ASP.NET website
There is some business-logic that is required for the email generation which is also in the website already
We decided that the ideal solution was to have a separate executable that is scheduled to run overnight and do the processing and emailing. This solution has 2 main problems:
If the website was updated (business logic or model) but the executable was accidentally missed then the executable could stop sending emails, or worse, be sending them based on outdated logic.
We are hoping to use something like this to use UserControls to template the emails, which I don't believe is possible outside of an ASP.NET website
The first problem could have been avoided with build and deployment scripts (which we're looking into at the moment anyway), but I don't think we can get around the second problem.
So the solution we decided on is to have an ASP.NET page that is called regularly by SSIS and to have that do a set amount of processing (say 30 seconds) and then return. I know an ASP.NET page is not the ideal place to be doing this kind of processing but this seems to best meet our requirements. We considered spawning a new thread (not from the worker pool) to do the processing but decided that if we did that we couldn't use the page returned to signify a success or failure. By processing within the page's life-cycle we can use the page content to give an indication of how the processing went.
So the question is:
Are there any technical problems we might have with this set-up?
Obviously if you have tried something like this any reports of success/failure will be appreciated. As will suggestions of alternative set-ups.
Cheers,
Don't use the asp.net thread to do this. If the site is generating some information that you need in order to create or trigger the email-send then have the site write some information to a file or database.
Create a Windows service or scheduled process that collects the information it needs from that file or db and run the email sending process on a completely seperate process/thread.
What you want to avoid is crashing your site or crashing your emailer due to limitations within the process handler. Based on your use of the word "bulk" in the question title, the two need to be independent of each other.
I think you should be fine. We use the similar approach in our company for several years and don’t get a lot of problems. Sometimes it takes over an hour to finish the process. Recently we moved the second thread (as you said) to a separate server.
Having the emailer and the website coupled together can work, but it isn't really a good design and will be more maintenance for you in the long run. You can get around the problems you state by doing a few things.
Move the common business logic to a web service or common library. Both your website and your executable/WCF service can consume it, and it centralizes the logic. If you're copying and pasting code, you know there's something wrong ;)
If you need a template mailer, it is possible to invoke ASP.Net classes to create pages for you dynamically (see the BuildManager class, and blog posts like this one. If the mailer doesn't rely on Page events (which it doesn't seem to), there shouldn't be any problem for your executable to load a Page class from your website assembly, build it dynamically, and fill in the content.
This obviously represents a significant amount of work, but would lead to a more scalable solution for you.
Sounds like you should be creating a worker thread to do that job.
Maybe you should look at something like https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
You can and should build your message body (templated message body) within domain logic (it means your asp.net application) when some business conditions are met and send it to external service which should only send your messages. All messages will have proper informations.
For "when certain dates occur" scenario you can use simple solution for background tasks (look at Craig answer) and do the same as above: parse template, build message and fast send to specified service.
Of course you should do this safe then app pool restarts does not breaks your tasks.
What's the best way to log in ASP.net MVC? I mean any event, I'm currently using NLog but I know there are a lot of possible ways to do it.
I use log4net, its quite good. There are some issues to be aware of, you can learn more about them here. I also recommend Elmah, for me I use it on every project I do, its a prerequisite.
I don't think there is a best framework/tool or standard way in ASP.net MVC. Just do it the way you would in any other framework. When I set up logging, I usually think of it as a resource available to the rest of the application, rather than being tied to a particular tier. This is common, and in fact logging is the standard example given when introducing Aspect Oriented Programming. See:
Logging mentioned in the wikipedia entry on AOP
Another AOP into that uses logging as the example
Depending on what exactly you're trying to log, consider using action filters; a great way to log what page requests are made and for error handling coverage. Non-MVC asp.net apps usually do something in the global.asax, as mentioned here. In fact, even if you use the action filters, which I would suggest, also include some basic error handling in the global.asax 's application_error event; it will fire a little more dependably than the action filters if something really crazy happens.
Other than that, call your logging resource at the point where the stuff happens that's interesting to you. DB or File? Either works, and as long as it's encapsulated in a good method or two, you can always switch that later.