I have Quartz.Net integrated for Scheduler job in my ASP.Net application.
But it is not working automatically and seems that it got stopped when IIS is recycling Application Pool. But fires when we send a request to server.
After reading IIS app pool recycle + quartz scheduling I am trying to configure the same in IIS 7.5 server for resolving the same.
<serviceAutoStartProviders>
<add name="PreWarmMyCache" type="PreWarmCache, MyAssembly" />
</serviceAutoStartProviders>
However PreWarmCache class has been defined in my website and kept all logic, since it uses template from website pages.
How can I define this class from website in type? What would be the value for MyAssembly ?
I can use assembly name if my project is web application.
I created as website. So what could be the value or how should I configure that section?
Note: PreWarmCache is placed under App_Code directory
This has nothing to do with Quartz.Net, but is to do with the IIS server recycling the application pool after a period of inactivity.
I have the same problem, but all I am trying to do is cache data.
So I need to do the following in my applicationHost.config file:
<serviceAutoStartProviders>
<add name="PreWarmMyCache" type="PreWarmCache, MyAssembly" />
</serviceAutoStartProviders>
This then call a function that populates an XML document and stores it as a lookup table in the cache to be used as and when needed.
And the problem is that if I use the AssemblyQualifiedName attribute it returns the following for my class:
MyApp.PreWarmCache, App_Code.<#########>, Version=0.0.0.0, Culture=neutral, PublickKeyToken=null
Where the ######### are, is changed each time the code is compiled.
I do not want to separate this into a DLL, as that would incur having to replicate the code.
So the question is still the same.
Can I/we provide an explicit assembly name for a dynamically compiled ASP.NET website's App_Code classes?
Fixed it now, taken code out into a separate assembly, compiled added reference, now all complete.
It is highly recommended that you do not use Quartz.NET in a web application. The application pools can, and do, reset. While they can be scheduled to recycle at certain times it's still possible for them to recycle at any time. This creates unpredictable behaviour and will be difficult to track down.
I highly recommend creating a Windows Service to handle your Quartz.NET tasks. It will be more predictable, easier to debug, and decoupled from your web application. This will remove the complexity of trying to keep the application pool on all the time to run a service.
If you still want to use Quartz.NET in your web application then this SO question may help.
Related
I get an asp.net project (sitecore) where my client does not have a license to run the project on localhost. So I have to do development directly on the server / portal azure by app service editor
My client wants to add 2 new pages. so I do it like this
On the root of project, I make new folder. The name is static folder. Then I make the html file. The name is test.html
Then on the Web.config, I add like this :
<system.webServer>
...
<httpRedirect enabled="true" exactDestination="true" httpResponseStatus="Found">
<add wildcard="*/Investor" destination="/static/test.html" />
</httpRedirect>
</system.webServer>
I try like that and it works
Is this way good and safe? or is there a better way? I have no other options
The good and safe ways to do it are either (a) deploy to development environment, test, and promote upward to staging and then production, or (b) blue/green deployment. Editing directly on the production server is never a good idea.
Editing web.config, adding a folder to root, and making other changes to the site may seem seamless to you, but under the covers you may be triggering the application to recycle on the fly or recompile. If your application is stateful, this could cause users to be spontaneously logged out (best case) or experience strange and intermittent behavior (worst case).
I understand your client is playing it cheap here, so they need to understand that the practice they are forcing you to follow is neither good nor safe.
I've got an interesting situation where I want to make sure I'm not running in the default AppDomain on an ASP.Net Web Api service (apparently RazorEngine has issues locking temporary files if running in the default AppDomain). From what I can see, by the time Application_Start runs, it's already not in the default AppDomain.
Checked using: AppDomain.CurrentDomain.IsDefaultAppDomain() returns false
Are there any situations where ASP.Net will run in the default AppDomain?
Hi There is no way for user code to have access to the default CLR AppDomain in ASP.NET. The ASP.NET runtime does however use the default AppDomain for some things but it creates a specific AppDomain for running user code. That's why IsDefaultAppDomain returns false and always will :)
Hope this helps!
No, application won't run in the default domain. In one w3wp process, multiple web applications can be hosted and each of them is running in its own appdomain. Asp.net runs some code in default domain to manage those appdomains. e.g. create/unload domain, monitor process memory pressure etc..
ASP.NET Core cannot be run directly in IIS as it requires Kestrel.
This means it is not possible to update a website at runtime like in traditional ASP.NET sites, since the kestrel server have to be shut down during the update.
I want to avoid downtime without adding additional web servers and a load balancer. Is it possible to configure the ASP.NET Core module in IIS to connect to two different Kestrel servers? So if one of them is shut down all requests will go to the other one?
(I was thinking something like having two different folders on disk: C:\inetpub\wwwroot\mysite_instance1 and C:\inetpub\wwwroot\mysite_instance2, thus shutting one down will enable updates of that instance)
If it is possible, are there any considerations we need to be aware of? For example, do the anti forgery token need to be configured in some way? (I do not use sessions.)
I would also be interested in a neat load balancer mechanism, but don't know any way to do it. Yet, you can perfectly switch the directory targeted by a web application from a directory C:\inetpub\wwwroot\mysite_instance1 to a directory C:\inetpub\wwwroot\mysite_instance2, update instance1 and switch it back, and it should do the job.
This is not currently supported due to the way in which IIS and the AspNetCoreModule works.
IIS passes an IHttpContext object to the AspNetCoreModule. The AspNetCoreModule uses the IHttpContext object to query the physical application path. The module then reads the web.config file found in the directory of the application. Once this has been done the module maintains a 1:1 relationship between the IIS application and the dotnet process.
I've raised this as a question and included some additional details on your behalf.
I just heard a very experienced .NET instructor say that a website is a collection of many webapplications and for every webapplication there is a AppDomain.
Does webapplication in this context mean webforms?
In IIS, a "Web Site" is what is tied to a specific host name and port. That web site can contain one or more "Web Applications", which is what can be created in ASP.NET. Each "Web application" is isolated from the others and contains it's own global.asax, sessions etc.
The isolation is not total though, web.config settings are inherited to sub directories. Applications sharing the same app pool can interfer with each other (the sandboxing is not perfect)
A website consists of one or more projects (one could say webapplications, however I think that is confusing terminology), each getting compiled to an assembly. Before the code in an assembly can be run it needs to be loaded into an application domain (AppDomain), which is an isolated piece of memory in which the code will run.
How do I engineer failover logic properly if an Assembly (.dll) cannot find a web.config file?
Background: I've got our website code nicely modularized into two different .dlls. For simplicity's sake, let's call them:
website.dll
commonengine.dll
The website code and .aspx / .ascx files calls upon the commonengine library for all data layer stuff. For connection strings, the commonengine in turn looks not to the app.config but to the website's web.config file (that's my own preference -- I prefer to have our production constants all in one place). The website code occasionally (very rarely) needs to access stuff in that web.config file. All good so far (even though not entirely pure).
Here's the trouble. I've written a third module. It's a Windows Service (specifically, it's a POP3 checker/processor -- processing mailbox requests and using the commonengine.dll for some data layer stuff).
The problem is the Windows Service calls upon the commonengine.dll, and the commonengine.dll cannot find web.config anywhere because, after all, it's a Windows service (.exe) and doesn't live in a website directory.
What's the proper test/logic here to use app.config when a web.config file cannot be found? Can any ASP.NET configuration gurus give me some guidance here? Thanks much if so.
I never read Web.config explicitly, I use the System.Configuration class to read it (e.g. System.Configuration.ConfigurationStrings["conn name"]). It will automatically go to Web.config in an ASP.NET app and app.config in an EXE.
Of course, you still have to take into account the fact that the config section might be missing.