I have created a chat for an ASP.NET WebForms application. I used SignalR (without Redis) to create the chat component. Everything worked accordingly on my dev machine.
Once the application got deployed to the IIS the SignalR chat stopped working. The reason I found is that the IIS server is configured as a web garden and SignalR is built to work on a single worker (more explanations here).
After reading the link above and some search I found that I could use SignalR + Redis to overcome the Web Garden issue. But, I also saw examples of AJAX WCF Services powered chat apps.
Which of the two is a better way to build a chat application, taking into account the Web Garden issue and the fact that deployment is done on a Windows machine (I read Redis works best on Linux)?
Related
There is a scenario where we have two applications. One is share point and other obe is Web API.
For security point of view, we need to deploy second stand alone project into the firsy application.
In IIS, I deployed one application. In that folder I deployed another application and make it as web application.
Now everythings runs fine. SharePoint applicantion consume APIs correctly.
Now, I have include signalR to both application where web api application is server and share point is client.
I have global asax file and add startup file for owin signalR. If I add owin automatic startup to false then application runs fine but signalR will not work.
If I start owin then neither api work nor signalR will work.
Important point is when I run SharePoint application from IIS and run web api from visual studio and set path of web api for signalR then it works fine.
What could be the issue?
So I'm creating a new .Net Framework 4.8 Web API in Visual Studio 2019 and I'm wanting to know how to create the API as a windows service? I can't seem to find any examples or online resources to do so. I can run the API locally in VS and it opens Chrome and shows the responses under the local IIS Server it spins up. How do I take this same project and compile it as a windows service while still using HTTPS?
Web API is fully capable of being self hosted on top of OWIN, and does not require IIS to run.
Web API self hosted is basically just a console app. So the techniques for turning a Web API console app into a Windows Service are the same as for any other .NET console app. You can use a service manager such as NSSM, or create a Windows service project directly (by inheriting from the appropriate classes, pretty messy) or use a library like TopShelf.
Note that it's generally not a good idea to directly expose this self hosted app directly to the public. IIS provides a lot of security benefits out of the box designed to protect against malicious requests. If you're planning to publicly expose it, make sure you stick a proxy in front of it that will fulfill those security needs.
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.
Objective:
We have a Windows Service/generic EXE that also hosts a WCF service (.Net 3.5). I'd like to be able to take a third party ASP.NET component in a DLL, and host it through that WCF Service.
Is this possible to do, in any way?
It seems like if you want to host a ASP.NET app, it must be through IIS, but we don't use IIS.
Is there any way that we could load the ASP.NET app into memory, make the app available through an endpoint, and receive requests back from the app?
Specifically, we'd like to take the "Microsoft.ReportViewer.WebForms.dll", expose the web form in a web page, and accept any requests back from the web form.
http://msdn.microsoft.com/en-us/library/ms251723.aspx
Looking for anything to get me started. Thx.
From owin.org
"OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools."
Essentially Owin implementations, like Katana (OWIN implementations for Microsoft servers and frameworks.), help you self host web apps, even in a Windows NT Service.
According to this post, hosting a WebForms app outside IIS/ASP.NET is not possible.
WebForms are tightly coupled to ASP.NET/IIS and cannot run directly on
OWIN/Katana (e.g. outside of ASP.NET/IIS). However, you should be able
to use Katana's middleware (Security, CORS, etc.) in a WebForms
application.
http://katanaproject.codeplex.com/discussions/571291
I'm playing with Azure asp.net development. I use Visual Studio 2010, with Azure SDK and I'm a newbie to Azure cloud.
I created several apps and deployed them to my testing Azure Web Site. Everything works fine - ASP.NET Web Page, ASP.NET MVC3, even simple GridView binding to an Azure SQL database, which I created earlier and that I manage with Microsoft SQL Management Studio, using ADO.NET. It's really simple.
Now, I learned from some tutorials, that I need to use a Windows Azure Cloud Service Project to make sure that my application will work. But it works without this project, too. So what exactly do I need such a project in my solution for?
There are actually three different ways you could have gotten your ASP.NET app over to the cloud, and the confusion comes because you are seeing elements of two of those options.
A Windows Azure Web Site is just a single ASP.NET application running in Microsoft's data centers (versus on premises) so all of the configuration it needs is already part of the project itself (primarily the web.config), some being exposed via the Azure portal. In many ways, this is similar to web hosting providers.
A Windows Azure Cloud Service is a collection of multiple services, which could be web sites/services (Web Roles) or backend code (Worker Roles). The code for your Azure Web Site could also have been deployed exactly as is as a Web Role, but in that case it would be part of a larger application that potentially contains additional Web and Worker Roles. It's the Cloud Service project itself that provides the additional configuration of those web and worker roles (even if you have just a single role in the cloud service). The Cloud Service offering is considered Platform as a Service.
The other option, for completeness, is to create a Virtual Machine image yourself, install your ASP.NET site, and then have Windows Azure host the Virtual Machine. It's at the opposite end of the 'make it simple to deploy' spectrum, but you get a lot of control over what exactly is on the VM that you deploy. This is the Infrastructure as a Service offering from Azure.
I'm going to assume you're developing for Windows Azure Cloud Services (the foundation PaaS solution of Windows Azure). The Cloud Service project defines your application to the Windows Azure Fabric. If you don't already have one, then odds are your are running your application outside of the local Development Emulator. If you are going to deploy your solution to Windows Azure Cloud Services, you will need to create this project for your application so Windows Azure's Fabric (the secret sauce that will manage your application) knows how to manage the application.
And I'm going to assume the opposite to #BrentDaCodeMonkey - that you're developing for Azure Web Sites, and not Cloud Services - in which case you may have confused yourself with the tutorials, as I don't believe a Cloud Services Project is either necessary or advisable.