Azure Web Job run in separate process? - c#

I have the following solution setup with 3 VS Projects all running in Azure:
-ASP.NET MVC site
-Azure Web Job
-C# Data Project
MVC site and Web Job have a reference to the Data Project. In the data project I have a static List<> "cache" when keeps some data in memory when called from my MVC site.
My Web Job is processing some data, then I'm attempting to clear that static cache in the Web Job itself. Is that not possible since the Web Job simply runs in its own instance when referencing the Data Project? This appears to be what I'm seeing.
One thought I had was to expose and end point on my MVC site which could be called from my Web Job to clear it (worst case)
Any other thoughts here?

No, one process cannot access to another one's classes and instances.
The best you can do is as you said create a mechanism to intercomunicate both processes, through an end point, a socket, a pipe or the one you best like.

Related

Asp.net application life cycle

This question might sound silly but I never got a clear answer anywhere. I am trying to figure out how asp.net application actually works, in windows app (.net) when an application is deployed on one or more PC then user can click open the app and an instance of that application is created, if user again opens the app then another instance is created (opening multiple excel files could be an example). But on web, since the application is deployed on web server and there could be multiple user requesting same app so is there a mechanism to create an instance of asp.net web app for every unique browser request? In another words if A and B are two users and access same app then does two instance (inst A , inst B) are created on web server to process the request?
Webapplication itself has one instance. Each request is handled by different threads. Each request goes through application pipeline (different for old ASP.NET, different for ASP.NET Core )which in most common scenario creates new instance of class responsible for handling request (usually controller). Rest is defined in scopes (so if some of your classes are singletons or limited instances or you use IoC containers with defined scopes), then they can share instances between different requests.
Basically what you don't see is a main loop function provided by framework, which handles all requests, creates classes instances and passes control to your code.
Asp.net along with the web server and OS use threads to handle each request. Threads are much the same as processes you describe for separate instances of Excel. The threads allow each user session to be handled independently by the web server.

Routing API project and Web Application project in the same domain (Azure)

Background
I have two separate projects in my solution. One of them (the web application project) is responsible to show the landing page (on the root of the domain, say www.example.com) and a documentation for the API (say www.example.com/documentation).
The other project is responsible for the API itself. It's path must be www.example.com/api/v1/ to ensure compatibility with our previous software.
We made this way to be able to publish updates to any of the projects without the need to publish the entire solution, and of course, for organization.
Problem
I don't get how to configure the applications to run on Azure on the same domain with different routes, and I'm stating to fear that it is not possible.
I already tried to configure a subdomain (say api.example.com/v1), but it can't be done because we will break the compatibility with our current clients.
This question is almost what I'm looking for, but it does not show how to do on Azure, and this one is on Azure but using subdomains.
First: you have to create 2 folders, 1 for your web api and the
second for your web app
second: you have to set the two folders as an application.
after doing those two steps you can acces to the two folder by puting:
www.yourdomaine.com(or another)/nameofyourfolder
good luck

How to access a RIA Services WCF WebApp from another WebApp?

I have a silverlight application which accesses its data through RIA Services, from a WCF app in the server. The current structure looks like this:
DataWebServer - A Web application project, which holds the .aspx page that will call the Silverlight components, the .edmx model file and a MyService class, inheriting from LinqToEntitiesDomainService<FortWayneDB>.
Silverlight App - Contains .xaml e .cs files that will generate the .xap binary files, hosted by the WebServer. It access "DatawebServer" project through RIA Services.
It's all working fine, but now I need to create a new application, and since we will going to need it to run on platforms like tablets and smartphones, we decided to build it in HTML5, instead of Silverlight.
How can I make this new WebApp to access the data entities on "DataWebServer" project?
I think of 3 different solutions, but I'd prefer the third one, which exactly my question.
I could place the new WebApp in a folder in the same webprojeect "DataWebServer", but that wouldn't be very organized, I'd rather separate this app from the "DataWebServer".
The second alternative, which I will follow in case I can't succeed with the third, is to create WebMethods in "DataWebServer" to be accessed from my new WebApp.
the third, which I don't know how to do, is to make my new Web App to access the Entities through RIA Services, in the same way the Silverlight Client does. I've searched the Internet, but all articles I've found show how to access RIA Services from the same project. Does anyone know how I can do that?
The first method is the most sensible.
From your details, I assume the DataWebServer is "publicly" accessible; at least as much as your WebApp would be. There is little value in having WebApp data requests go to a different server, DataWebServer, as this introduces an unnecessary delay while one web server calls another. Instead of re-using the HTTP services from DataWebServer, add the WebApp functionality to the DataWebServer and re-use the LinqToEntities context.
If you desperately want the third option, you should consider creating your WebApp in a way that the JavaScript in the app calls the DataWebServer for data from the client's browser. Importantly, this approach avoids WebApp web server calling to DataWebServer for data.

