I'm trying to build a basic application which will have 2 separate components which are:
1. Continually poll an external process and store the results within a DB
2. Grab the results from the DB and display it in a webpage
I'm looking to do this in .Net so I would normally say to do the first component in a Windows Service and the second in ASP.net with a relational dbms like sql server.
The problem with this is that i want to use webhosting to deploy this and they don't tend to allow Windows Services (unless you pay a fortune). So is it feasible to do the polling component in a seperate asp.net page, or maybe create a spawning worker thread within a single asp.net page that will do the polling for me?
Any opinions/input appreciated.
Thanks :)
Consider this blogpost dealing with Easy Background Tasks in ASP.NET. Some suggestions, lessons learned, etc in the comments. I think I remember a podcast where the scale of the site has forced a move of this code to a Windows Service. You may/not have the same scaling needs.
You could have a static method set up a polling thread under ASP.NET, so yes.
SO is a treasure trove of information, and the ASP.Net background task comes from a question that was asked during the beta. SO actually uses something similar to this to award badges.
I have personally used this to do exactly what you are saying.
Where/What is the external process?
If you have any control over that, could you not place your service there?
ASP is fundamentally designed for requests, not for long running processes, you may get something working, but it will never be as robust as something designed for the job.
Related
I have done a lot of searching to find a way to start a GUI application from a windows service on Windows 7. Most of what I have found is that with Windows 7 services now run in a separate user session and can not display any graphical interface to the current user. I'm wondering is there is any kind of workaround or different way of accomplishing something like this? Can the service start a process in a different user session?
This change was made for a reason and not simply to annoy developers. The correct approach is to put your UI in a different program and communicate with the session through a pipe, or some other IPC mechanism. The recommendation that services do not present UI is more than 10 years old now.
You should really try to follow these rules, even though it may seem inconvenient to begin with. On the plus side you will enjoy the benefit of keeping your service logic and UI logic separate
If your services runs under the LOCALSYSTEM account then you can check "Allow service to interact with desktop", for the benefit of legacy services that would fail if they could not show UI. But it won't help you anyway because the UI will show in session 0 where it is never seen!
I recommend you take a read of the official Microsoft document describing session 0 isolation.
There is a way to do this.
If you need to show a simple message box you can use the WTSSendMessage Routine.
If you need a complex UI elements you can put it in a separate program and you need to use CreateProcessAsUser Routine.
In this sample provided by microsoft you can see the process.
http://blogs.msdn.com/b/codefx/archive/2010/11/26/all-in-one-windows-service-code-samples.aspx
Windows 7 introduced what is called "Session 0 isolation" that in practice means that every service (except system services) run in a separate non-interactive session. For this reason you cannot directly create a GUI from within the service, except if you run in legacy mode by flagging the Interact With Destop option, which is not good if you plan to run your service for some years in the future.
As David Heffernan said, the best is to use a client-server architecture. WCF makes it easy to communicate with named pipes.
This page is a good starting point to read about Session 0 Isolation and this white paper is also very good.
I've read a good bit about threading with C#, but to be upfront I haven't done anything in production using it.
I have an application that has to process a bunch of documents and then send the documents via email. This may take 60 seconds to accomplish. I don't want the user of my web application to have to wait for these things to process to move on to other parts of the site.
On a button click the SendEmail function is called. What can I do to this code to make it so that my users can continue browsing the site without discontinuing the processing I need to do within the EmailPDFs function?
[Authorize]
public ActionResult SendEmail(decimal? id, decimal? id2)
{
EmailPDFs(..., ..., ...);
}
Thanks so much!
This is really the kind of thing that message queues are designed to handle. Fire off a message, and a process on a potentially separate server picks it up and processes it. When it's done, it sends a message back to a queue on your server, where a process on your server picks it up and notifies you that it's complete. You then notify your user that the work is finished.
Modern message queue systems can be backed by databases (such as Mongo, MySql, or SQL Server), and are extremely robust. The great thing about them is that they allow you to move long-running or CPU-intensive processes off onto other servers so that your web site remains nice and snappy.
You could try to add multi-threading and parallelism to your web application, by using TaskFactory and all that other stuff (for many folks, this is the route they take), but it doesn't make it very easy to separate your application if you need to, and break those big, resource-hogging pieces off if it becomes necessary.
I urge you to consider a queue-based solution.
Update:
For samples and information on how to implement this type of solution, see the following:
Reliable Messaging with MSMQ and .NET on MSDN
C#: A Message Queuing Service Application on MSDN
Also, consider glancing at this StackOverflow question for a quick crash course on the bare minimimum amount of code required.
A final note: MSMQ is built into certain flavors of Windows, and can be added to it through the Add/Remove Programs feature of the Control Panel. However, how you install it will depend on your specific flavor and version of Windows. A simple Google search will help you to find the appropriate instructions.
Good luck!
I have SQL Server database with information for files - I'm talking about custom properties. These are categories and description for each file.
The Windows Forms application is for the user. But I will also make a Windows Service that will track any changes with the files. If a change happens(renamed,moved,deleted) the service has to update that same database accordingly. And I think it should do it right away, without any delay.
Now this is going to be my first time making WS plus the first time I will have to handle concurrency (theoretically I know about threads and so on).
So:
First of all, is it OK if one process is updating a database another process may be using at the same time? Do you need to handle that situation on the first place? (Probably, fx in our daily "user lives" we can't modify a file when it's being used by another process)
Is the idea these two to share one data source good ?
If it is, then how to handle the concurrency ? I can use WCF for the messages between the two, but then does the solution have something to do with WCF ? Because I'm going to use this for the first time as well :D.
Any help is appreciated. Thanks in advance for the time !
Since MS SQL is transactional there will be no big deal. You just have to watch out for data wich might be read and updated by one process - there it can be neccessary to use a Transaction scope (that's a .NET Class ;)).
From the Software architectural Point of view you should conside using a three-tier and not a two-tier application:
Two Tier:
Essentially your System with the persistance-layer (DB) communicating with the Clients directly
Three Tier:
Persistance-Layer <--> Logic-Layer (e.g. a WCF-Service handling the app logic) <--> Clients (Service and Forms - triggering app logic and showing results)
When it comes to concurrency it's going to be really straight forward. The MSSQL database engine handles just about all of it (e.g. locking and sharing). Further, if you leverage the SqlCommandBuilder to build your statements, the statements will automatically use optimistic concurrency.
As for the Windows service and how it gets notified, use a FileSystemWatcher, it going to be more efficient and you won't be published some service port on the local box.
I'd normally give you some good code examples but I'm answering this from my phone.
I have a web app that I'm writing right now that is supposed to have "periodical events". For instance, at midnight, the web app should calculate "scores" for all users. I want this done only once during the day.
Is there a way that I can automate this, so it runs automatically at midnight (or whatever hour I choose)?
I don't like the idea of creating a separate script (VBS) to do this, as the calculation would depend on a lot of business logic of the app. I was thinking to put it into a separate Class Library, so it can use the web app logic (which is also in a class library), but is this the best way to go about it?
I also don't like the idea of using the Session_Start() event in the Global.asax to trigger the event by checking the hour manually. There must be some easier way - especially because down the road I expect there will be a lot more of periodical events - some may have to be triggered every fifteen minutes, for example ...
Thanks a lot for any help you can give me.
You should not do this in the web app itself. You are correct to put the business logic in a separate library. Once you have done this, you can use the business logic from anywhere, and therefore, a good solution would be to create a console application that does the nightly jobs, and invoke the console application from Windows Task Scheduler. IIS is not suitable as a host for periodical events.
I guess you are missing the point of separation of concern. Whatever you are asking is a job of a service. You need to develop a separate application as Windows Service that will do all your calculation and to be triggered by any scheduler even Windows Task Scheduler would do. This is what basically done on large scale applications.
Yeah... again awesome "change your architecture and hosting environment so that my answer can be relevant" responses.
Doing what you ask is actually quite easy, take a look at this article: http://www.codeproject.com/Articles/12117/Simulate-a-Windows-Service-using-ASP-NET-to-run-sc
This is a job for a windows service or scheduled task. A web application responds to HTTP requests. Essentially the service's job would be to wake up, run the appropriate calculations and write back to the database. Once in the database, your web application can use the newly calculated values.
Here is some information on windows services: http://msdn.microsoft.com/en-us/library/d56de412.aspx
I'm making a small application that is supposed to download info from the web every day at 2am. It will download the information and write the strings to an XML file of my choosing.
Using .NET and C#.
My initial approach was to install a service on the users computer and have that run, but I'm not so sure. I've not even used it so much in the past, only once.
Which is the best (read: time tested :P ) approach to this very common problem.
You can either build your application as a Windows Service, as you mentioned.
Or else it would probably be a better idea to create a normal console application, and launch it automatically at 2.00am with the Windows Task Scheduler.
You can consider both methods as popular and "time-tested".
I would suggest having a console app, which calls data fetching algo in a separate public class (not the main method).
Like Daniel mentioned, run it via Windows Task Scheduler which itself will take care of most scheduling requirements.
This allows the solution to be scaled in the future if need be. E.g. convert into Windows Service, full GUI Winform or even SQL server scheduled tasks etc.