Are there any caveats or short comings to using the new Task API in System.Threading.Task in ASP.NET hosted under IIS?
I know prior to .NET 4.0 working with any of the ThreadPool actions inside of IIS was always recommended to be avoided.
Any caveats to using ThreadPool with IIS would still be valid using System.Threading.Task, as the Task API is just an additional layer of abstraction over System.Threading.
For long-running tasks in the background, I use a ThreadPool inside a Windows Service. This keeps it outside of IIS.
Related
I am creating a cron job using .Net Core which will fetch data from API and insert data into database.
Should I use ConfigureAwait(false) while calling api in asynchronous mode?
I am confused after reading article - ConfigureAwait(false) relevant in ASP.NET Core?
Since I am having console app not a UI app so Please suggest Should be go with ConfigureAwait(false) or not
In short: if you are asking, then you don't need to use ConfigureAwait(false) in your application.
.NET Core framework has no SynchronizationContext. So in this contextless approach from .NET Core, the default asynchronous behavior is the same as we have, when using ConfigureAwait(false), so when an async handler resumes execution, a thread is taken from the thread pool and goes the work.
Source: https://itnext.io/a-deep-dive-into-configureawait-65f52b9605c2
So I am playing around with Service Fabric for rolling out a system to the cloud, and so far I have most of the stateless services ported over and running well using ASP.NET Core.
I have another set of services that need to be stateful, and I would like to leverage .NET Core for those services as well. For those I will need to run a custom TCP protocol, not HTTP/WebAPI/WCF.
So the question is; is this possible? The templates only have a ASP.NET Core stateless service template. Can I build something like a .NET Core console application to run as a "Reliable Service"? If so, is there any documentation on how to do this?
Yes, it's possible.
You can create the .NET 4.5.1 stateful service via the template, and then port that project to .NET Core - we've done this and it works just fine.
There doesn't appear to be any official documentation on this process.
I am looking to implement hangfire into my asp.net web api and asp.net MVC website projects.
The way I have structured my solution is as follows:
Solution - My Solution
1: Model - (Project containing Entity Framework Objects and classes)
2: Services (Where I implement all my> business logic, changes etc.) This is where I will most likely make use of HangFire.
3: Web API (my asp.net api project)
4: Web UI ( mvc 5 Admin interface website)
Both project 3 and 4 make use of the 2:Services project to do work and call services which execute business logic. This is where most tasks will be spun off.
How would I go about implementing hangfire, so that they respective iis sites can both make use of the same "instance" of hangfire. but it will obviously run on the associated app pools?
or maybe it cant work like that and I have to have it running in one place?
What are my options, and furthermore what is the recomendd approach?
The biggest take-away for me was that HangFire will not continue past a work pool shutdown (i.e., idle timeout), which is my core problem anyway, and recommends altering the server configuration to never shut down work pools. If your app is going to be in constant use 24/7, then this shouldn't be an issue for you although your work pool could still be recycled for various reasons, but for an app that will experience peaks and troughs in users then you may want to consider an out-of-process HangFire server.
The approach I'm taking is the later. I'm building a proof-of-concept that has a Windows service (built using Topshelf - highly recommended for this) that hosts the HangFire server (and dashboard), a shared core library, and a client (which will be my WebAPI in production, but is a WPF app for the PoC). The client enqueues a job using a class instance from the shared library, which the HangFire server also has access to.
I'm assuming from your description that the WebAPI controller actions call corresponding methods in class from the service layer? If this is the case, then I would opt for a similar solution to mine, with the HangFire Windows service having access to your services and models as required.
If your app is going to be heavily trafficked and work pool recycles don't bother you, then I'd host the HangFire server in your WebAPI directly.
I'm trying to eliminate (or at least minimize) startup/warmup times for my .NET applications. I'm not really sure on how to do this even though it's a common concern.
There's a ton of questions about slow startup of .NET applications. These are easily explained by pool recycles, worker process startup, dynamic compilation of .aspx files, JIT etc. In addition, there are more things that may need to be initialized within the application such as EntityFramework and application caches.
I've found alot of different solutions such as:
ASP.NET Precompilation
IIS 8 Application Initialization (and for IIS 7.5)
Auto-Start ASP.NET Applications
However, I'm not entirely satisfied with any of the solutions above. Furthermore I'm deploying my applications to Azure Websites (in most cases) so I have limited access to the IIS.
I know that there are some custom "warmup scripts" that uses various methods for sending requests to the application (e.g. wget/curl). My idea is to create a "Warmup.aspx" page in each of my ASP.NET applications. Then I have a warmup service that sends an HTTP GET to the Warmup.aspx of each site every ... 5 minutes. This service could be a WorkerRole in Azure or a Windows Service in an on-premise installation. Warmup.aspx will will then do the following:
Send an HTTP GET to each .aspx-file within the application (to
dynamically compile the page)
This could be avoided by precompiling the .aspx pages using aspnet_compiler.exe
Send a query to the database to
initialize EntityFramework
Initialize application caches etc
So, my final question is whether there are better alternatives than my "Warmup.aspx" script? And is it a good approach or do you recommend some other method? I would really like some official method that would handle the above criteria.
Any and all suggestions are welcome, thanks!
Did you try this IIS Auto-Start feature described here ?
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
You could have two instances of the site. When you need to deploy a new version, and therefore suffer a startup cycle, remove one instance out of load balancer rotation, deploy and start it, set it in and do the same for instance 2. A rolling deployment.
I'm responsible for a .NET process running under windows.
The process is running as a windows service.
I would like to have the ability to be able to get some info from the service in a web browser.
For that matter I would like to write a small ASP.NET web service.
The problem is that I want the run the web service within my process.
As far as I know, I can't do that since ASP.NET must run from within an IIS.
so...my question is, is it possible to host ASP.NET server within another process?
I know that in the common scenario, I should have the "process code" run as "code behind" the ASP.NET but in my case, the .NET service is already a part of our product so in this case I'd like to have the opposite.
Thanks a lot.
You don't have to host ASP.NET inside your service. You can use inter-process communications techniques to communicate between your service and a new or existing ASP.NET webapp. Here's an example using named pipes. Or if you're using .NET 3.5 or higher you can use WCF.
If you really want the service to host its own site I don't think embedding ASP.NET is possible but you can use an http component like this one.