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
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.
Some information:
I've got a USB scale attached to a local machine that's being read by a .NET application. I've also got a web server that needs to get these scale readings and display it to the end user in a browser window(IE 10).
We have a solution now that does this already, by having the win app send data to the web server which relays it back to the user with a jscript control. It does the job, but it causes performance issues as the scale is constantly updating and sending data to the server and back, and if there's a delay it causes all sorts of issues. so I'm looking for a solution that DOES NOT send this data over HTTP at all, but still displays in the web form.
It seems like it should be easy to just have the jscript retrieve this same data somehow but it's apparently not so simple. There's security issues, among other things. I've looked into things like Silverlight and ActiveX controls, which seem like they may be capable of doing the job but I was hoping there would be a better(or just simpler) way of doing it, perhaps with jscript directly. I thought of just using some local file that both of these applications can access but it seems like there would be issues with permissions and synchronization. Any thoughts?
I don't know that you would consider this simple, but it seems as if a more correct way to do it would be to setup a web service on the computer that is connected to the scale and then query this web service using ajax from the browser.
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'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.
Overview
C# File - Users PC
PHP Server - Hosts Webpages for application
Server and Users PC on local network
I have a c# file that reads weight from a USB scale. How would I trigger this file to run so it feeds into my program. The problem is I am using PHP to host our webpage/application so its not running client side and the scale is not hooked up to the server but to the clients PC.
The C# script would have to be on the clients in order to read the scale so how would I trigger this to happen?
Is this even possible and if not what would be a better way?
Important Edit
I was able to run the Scale Script (C#) when I wanted by having PHP and C# use TCP sockets.
The C# would listen for PHP to send something and when it did it would read the scale and send this information back to PHP becuase PHP was listening for a response. Mixed in with a little Ajax and it updates in the web browser.
Gave Chris Credit because he was the most helpful with answering my questions
It sounds like what you really want is for the client application to submit the data to the website itself, and the most suitable approach is probably to expose a web service from your server.
This service should accept weight data, along with some sort of customer key or whatever, to correlate the records correctly on the server side. I've never created a web service in PHP personally, so I can't give any advice on the implementation of that, but it is fairly trivial to hook a C# client app up to a web service once you've exposed its metadata (assuming you use SOAP).
you can't start C# application from a web page in a way that'll work in every browser every time. BUT, you can have some workarounds:
Use ActiveX component that read the data in the client and upload it to the server. the biggest cons is that it'll only work in Internet Explorer
use Silverlight client application that runs on elevated mode (v4) and upload the data to your server.
refer your clients to download application (the C# application you wrote about) and run it - this application will upload the data to your server.
hope this helps.
C# isn't a scripting language, it's a language that compiles into executable binaries or libraries. You won't be able to execute C# code on the client's computer via a website because C# code needs to be compiled before it can run.
Presumably what you really want is for your compiled C# binary to be executed on the client's machine via your website. You won't be able to easily do that. There are a lot of security measures in place to prevent browsers from running programs on your computer. There may be ways to hack around these security measures by using plugins (such as ActiveX), but it's not something that will be a one-liner.
Edit: I think you need to step back and think about what you're trying to do in a broad sense. You're trying to create a website that can read information from a user's USB port. This is the type of thing that browsers are designed to prevent, and for good reason. I wouldn't want random websites to be able to access peripheral hardware without my explicit permission. If you want this website to function the way you're expecting, you're going to have to seriously think about the security implications. You'll need some kind of client-side code (ActiveX, Silverlight, ...), and the user will need to explicitly give permission to for this all to happen. It won't be easy, and it won't be automatic. And I'm damn glad that's true.