I have a question that is perhaps slightly towards architecture and design rather than syntax problem....
I have a c# winforms app on my desktop which I have built which is similar to a CRM. I make updates to customers records as they submit orders/invoices etc and what I would like to do is to build (or buy) a module that will update a remote database that sits behind a website onto hich registered clients log in. I want the clients to be able to see the status of their invoice/purchase etc as I have updated it on the winforms app.
I can think of a couple of options of the top of my head but would like to know more if you have done something similar
Things I am considering are;
>Replication - I think this is overkill as the updates are not
huge, are one way only, and not
critical they are in real time, and
also I am running SQL express on the
winforms app. This can be changed
but rather not
>create a text/xml file that gets created and uploaded to the web
server to a location that is
monitored every 5 minutes and then
updates the web database. - I am not
hosting the website myself so I do
not have complete control over what
I can install but I suspect I can
install a .NET 'filewatcher'
Anyway, I would appreciate your thought on my 'problem'
thanks
I think your best bet is to create a web service of some kind (I like using ServiceStack.net to create simple REST ones, much cleaner imo than WCF). This will sit on the server and be responsible for the server-side sync piece.
On the client, you could either have the winforms app fire off the call to the web service based on some threshold of activity, or you could have a windows service that you install with the winforms app which does it in a scheduled job or on a timer.
You'll want to be sure that you're doing all your calls over SSL of course, and make sure you're authenticating the clients, but that's the basic architectural approach I'd take.
Related
The current project I'm working on is a Windows Form Application, which in large part functions as a background service to make Queries to a decent number of APIs and store that information into a database. Pretty straightforward.
As I implement more data sources the issue I'm running into is that one of the places I'm pulling from wants to use webhooks to push that data to me. Again fairly straightforward, I did some tutorials on making ASP.NET Web API projects and all of that makes sense in isolation.
Now what I'm confused about is to tie it all together. From my understanding, the options I have would be to have the Form application and the Web API application run separately, which seems like more separation than I want (especially considering that the webhook is for a single item of data that already ties into what the Form application is handling). Alternatively the other option would be to get the Form application to to self host a Web service which seems like the way to go, but I'm unsure of how to approach that without starting with the Web API shell.
I tried reading up on it and this and this seem to solidify that it would definitely be possible to just host the webhook receiver/controller server inside of the form application without making a new project for it. But I'm not sure of what config, new files and settings of that kind it would take.
I would be super thankful for anyone who could offer guidance about how to go about implementing this webhook controller in a project type not designed for it by default, or if you could tell me that it's a bad idea and I should make separate projects for them.
Thank you for your help!
"Webhooks" (or HTTP callbacks, in general) require a publicly routable address. At home, your desktop computer likely sits behind a NAT and with a dynamic IP address, so it won't work unless you enable port-forwarding and find out your publicly routeable address (assuming it's possible at all and you aren't running inside a restricted company or school/university network). You'll probably want to use AWS Lambda or Azure Functions as a quick and simple way of accepting messages from the public web which your desktop program can retrieve them from later-on (using a "mailbox" paradigm). You could try making it work in real-time with a WebSocket or EventSource but I don't know if that works from AWS Lambda or Azure Functions - if it doesn't then you'll need a "real" website.
I was not quite sure how to phrase this question.
What I want to do is create a simple server type application in C# which simply listens for incoming socket connections and handles them the way I specify. It could be a chat application or something like that, very simple.
I looked at the example: http://msdn.microsoft.com/en-us/library/fx6588te.aspx about asynchronous sockets.
I understand the code in the example except I'm uncertain about how the code would execute. Specifically, what would be the entry point of the application in the example? How would the server know to start it?
My only experience with IIS is in web forms with C# codebehind. I understand that the code for web forms is executed when the url points to the location and then again on postbacks etc.
Where it gets foggy for me is when I don't want to use a web form but simply a collection of C# class files with a single entry point (similar to a java application).
Edit for clarity:
The goal of what I want to do is to create an application which I can put on my web host which will continuously accept requests from client applications and handle them the way I will specify and then return information to the clients. I'm just not sure how to tell the server to start the application since I only know about web forms.
Also, it would be fine if I needed to initially direct my browser to a web form and, say, press a button to start the application. In fact, it would be ideal if I could start and stop the application at will.
Also, I may have used incorrect terminology. I thought IIS servers were what you called a server which can run asp.net applications. I could be very wrong about this.
Thanks.
you cannot use IIS to start windows applications, you need a windows service application that constantly listens to the port specified, and that windows service application needs to be scheduled to start either at system start up or at any event of your choice. and that windows service applications needs to stay in memory as long as you want your app to function.
PS: your question seriously needs some editing, but I am also new to SO, so I will let respectable senior users to do what they are best at.
EDIT: If you want to simulate windows service using IIS than here are your closest bets, please follow the links to know what you need to know.
Simulate Windows Service Using ASP.NET App
Forcing your Application to Stay alive
These two links will help you keep alive your application and bamm, you can create any number of classes (Java style as you quoted) to perform whatever tasks you want it to perform
It sounds to me like you don't want to use IIS at all. IIS handles the listening for you and is the "service" to manage requests. If you are lookng to manually listen for incoming connections, then you will need the following components:
A windows service running that has..
A http listener built into it.
Take a look at the C# HttpListener class and look at the process for building a window service that can run in the background of your server.
This isn't all that difficult, but I'm not so sure it's what you need. If you don't want to use webforms, you can have a web application that resolves requests straight to custom handlers which i THINK is what you're actually looking for and makes having your own listener overkill.
EDIT: Additional info on custom handlers
Here is a start on what a custom handler is and how to use it:
http://support.microsoft.com/kb/308001
I would also look at some beginner articles on MVC3 from .net. MVC is a framework that doesn't have any of the fluff (such as viewstate) that webforms has and allows you to route a URL (request) to a Controller (class) and return pretty much anything you want. There are a lot of advantages to using MVC and if you are coming from a java/pure http background it will make much more sense than webforms.
You can get started with that one by searching around for "getting started with .net MVC3" or even start with www.asp.net for beginner resources.
Unless your goal is to learn low level TCP communication, writing and configuring services, dealing with code changes, writing own serialization/request parsing than sticking with IIS and HTTP maybe easier approach.
There is no need to use WebForms - WebService (ASP.Net or even WCF) or MVC Web API will give you ability to implement methods you want without need to write your own custom serialization and request parsing infrastructure. You can even do long poll if/when needed (i.e. SignalR).
I'd start with basic MVC application reporting JSON results as server side as it will still show all issues involved with writing chat client (persistence, discovery of other clients, quick status updates) while allowing you to focus on communication itself (including easily see all traffic if need).
I have three applications running in three separate app pools. One of the applications is an administrative app that few people have privileged access to. One of the function the administrative app allows is creating downtime notices. So when a user goes into the administrative app and creates a downtime notice the other two apps are supposed to pick up on there being a new notice and display it on the login page.
The problem is that these notices are cached and being that each app is in a separate app pool the administrative app doesn't have any way to clear the downtime notices cache in the other two applications.
I'm trying to figure out a way around this. The only thing I can think of is to insert a record in the DB that denotes the cache needs to be cleared and the other two apps will check the DB when loading the login page. Does anyone have another approach that might work a little cleaner?
*Side note, this is more widespread than just the downtime notices, but I just used this as an example.
EDIT
Restarting the app pools is not feasible as it will most likely kill background threads.
If I understand correctly, you're basically trying to send a message from the administrative app to other apps. Maybe you should consider creating WCF service on these apps that could be called from the administrative application. That is a standard way to communicate between different apps if you don't want to use e.g. shared medium such a database and it doesn't force you to use polling model.
Another way to look at this is that this is basically an inter-application messaging problem, which has a number of libraries already out there that could help you solve it. RabbitMQ comes to mind for this. It has a C# client all ready to go. MSMQ is another potential technology, and one that already comes with Windows - you just need to install it.
If it's database information you're caching, you might try your luck at setting up and SqlCacheDependency.
Otherwise, I would recommend not using the ASP.NET cache, and either find a 3rd party solution that uses a distributed caching scheme, that way all applications are using one cache, instead of 3 separate ones.
I'm not saying this is the best answer or even the right answer, its just what I did.
I have a series of ecommerce websites on separate servers and data centers that rely on pulling catalog data from a central backoffice website location and then caches them locally. In my first iteration of this I simply used GET requests that the central location could ping the corresponding consuming website to initiate its own cache refresh routine. I used SSL on each of the eCommerce servers as I already had that setup and could then have the backoffice web app send credentials via SSL GET to initiate the refresh securely.
At a later stage, we found it more efficient to use sockets instead on the backoffice where each consuming website would be a client and listen for changes in the data. The backoffice website could then communicate to its corresponding website when a particular account change and then communicate this very specifically. This approach is much more granular and we could update in small bits as needed as opposed to a large chunked update but this was definitely more complicated than our first try.
I've been away from web development for 6/7 years now and I'm completely lost in regards to how to do things. I'm going through some tutorials on HTML5 and whatnot, but I was hoping to get a helping hand here.
I'm trying to build a (POC) website which would have the "server" monitor it's running applications and when a certain application is running change the content of a hosted page. I don't want the model to be PageLoad->Application Check, I'd rather have something like ServerStart->ApplicationHook->Callback->Model->PageLoad->CheckModel, so a hook is put in place when the server starts and the callback of the hook updates a model which the page uses to update. Although this architecture may not be the best way, in general I'm just looking for a way to have a long running process which starts when the server starts up. Eventually I'l move this to a Windows service which calls a webservice when changes are made, but for a POC I'd rather keep away from multiple applications interacting, as the Windows Service would need to be "called" by the server too and I can't think of an easy implementation of that at the moment.
So, if you were building a page which relied on events on the server and needed to be able to interact with an application on the server separately to an individual page, but the page needs to be able to "post" information back to that application what would you do?
My explanation has been a bit all over the place, so I hope at some point my question has come across clearly! :)
Maybe there're alternatives but I think your only option for this kind of setup is a Windows service. If you need to talk to it from other components, have it use sockets or listen for HTTP requests on a known port. Doing what you described from a web application is not impossible but it'd be certainly very hard since it's the web server (app pool executable) that controls what happens in the process, not your code. In a Windows service, you're in control.
Edit: here's an article about the different options for hosting a web service - it seems to me that using a Windows service is, indeed, your best choice. You may be able to use a WCF service but you'll have to talk to a local application on the server and that part may be easier to do just using a Windows service.
I have one application which is developed in ASP .NET MVC 3 which using a SQL server database.
Apart from this, I have one console application which calls an external web service and update the same database with the information and business rules. (Basically we iterate the records from Web service and process the business rule and update the same database), we have configured the console application with Windows scheduler to process it periodically.
The problem is, when my Console application runs periodically, it uses the 100% CPU usage (because we're getting more than 2000 records from web service), and because of that my current MVC application is gets haging OR sometime works very very slow because both application are configured on same windows server.
Could anybody please do let me know that How would I resolve this problem where I want both the things on same server because I have central database used by both application.
Thanks in advance.
You haven't given any detail that anyone can really provide resolution, so I'll simply suggest how I would approach it.
First, I would review the database schema with a DBA to make sure there aren't things like table locks (or if there are, come up with strategies to compensate for them). I would then use the SQL Server profiler to see where (or if) there are any bottle necks in SQL server while these things are running. I would then profile the console application to make sure it's not doing something it doesn't need to be doing. I might even consider profiling the web site to see if there's anything in there that might be contributing to slowness.
After that, I would figure out how to get rid of the Console application and work its functionality into the site. Spawning another application on a given web request is not scalable. More than a couple of those come in at once and you've got the potential to bog the server down very easily.