I have the following question, how can I access a device / equipment connected to the client's usb through an application made in Asp .Net MVC? The idea is to access a biometric reader connected to the customer's computer.
I have already looked for some alternatives such as ActiveX and Silverlight, but from what I researched ActiveX works only in I.E and Silverlight seems outdated (at least the tutorials and research related to the subject). I saw that it is possible to work this way with Blazor and Asp .Net Core, but it would be impracticable to change the project at the moment. I thank anyone who can help.
Unfortunately accessing a client's usb could be a tad hard. Browsers generally tend to be sandboxed against hackers. So you can't access hardware devices that easily. Even for accessing a camera the client needs to give explicit permission.
More and more webapi's incoroporate native behaviour however, and one of this is apperently chrome:
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
Firefox also seems to do its part:
https://developer.mozilla.org/en-US/docs/Web/API/USB
But be careful, because some limitations may apply. For example, HTTPS seems to be a must-have.
Related
I am a novice programmer. I was trying to learn about networking in C#. I want to know how to create a public server in C#. I tried to search on the internet but I didn't find much. As a public server, I meant to connect to one computer to another from remote or an online server where I can connect from anywhere which is written in C#. I want to know is how to make it and what I need to do that or especially I want the information how can I make one and what I need. I would like to use winform/wpf or console application for the server.(Sorry for my bad English)
There are plenty of resources out there already, you just need to do your research.
A couple notes:
winform/wpf is a technology for desktop programs, with windows and user controls and such. A server has no need for such things.
a server is a server, public or not. Making it public is as simple as making it available at an IP address / domain that is reachable from the internet. This has little to do with implementation.
there are so, so, so many different types of server applications. Some serve websites, others serve databases, and still others just provide raw data in the form of JSON or XML.
I'm assuming since you're just getting started, you're trying to build a web server to serve a website. Here's a tutorial I found by Googling 'c# web server' that seems to get you up and running: https://codehosting.net/blog/BlogEngine/post/Simple-C-Web-Server
Good luck, and remember that SO is a place for technical questions, not a 'how to do a whole thing start to finish' forum :)
I think the keywords you need are
ASP.NET + IIS, for a full fledged server app
HttpListener, for a stand alone server app
The prior is a framework for building a MVC Server application (it also has a subset called WebApi which as the name states is for APIs), and the latter is the class you will need to create a stand alone server application.
In the future, you might want to consider using ASP.NET Core to deploy your application onto linux.
Good luck.
Im creating a web application that can view a few database tables. You can even update the tables from the web application. Everything works fine, but I want the tables also to be updated in realtime when the tables are changed from another client! And even from my windows application. I've heard that you can use websockets between clients. But Can you also use websockets from a windows program to communicate with a webserver? (on the same computer)
All client examples Ive found so far uses javascript, so I think the answer is no, but hope Im wrong. I was planning to use signalR.
Im writing in C#.
Yes. Websockets are not natively in the .NET library for clients. But there are good 3rd party libraries which are free.
I have used WebSocket4Net. https://websocket4net.codeplex.com/
WebSocket is an official IETF wire protocol that can be used by any language. WebSocket is also a W3C official JavaScript API, but there are other language bindings that mimic the JavaScript standard, e.g., Java, C#, C++, iOS, Android, et al.
The Kaazing Gateway has C#/.NET bindings for WebSocket. Here's the 4.0 binary: http://developer.kaazing.com/downloads/byop-edition-download/
Search for "Kaazing" in Github to get the src.
Full disclosure: I work for Kaazing.
I need to find or create an HTTP server that will run on a Windows machine and announce its presence via Bonjour(Zeroconf). I've searched all over the web and can't seem to find anything that fits the bill or even any information about how I would go about adding the Bonjour functionality to a server that I create.
I found that apache has mod_zeroconf, but it only runs under Linux and found that Apple provides a Bonjour installer for Windows, but it doesn't appear to add the announce functionality. I feel like I may be searching in the wrong places.
For my current project I'm ok with using something off-the-shelf, building with C#/.Net, or even rolling a rails/rack based server and setting up the announcement as a separate process.
I suspect you'll need to integrate Mono.Zeroconf.
We are planning to develop a Silverlight 'cross platform' application, that is expected to run on both Windows and Mac with elevated permissions. Mono alone is not an option, as the application requires Silverlight specific video features, supported only in SL 4.0
So, here are some considerations.
1 - The 'Application', should interface with a local database (outside Isolated storage)
2 - The application should be able to talk to native libraries for performing some DVD IO operations.
3 - It has to be installed via a custom installer, much like a desktop app
We are trying to identify the best way to to satisfy the requirements, if possible, with a common code base, probably using SQLLite for the database.
In Windows, things are straight forward. You can use sllauncher to install the XAP with elevated permissions, and you can access the SQLLite and other system level operations via probably a COM layer. Not a big deal.
But how to implement interfacing with SQLLite and system level libraries in Mac? Is there a documented/undocumented way to interface with Mac libraries from Silverlight (Mac)? I think no. One option might be to use Mono's XSP web server, and run an ASP.NET site from the local machine, and host the XAP locally, and then implement a handshake with the ASP.NET code running via Mono/XSP, and then do the interfacing from there.
Another option will be to host the Silverlight in the Mono's Winforms browser control (I still need to see if this is possible), and then do the talking between Mono Winforms browser and Silverlight via HTML DOM.
Both are not straight forward options in Mac.
I highly appreciate any inputs you can provide to achieve the objectives in a better way.
Part of the solution could be to define an interface on your database. In windows you could choose to talk directly to it, and for mac you write a soap server. Your silverlight app should be allowed to talk to that. You can implement the soap server in mono, then you have one language all way....
I don't believe the Winforms browser control works on Mac, but you could try MonoMac instead.
I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan
I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.
You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)
I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.