What is the best way to implement scheduling in asp.net MVC

I have an asp.net MVC web application that requires tasks to be scheduled. (A large chunk of functionality is scheduled)
I am using Quartz.net as my scheduler and am currently running it as a windows service. Clustering to handle load and performing resource intensive tasks out of peak hours
The problem I face is to be able to schedule all the required functionality I have to include everything in the scheduler service including all assemblies and most of the mvc base ( e.g using the MVC views to generate email reminder templates ) so the service becomes a duplication of the web application with lots of additional code to make it play nice. This is becoming a bit of a nightmare.
So I can?
1) Configure the scheduler to work within asp.Net MVC.
2) Use a Widows service that calls the required web page.
3) Use current service design.
my preference is probably #1 as this will resolve all of the above issues but the web app will get recycled/stopped if there is no activity for some time, This means that scheduled jobs may not be executed (only if there was some activity around the time when the job should be run).
Quartz.net setup in an asp.net website
Any thoughts/suggestions as to which is the best approach or any alternatives?
I would definitely avoid option 1. Your website should be request and response, nothing more.
If the action performed by your service is not 'long running' and can reasonably be performed as part of the request/response cycle of an HTTP request, then option 2 is reasonable. This should really be a web service rather than web page call, however (this is easier to do in OpenRasta which makes no distinction between web sites and web services).
If your scheduled action is intensive/long running then it ought to be done outside the website and your current architecture is probably ok. The replication of assemblies isn't really a problem (disk space is cheap).

View need to go Winform to Webform, what is your advices?

Our application is well structured (well we did our best!) and we have split the Model from the View, Now, we need to let some information to our client with a web access. We would like to build something small with IIS and some webform.
Here some information you might think are useful:
Our controller have Thread of database queries
Our database is PostGresql
All is build with C#2.0
We used a lot of databinding between our View and Controller in Winform.
Winform will stay for internal purpose, only a small part will be available on the Internet.
What are your suggestions for this kind of move?
Update
We will host the web in our company server so the database will stay inside the business. No need to duplicate data or any synchronization.
I think the "synchronizing" Michael is talking about is the data in the database and the view presented by the Winform app.
We had a similar problem, and the solution we came up with is to create a Web service that exposes the data via XML and use the service from both the web app and Winform app. Every time you update data send it to the web service, and every time you perform a query get the latest data from the service. Do not consider caching data on the Winform app unless you have profile data showing it is a bottleneck, or you want to run unconnected from the network.
This is perfectly possible in .Net 2, you do not need 3.0 or WCF.
The biggest challenge is going to be synchronizing your database between the local Winforms application and the hosted Webforms application. Once you do that, creating the web app is easy.
If your web application is read only, then you can set up replication. Find a tool that you like. Three that I found through a quick search are:
Slony-I
Mamoth Replicator
Bucardo
If your web application is not read only, then the problem is more difficult. You might want to consider upgrading to .NET 3.0 or 3.5 so you can use WCF. If there is a significant overlap in functionality, you might want to move your data to the web exclusively and expose it through WCF services.

Categories