I'm looking for a way to establish a simple communication between a c# web application and the operating system.
Since i'm working on Silverlight, i get everything i need to create files into any folder on the C:/ Disk. The problem is that we're going to migrate from Silverlight to Html 5 / C#
So i'd need a way to create files FROM any browser to any OS : Windows,Mac,Linux ..
I thought about using Microsoft Active X but that's not cross platforms.
I'm simply looking for a technology/plugin/software or anything that would allow me to do that, the less client interaction would be the best.
I think your need is in conflict with any common sense about security. If there was a simple way to create any file on any computer that loads your web app, just imagine how quickly all sorts of malware would spread.
But going back to your question - I think it will not be simple (btw. was it really simple in silverlight?). What I can imagine is to have some kind of service running on a client PC (the user would have to install it, or it could be corporate policy if your web app is targeted at corporate solutions). Then the service would listen on some TCP port and your web app could send requests to that port with the intent to create particular file with particular content. All the security concerns would be then implemented in mentioned service so that it doesn't get abused by hostile web apps
Related
My company has several desktop applications that needs to be launched from an ASP.Net Core web application. Also the applications are going to be updated if there is a newer version. The web application would be working offline (only accessible to a specific LAN), and all the applications and clients would be in the same network. So basically, I am trying to create a Launcher/Updater Web Application.
The problem here is, web browsers are not capable manipulating (installing, launching or updating) applications that are on the client machine in a direct manner. We already checked Microsoft`s ClickOnce solution on updating applications but there are some reasons why we do not want to use it.
My question is, if there is any way to read, write and edit client side data, with or without an extra client side application from a Web application?
I had a similar problem. There is no way to update client without using an additional program (at least in my experience). You won't be able to delete and replace libs and executable when the files are in use (read the software is running).
I wrote a small application to handle restart, update, and monitoring of the main application.
If you need more info about the approach I used let me know.
I have a Windows Service written in C#. I have recently added CassiniDev to it to allow remote web administration and monitoring of the service. The integration went really well except for my inability to interact with data layer of my Windows Service from hosted ASP.NET pages.
I have tried putting everything of interest into a common assembly but the debugger shows there are two loaded assemblies with the same name but from different paths. Cassini runs ASP.NET off some temp folder so the assembly I am using is really "a different instance" in the address space of the same process.
I am not sure what is going on here. Probably some "application domain" separation stuff that I do not understand at this time.
So with Windows Service and the web server running in the same process, how can I make them interact? Say I have some status in the Service part that I want to report in the ASP.NET part. Any ideas how I could make this happen? Shared memory or TCP comes to mind but it sounds like an overkill for purely intra-process communication.
If security isn't an immediate concern, i.e. the data isn't highly sensitive and in a controlled environment, then you could have success using Named Pipes. A managed API for processing piping has been implemented as part of the framework, so you don't need to think in native calls.
I want to build some sort of interface that will monitor our real time routing/switching system. I would like to give a lot of visual feedback to be able to monitor its status visually. Our system and clients are not co-located so they would need to connect via TCP/IP.
I would like to be able to service any number of monitoring clients (although this will probably only ever be about 4-6 clients). I thought of using SilverLight but there appears to be one or two tricks involved in getting SilverLight to connect back to an application running on a different port.
I have also thought of using HTML5 canvas and websockets. Another alternative is to just create the clients using normal Window Forms and perhaps WPF. But this means that to monitor the application the client will have to be downloaded before. I would prefer something that is as easily accessible as web app?
What are some of the more common application stacks to achieve this? What should I watch out for?
EDIT:
Just to add: This will be an internal tool only. But we have offices in a couple of locations.
any choice in this direction could be subjective and arguable, surely somebody could suggest any possible web framework or language...
I would consider, however because of your .NET and C# tags, ASP.NET MVC 3, so basically web based plugin-less ( NO Silverlight ) HTML 5 solution.
Consider that StackOverflow is done in same way (MVC, ASP.NET, SQL Server... ) and outperforms as we all know.
the way you grab the underlying events from TCP, so the way you capture and provide the data from TCP, it's another thing from the front end, I would probably write a Windows Service if the traffic is so high and you want to grab and store data anything regardless any active client connection.
There are plenty of real time charting controls out there also for MVC, MS Chart Control. DevExpress, ExtJS integrated ones...
"real time" and Browser is bothering me.
I would indeed go WPF or WinForms. Using the ClickOnce-Deployment you can make this a no-pain for the user and you can roll-out new versions just by redeploying them and having the user restart the application.
In my company this works really fine and we have no problems whatsoever. The only problem with this is, that the app.config is somewhat hard to find and keep current/valid (redeploy) but in your case this won't change per client (or so I guess).
I agree with #Davide - I would go for a WebService that will obtain all routing/switching data in realtime. You will have a web application and on the client side you will have JQuery/AJAX fetching realtime data from the WebService component.
I've seen cool demo's of Web Orb doing something similar to what you want. http://www.themidnightcoders.com/
If you are starting from scratch, it would be good to check out WCF (Windows Communication Foundation). It's great because it can expose your functionality in many ways, using nothing more than modifying a config file.
If you want a Windows client app, you can host it in a Windows Service, or simply include it as a side assembly. For web apps, you can choose between various formats (JSON, XML), channels (HTTP, TCP) and protocols (SOAP, ODP).
If I got it right, there will be a server-side application which will collect information from the devices and expose it to clients as a service. In that case, a WCF application might be hosted in a Windows Service or IIS on a server machine, and expose the data though one or more endpoints (HTTP, TCP).
I am not aware of problems in connecting a SilverLight app to a service, but I would rather go for a HTML5/JavaScript combo instead, for easier deploying and compatibility with a wider range of devices (no plugins needed). ASP.NET MVC should be the best choice for the web app.
I've been writing desktop apps in C# for some time now but I'm increasingly getting frustrated with the fact that not everyone has .NET 2 or Higher installed. I don't have the option of upgrading their systems to meet my needs. My apps are mostly utilities that run alongside the main program the company I work for has. They access the file system and the registry. Being relatively new to programming in general, I was wondering if moving these tools to the web would solve some of my problems. But I have no idea if web apps can have access to these parts of Windows. I was thinking of writing these web apps in either Rails or ASP.NET. So my question is this. Can a web app access and modify the registry and file system of Windows?
Thanks.
Nope, "web apps" like asp.net or rails apps run on the server alone and just serve html to the client. So all the client-side code can do is what jscript running in the browser sandbox can do, ie no file access or registry access.
You can however install an activex on the client computer that gets full access, but the user has to agree to install it as it's a security risk.
Writing the apps as Web apps instead (and Rails is cool to use) is a good option - your users don't need to install anything, upgrades are easy to do, and dependancies are no longer a problem.
However, you now need to start re-architecting your apps so they do not need to write anything to the client, except a cookie (that's stored in the browser). If you can do this, then migrating to a webapp will be great.
If you cannot, my advice is to learn the same language that your company's app is written in. Once you do that, the company app will have taken care of the dependencies already and you will just need to offer your utilities alongside the app, perhaps even in the installer, or just to copy the files into a subdirectory. If you're thinking of learning Ruby, then learning the corporate language will be just as difficult (only you'll be able to reuse a lot of code used in the main app)
No, a traditional asp.net application cannot access the file system or registry on the windows box. Simply put because it doesn't actually run on the client machine. Instead it runs on the server where it does not have access to the local machine.
It is possible to have portions of the application which run on the client machine. Browser based applications for instance. However these would require that the 2.0 framework be installed on the customers machine which puts you right back at square #1.
No, this isn't possible. Web applications cannot modify the registry and/or file system on a user's machine because of the security implications. You would need to develop a Windows app to do these kind of changes. You could always make this tool available for download on your website though.
No, you can't do that with a web application. Besides others have already said, a web application run in a browser, not inside an operating system, so all you can do is what browsers allows you to do and not all you want, and browsers doesn't allows you to take control of the host machine.
I'm guessing the desktop app used in your company uses the registry to store workstation / user specific (state)data.
Moving to a web based app does not mean storing state data is no longer possible, just account for it by including a table in your database that can be used to save that same (state)data in. The registry is no longer needed.
Another pro is that by moving to a fully webbased application, you never have to worry about your endusers, because the code is running on the server, all the enduser gets is the output in html :-D.
The only thing to keep in mind is cross browser compatibility, don't create an app that works in IE only for instance, it has to look and work the same in all major browsers.
There are a few products out there, such as Xenocode and VMWare's ThinApp, that allow you to virtualize your app's dependencies to the point where your .NET app can run on a machine without the .NET Framework installed. Just another option from left field.
I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.