I have an api running in IIS written in .net framework 4.7.1 that needs to start a console app, but when I call Process.Start(#"\\boxName\d$\moreFoldersHere\FileName.exe"), it hangs on execution, and the console app does not start. I have verified that the app pool under which the site is running has full perms to both the directory containing the exe and the exe itself, and I have made the service account an administrator on the box with no luck. I have no trouble running the app, but even when I set the app pool to run as myself, the behavior does not change.
Purely for context... the api needs to trigger a process that may take an unreasonable amount of time to complete. Obviously I don't want the api response waiting on it, so I don't want to wait for the result of the process; I just want to fire-and-forget. I also don't want iis cleanup killing it after some period of "no activity", and I need to potentially have multiple instances of this same process executing at the same time on the same box.
I found the answer... In IIS, in the App pool, LoadUserProfile needs to be set to True.
I'm not sure why it defaulted to False, but everything is working fine now.
Since it's a console app, your issue is likely the need to read the output. See this answer.
Related
I have read the MSDN article (link) which says something about the IIS process recycling and it turns out that
The new process is started before the old worker process stops, and requests are then directed to the new process.
But, when I read next part of that article i saw this:
Occurrence of multi-instancing: In multi-instancing, two or more instances of a process run simultaneously. Depending on how the application pool is configured, it is possible for multiple instances of a worker process to run, each possibly loading and running the same application code. The occurrence of an overlapped recycle is an example of multi-instancing, as is a Web garden in which two or more processes serve the application pool regardless of the recycling settings.
If your application cannot run in a multi-instance environment, you must configure only one worker process for an application pool (which is the default value), and disable the overlapped recycling feature if application pool recycling is being used.
So, I am a little confused.
On the one hand, I am okay with the thing when all the web requests immediately and permanently are become directed to the new process instance. On the other hand, this article recommends me not to use recycling at all in case if my application, quoting above "cannot run in a multi-instance environment". Which means, in my opinion, that requests may be processes as one or the other process instance, which is not allowed by my app logic.
All I want to know is, if there is any chance, any opportunity, that IIS can go such bad way and collapse my application, or shouldn't I worry about it?
IIS by default will recycle periodically; this is normal and healthy behavior (frees up system resources). IIS will only run multiple processes for the same app temporarily. On a recycle the new process will start and the original will only run until current activities have completed or the timeout period has expired. If you're concerned about session state, look into State Server (SQL being the preferred method). I've got a couple posts regarding this very issue, but check out this link.
I have created a message Queue here which is basically on a single thread and sending email one after another from the database. First I thought that since it is a continuous process, it has to be on windows service and it sounded like an ideal solution but not that I talked to my manager, he said that it would be better if it is in the same repository as the entire project and if I put in a while(true) statement. that way while deploying to the production, we do not need to worry about installing any windows service or anything. But what I think here is that if we do it that way then there would be a lot of unwanted pressure on the web server.
I am not sure which way to go. Any suggestions?
I would definitely suggest a windows service for processing the email queue in the background. Here are some points you can suggest to your manager:
The service could be kept in the same repository as another project.
Installing and upgrading services is very easy. Use installutil and add a batch file to your project for installing/uninstalling. Upgrading is a matter of stopping the service, updating the service .exe, and starting the service again.
All of this could technically be automated as well as part of your deployment process.
I'd go with a separate Windows service. With this service being party of your application, its life time is dependant on the life time of the application pool process (depending on the version of the IIS you are using, of course), and this way whenever youll choose to change the application pool settings, you will have to remember ur message job is also dependant on it, and if you set up any recycle settings for the app pool, you might have hard time uynderstanding why your job suddenly stop working or anything like that.
You can also go the route of simply writing a command line application and then wrapping it with something like Service+ to make it behave like a service. You also get other features like being able to run it like a command line application if you like (whenever you want to run it) or having it launch/execute from some other application as needed. You can build in a variety of behaviors as well... continuous mode, perhaps process 1 (or 100 or whatever) at a time then exit (and let Service+ restart it), or whatever else you may need.
IIS 7.5 introduces the notion of auto-start providers, that allow you to get WAS to auto-load an application or assemblies when an application pool starts up.
Can a similar thing be achieved with IIS7?
Basically, we have an application that runs under WAS, and has an in-memory cache of data. When an application pool recycle occurs, my WAS deployed app won't actually be activated until the first hit for it is received. This means that the cache is cold when the first hit is received. It would be good to be able to pre-start the application as soon as the app pool is recycled.
Other options we've considered are:
Deploying the application as a Windows service so it doesn't re-cycle (this would work, but the application lifecycle management of IIS/WAS is a useful thing apart from this issue)
Writing a separate service whose job is to ping our application to warm it up.
However, the nicest way would be to get IIS7/WAS to do this for us.
In Windows 2008 you can log events that occur on the application pool, so you can log recycle events.
You can configure the event viewer to start a program when a specified message has been logged. You could call your service or load the assemblies in that program.
Would this be a feasible solution for you?
Regards,
Michel
in the advanced settings of your application pool set your application pool to generate Recycle event log entry every time it is recycled; I think the option is "Specific Time". Then you can use Windows Task Scheduler, create a script or something you want it to run that will hit your site so it can initialize. Set the trigger for the task to an even, set the Event Filter that you want to trigger the task and voila.
I am writing a web monitor app that gives information about all app pools / apps on my IIS server. I am looking for a way in C# to programmatically check if an IIS application is running without causing it to run if it is not.
Here is what I have found...
application is running, there are one or more sessions active.
all sessions dropped off...application still "running", app pool worker process is running.
At some point determined by IIS, the Application_End is finally executed...however, the app pool worker process is still running.
After 20 minutes, the app pool worker process finally shuts down due to inactivity.
It is between #3 and #4 that I am having trouble. The application has ended, but if I try to send an Http Request to the app, it will automatically start up. I am looking for a way to programmatically determine if the application has ended (while the worker process is still active awaiting shutdown) without restarting the Application.
I can try to provide more details if you are unsure what I am talking about.
Regards,
Jeremy
I found this on MSDN
public bool CheckIISRunning()
{
ServiceController controller = new ServiceController("W3SVC");
return controller.Status == ServiceControllerStatus.Running;
}
For this to work you need to have
System.ServiceProcess added as a reference.
Microsoft has created a VBScript file to identify the IIS Application Pools (by Process Id). If you search "iisapp.vbs" on google it should point you in the right direction.
Note: I'm not 100% sure that it will work with Windows Server 2008, but does work with 2003.
In IIS7 you can use appcmd apppool /? to see what possibilities are available.
I have windows task which restarts IIS at midnight 00:00. In my application there is a background thread which runs a global refresh at around 02:00.
My problem is that the application starts only on the first request from a browser. This may not occur for quite some time and the global refresh can be late in starting.
Is there any way to start the application without first browsing to the web application?
Ideally you should keep maintenance tasks such as this separate from your web application (either as a scheduled task or Windows service).
But, if you really need to do it this way could create a batch file that does:
iisreset /restart
"C:\Program Files\GnuWin32\bin\wget.exe" -O nul http://www.myapp.com/default.aspx
Then run this batch file as your scheduled task at 12:00. This will restart IIS and warm up your application.
You can get GNU wget.exe from:
WGET for Windows (SourceForge)
You can have another task that accesses your web site after IIS is restarted.
Still, I can't see why would you have a thread doing maintenance inside your IIS worker process. If the process dies from some reason (for example - because of the recycling configuration in the web site's application pool) the work won't get done. It's better to do this from a separate process, such as windows service or a scheduled windows task.
You shouldn't have any threads scheduled inside an IIS web application - becasue IIS has some logic to recycle the worker process and your application when it is not used. Its better to run it as a separate application (scheduled separately).
You could also use a Powershell script called by task manager. Here is simple six-line script we use to "warm up" SharePoint servers.
You could repurpose or find a similar script for a basic .NET application.