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).
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'm currently working on an ASP.Net MVC4 application to automate a production workflow.
my client would prefer the solution to be "zero footprint", so completely running in browser.
One of the issues I can't imagine how to handle is to get data from a weighing scale connected to the client's serial/parallel port from within the page.
(Obviously this can't be done from the web backend ... )
I've been digging around, assuming this could be possible through javascript/jquery, but since this is running sandboxed within the browser, I'm assuming to get stuck that way ...
One of the approaches I considered was writing a self-hosted WCF webservice to run on the client that has the scale attached (hosted by a windows service or console app or so) that exposes the scale readout. Theoretically, that would allow me to consume the webservice in the IIS backend in my MVC C# code and serve it back to the client.
The only issue with this approach is that this would require the application to be hosted locally, where we'd prefer to have it hosted by an external provider.
Is there no way to handle this on the client side exclusively?
I can't imagine I'm the first person running into this, but I can't seem to find what I'm looking for by digging around on the web ...
Any thoughts ?
Thanks in advance! Stijn, Belgium
You absolutely must have a process running on the system that has access to hardware to support reading from any hardware interface. You have a lot of options there- it could be a local service running that can read the serial port and expose a simple HTTP endpoint to the browser. You can also do ActiveX-style controls for IE or browser extensions for Chrome:
http://developer.chrome.com/apps/app_usb.html
Just as a follow-up:
I ended up creating a user-control that reads out the COM-port through PInvoke of CreateFile to open the COM-port ...
Works great, no hassle with an external process running on the client etc ...
Does require full trust in the browser, but that's acceptable, since it'll run on clients under our control ...
grtz,
Stijn
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 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.
I have a data loading application that has to be executed multiple times per day at irregular intervals. I am planning to write a service to kick off the downloads and import the data to a database server. Are there advantages to using a standard service over a webservice or vice versa?
I think you're missing the point here.
Web Services typically are used for a form of communication or remote execution. You call a remote function on a web-service to either adjust the behavior of the machine it's running on or to retrieve data from it.
Windows Services are background processes that run on a machine without any "logged on user" being required. They can perform tasks and do things while the user is at the login screen, or do elevated operations. You can talk to services to adjust their behavior or retrieve information, but it's general purpose is different than a webservice.
The biggest notable difference here is that web-services must be called, they don't run on their own.
For your application I would suggest using a Windows (Standard) Service, as you can have it execute code once per day. I would only use a web-service if you've got something else to automate the calls to the web-service and you require a response from the server detailing it's execution result (success/fail/warning/etc...)
You could also consider writing a normal (windows or console) application that is triggered by a Windows Scheduled Task. What you've described doesn't necessarily sound like something that would require a service.
Sounds like a good use of a windows service to me. Off the top of my head, I'd use a windows service if:
1. Work is performed on a scheduled basis (regular or irregular intervals) in the background;
2. No interaction is needed - work is just done in the background and kicks off based on polling or some other type of trigger (message dropped in queue, database value trigger, scheduled timespan, etc.);
3. Needs to be monitored (either starts/stops along with logging) and you can take advantage of WMI, perfmon and event log with little effort.
A web service is better for tasks that are interactive (like if you wanted to initiate the download based upon a request received).
Sounds like a windows service is the approach you should take.
Hope this helps. Good luck!
If "irregular interval" does mean, the application is invoked by another application, I would use a web service.
If the action is scheduled, I would use a windows service.
If you are working with SQL Server (scheduled or not), I would also consider SQL Server Integration Services.