I have a long running task (many hours) that is started via a web page on an intranet interface. This is an ASP.Net 3.5 project. Of course, I could extend the script timeout and let the page run for several hours, but I don't think this is a clean solution. I read somewhere that long running tasks should not be children of a Web Application Pool, since it could be reset by IIS at any time. Searching for a solution, I read a bit about Quartz.Net, but most examples are talking about recurring jobs. I was wondering if it were also appropriate for tasks that should run only once when a user asks for it. Or is there another better solution?
Also, if Quartz.Net is a good way to go, should it run as a Windows Service, or should it be spawned by the ASP.Net web site using Global.asax?
Quartz.net works just fine for this scenario. You schedule a one time job on Quartz.net and let it run for as long as it needs to. At work this is exactly how we run many of our jobs.
You should set up Quartz.Net as a windows service though. IIS recycles web apps and if you run Quartz.net within your web app it will get recycled along with you web app by IIS.
Related
We have a c#, .NET 4.0, windows application which we deploy to a terminal server. (Developed using VS 2010). This application makes use of several WCF services sitting on another server.
Our users access the front-end via remote desktop session. (They all have a .RDP file on their desktops.)
My question is regarding the deployment of this front-end. Currently, if we need to do an emergency deployment during business hours, we need to kick all the users off that are hooked into the app (as they are using the dll's that we need to replace). This is not ideal, obviously. We work in quite a business-critical environment, so these deployments are unavoidable. I've investigated ClickOnce, but have read that you cannot use this with terminal services application here. (Which kind of makes sense since it's essentially one app being "accessed" by several clients...)
I would like to be able to do a "silent" deployment whereby the user knows nothing about the fix until they restart their instance of the application. I'm not sure this is even possible?
I would appreciate any guidance or suggestions on this!
Yep, I do this all the time with a RD app -- you just need to move or rename the DLLs instead of deleting them. Windows allows moves and renames when DLLs are in use, but prevents you from deleting them. If you use Windows Installer to deploy your app, it will do the moves automatically (and delete the old versions when the system is next rebooted).
Once you replace the DLLs this way, existing sessions will continue to use the old, renamed versions, and new sessions will use the new versions. Of course, depending on how many DLLs you have, how long it takes your app to load them into memory, and how much activity you have on your server, you could run into a scenario where the app loads some of the old DLLs and some of the new ones when you're in the middle of updating them, but that would likely be rare.
Can we have any alternative way to make run-able the custom Workflow activity in Workflow steps.
All the time what I do is register the dll using Plugin registration tool and then restart the server. Then only we can use the custom workflow activity on Workflow.
I have tried after restarting the IIS and hoping so it'll be done but no luck.
All the time restarting server should not be any solution. Is there any alternative way for it please suggest. All you are suggestion would be greatly appreciated.
1) You do not need to restart IIS; restart the application pool (its far faster and doesn't disrupt other applications that might be running on the server; by default its the 'CrmAppPool') using the command:
%systemroot%\system32\inetsrv\appcmd recycle apppool CrmAppPool
2) Similarly, you can recycle the async process by running (powershell):
Restart-Service -displayname "Microsoft Dynamics CRM Asynchronous Processing Service"
3) Both of these commands can be run remotely using the powershell command:
powershell Invoke-Command [CrmServerName] -ScriptBlock { ["Restart-Service...."] }
4) You do not need to deploy to the server to debug plugins. Its far easier/faster to create a test harness. The link below outlines how to setup a dev environment for unit testing.
How I develop and unit test CRM 2011 plugins
CRM caches the dlls, restarting the services causes it to refresh those caches.
If you register a synchronous plugin then you need to reset IIS.
If you register an asynchronous plugin or custom workflow activity you need to reset the asynchronous service.
We don't need to restart the server to make it run the plug-in code, the only thing is you need to restart IIS after that.
Try restart IIS and then restart the asynchronous service, this must be the only thing necessary.
The point here is very specific -
It's not only true for the CRM, but is also true for any web application hosted on IIS. Web App (CRM for you case) caches dlls for the very first time when the message is executed (plugin message/event - Although this is done by .net platform internally, so to address the other similar calls more efficiently.). So, in that case you need to flush off the synced thing from your web app. And that is why you need to recycle app pool (SMART WAY -> for single application flush, and without impacting other applications on the server, you should always go for APPPOOL Recycle instead to IIS restart.)
For this, what I would suggest you is to write a powershell script to recycle AppPool for your application and trigger it on Post build event of your project (plugin project) in VS. So, that will make your process automated and will reduce your efforts to much lesser.
Regarding custom WF assembly, Since it executes under Async. Service, so you need to discard off the cached content from here as well.
Hope this helps!
You shouldn't need to restart anything.
What you need to do is increment the build number of the assembly you are updating each time you deploy it.
This makes sure that CRM knows not to use it's cached version but to load the updated one the database
If you want to see the CWAs without any need of restarts just select the activity in the plugin registration tool and press the "save" button below the properties
I'm looking for best practice in continuous delivery of windows services.
Currently we hava a set of powershell scripts that unintall, reboot, install updates but error handling is tricky. We are reviewing System center but are there any other options available for deploying a windows service?
We've been using Presto since Dec 2011, and have done over 1,000 deployments. Most of what we deploy are Windows services.
What's nice is that we set up our apps and servers in Presto, then we can repeatedly deploy, to any server (or multiple servers at once), by just hitting a button. Presto will copy our official release binaries, update all of the items in our app config files, create and start the service, etc...
So, if you have an application that has 30 manual steps to deploying it, you can enter these steps in Presto, then it's done automatically for you after that.
It's worth a look: http://presto.codeplex.com/
Your most basic and generally accepted best option comes from this thread, which basically links to a Microsoft support article on creating an installer for the windows service.
Where I work, we release bug fixes in to the system every night when we know our clients are not using the system.
Trying to take a step towards better service I'd like to deploy to IIS while the application is running.
A solution that comes to mind is to setup two different IIS applications and switch them over after deploy using a script. But I'm not going to try this out as I don't want any complications during our busy hours.
Does anyone have experience in this area of deployment?
Thanks
Regardless of whether you're using PHP, ASP, ASP.NET etc there is no native support for transactional deployment on IIS.
The simplest approach would be to have two physical folders and (optionally two web sites - one production, one test) on your web server, for example:
c:\websites\myapp\dep1
c:\websites\myapp\dep2
Initially your site would have its physical path pointing to c:\websites\myapp\dep1.
When you deploy your latest build you'd deploy into c:\websites\myapp\dep2. Once you're done just switch the physical path of the production site over to this folder. This means you still have the original site and can fall back to it if the new code fails for whatever reason.
The next time you do a deployment you'd deploy into c:\websites\myapp\dep1 and once you're done switch the production site to that folder.
You could optionally have a test site that points to the folder you're deploying to so you can make sure the site works before switching your production site over.
This could all be scripted.
Here's some related reading that may be of interest:
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Rob Conery also had an excellent blog post about the lack of a decent deployment story for ASP.NET application. You should take a trawl through the comments some of which are quite insightful:
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Currently we run our web applications on a thin client browser IE 6 and it is slow.
We are a non-profit organization. All our offices are linked via VPN.
Opera 10 browser allows one to convert one's PC into a server.
I am thinking of deploying our application and Opera 10 on every client, meaning that the every client would run a server which in turn would run our application.
Therefore, the clients would connect only to our database. This would speed things up.
However, I would need to deploy updates to our application from time to time.
How can I deploy a web application to the clients PC's remotely?
Our app is .Net.
You might want to take a look at click-once deployment which can handle auto-updating applications (I believe however, they should be .Net based)