Looking for serial port communication using ASP.NET 4.0. I have a cardwriter/reader from IDTECH which talks through a comport. Is there any way to accomplish with .net through the web.
I read things but most of the topics on speaking about .net 2.0 and I was not sure if they created something to handle this in .net 4.0
Thanks
Anything written for .net 2 should work in .net 4 with some changes that occur between revisions. However, using the serial port from asp.net will not work on most servers as the user that the asp.net process is using won't have permission to access the hardware.
The only way around this would be to build the portion of the process that talks with the card reader/writer as a Windows service and add some method of communicating to the service from your asp.net application (TCP connection or something similar).
The only way this is possible is via a browser plugin. This has nothing to do with .NET (unless that's what you use to write your browser plugin).
Everything you see about issues with the .NET serial port control are referring to desktop applications. As a side note, most of the issues have been resolved in .NET 4.0, but not all. I've given up and now use CommStudio, which is available as an ActiveX control, so you may be able to access its methods from a web page.
Related
I have a Delphi Application with a Client-Server Architecture. Now, I want to write a Web-application for this Delphi Client-Server Application.
To write a this Web App I don't want to use Delphi - I want to use a "modern" Web Architecture like a PHP Framework, ASP.NET, Ruby on Rails etc.
So far i came to one possible Solution with RemObjects (http://www.remobjects.com/ro/) and ASP.NET:
In this approach the Delphi Application communicates with an ASP.NET WebServer over RemObjects where the Delphi Application is the REM Objects Server and the ASP.NET App is the Client.
My questions are:
Is this approach really a good idea and if not why?
What are other possible approaches to solve this problem?
Thank you for your help.
Edit:
Thank you for your answers so far!
How about establishing a neutral link like a Database?
You need a two-way messaging / inter process communication solution. Typically SOAP, REST and other web services (RemObjects) are synchronous, request-response style communication.
A messaging middleware can be implemented in a way which totally decouples the applications so that you can restart any part of the system (for example for maintenance and update installation) without disturbing the others.
Popular open source products in this field are for example Apache ActiveMQ, Open Message Queue and RabbitMQ, which offer cross-platform/cross language clients.
An alternative could be SOAP, or a RESTful connection.
R/O is faster than SOAP, for sure, and well integrated to both sides (Delphi and C#).
And, since you are already using R/O between Delphi client and Server, it will be the first option to consider.
IMHO any RESTful connection between Delphi Server and a C# client may do the work also. And will probably be faster, so is to be considered only in a second phase, if you find any performance or stability problem with a R/O connection.
We are planning on replacing a legacy "server" app (a Windows form app with, although it does not really need it, a GUI representation (showing status messages)) with a simplified service of some sort. The server/service responds to requests for data and sends said data. Will a legacy (.NET CF 1.0) app, which cannot be updated to a newer technology (because the handheld devices on which they run don't have room for the more recent/larger .NET Compact Framework runtime) be able to access "newfangled" services such as an asp.net RESTful web service? If not, what are some other options? Or, if there are better options even with that being feasible, what might y'all suggest?
No, the older .Net "Service references" don't understand newer formats/protocols.
But, at the end of the day, it's all just a bunch of auto-generated code mapping "objects" to XML.
SUGGESTION:
Just parse the XML directly.
If in doubt, play with your target service using SoapUI
Unless you've got a really complicated schema, that's probably the easiest to program - and most memory efficient - solution.
IMHO...
I'm responsible for a .NET process running under windows.
The process is running as a windows service.
I would like to have the ability to be able to get some info from the service in a web browser.
For that matter I would like to write a small ASP.NET web service.
The problem is that I want the run the web service within my process.
As far as I know, I can't do that since ASP.NET must run from within an IIS.
so...my question is, is it possible to host ASP.NET server within another process?
I know that in the common scenario, I should have the "process code" run as "code behind" the ASP.NET but in my case, the .NET service is already a part of our product so in this case I'd like to have the opposite.
Thanks a lot.
You don't have to host ASP.NET inside your service. You can use inter-process communications techniques to communicate between your service and a new or existing ASP.NET webapp. Here's an example using named pipes. Or if you're using .NET 3.5 or higher you can use WCF.
If you really want the service to host its own site I don't think embedding ASP.NET is possible but you can use an http component like this one.
I have a .net application running on server. Now I want to comunicate between my ASp.NET website and the server application.
Currently I use database, server writes info to the db and site uses it etc. However adding new fields to echange and exchanging complex object is a pain.
Is remoting the way out? If yes, what are the common things to keep in mind while doing this.
both server and asp.net site is on the same server
both is under my control
is there any other better way than using remoting?
It is .NET 2.0
The purists will say that remoting is an old, dead technology, and the way to do it now is to use WCF.
If you're attempting to have some SOA thing, the best thing is to a web service for your server application and access it from your ASP.net website application. It's the best way to do.
However I don't really understand what the purpose of the "server" is? Couldn't your ASP.net website - as you say - be your front-end of the server application?? Your "server" would then simply be the business and data layer and there would be no need to use remoting or WCF.
I would say webservices if want to stay .net 2.0, otherwise it think you should take a look at WCF.
If you need direct interaction between assemblies (ASP.NET and some server application or service) you should use Application Domains and cross-domain calls (some good example here) or using WCF, which is better. Also you can use web services if your server application can be accessed via web without major resulting drawbacks (security issues, server deployment change, etc.).
Actually, u can deploy a WebService on that server. WebService is base on SOAP, it can exchange data object with your website.
If you can update to .Net Framwwork 3.5, you can try to use WCF instead.
I have a need to explore VOIP integration into a .Net application. It would be incredibly helpful if the toolset was usable via ASP.Net (version 2.0 or higher), and provided the developer the option to allow interaction on the client either embedded within the web browser or external to the client web browser. It should be compatible at a minimum with Internet Explorer, but would be better if browser independence were an option.
I don't really understand your question -- what are you trying to DO with VoIP? Since you mentioned ASP.NET I'm guessing you mean some kind of server app? If you explain more about what you want to do, we can give you better advice.
You could check out Microsoft's Speech stuff: http://www.microsoft.com/speech/speech2007/default.mspx. As I understand it, Speech Server was moved into being part of OCS. I remember that it supported using .NET 3.0's Workflow Foundation as well as some multi-modal stuff with ASP.NET.
FreeSWITCH is a flexible VoIP system that works for both large-scale server implementations as well as embedded scenarios (say as an ActiveX softphone). There is full .NET and Mono support via mod_managed. (This allows you to create voice applications in FreeSWITCH using any .NET language.) There's also an XML-based API that allows you to send and receive events to control a remote FS server. You could use this from ASP.NET. FreeSWITCH is very active in #freeswitch#irc.freenode.net so you can get a lot of advice there.