My setup requires a web app to start a desktop app. There is a method for doing this mentioned here:
https://weblogs.asp.net/morteza/How-to-run-a-desktop-application-from-a-web-page
However, I would prefer not to make a registry change. Also, I have a file-system connection to the web server, so the server can write a file to my remote profile.
The question is, what is the best way for a desktop 'listener' program to detect that a file has arrived? (so that in this case it can run a script for a larger desktop program).
By 'best' I mean low impact, so preferably not checking the remote directory every half-second. The environment is Citrix Windows, (code used is C#).
Thanks for reading.
Related
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
I have done plenty of C# shell command calls, apps, batch files etc. The other day I was asked if it would be a problem if an executable that I currently run from my web site app, would move to another server on our intranet.
In other words the web site app and the executable that I am running through Process.Start(...) are located on the same box currently - all good there. Now there is a wish to separate the two on two different servers.
I done a few futile attempts to execute an app (located on server B) from server A (where the web site resides).
Is there a way that I have not run cross yet to do this ?
Thanks
PsExec is one way with minimal coding. Using System.Diagnostic.Process, you can call this command:
psexec \\ServerB (path)\myapp.exe arg0 arg1 ...
To control the processes of server A by running an application on server B, you would need an application running on server B that would get controlled remotely somehow.
As an example, let's say server A runs unix, so you could write a application that would connect to server A using ssh, authenticate and then control the processes and whatnot like you do in a shell. If server A does not allow ssh connection, you could write your own application that would be running on server A listening to some connection and commands that would come from an application in server B.
It's quite hard to understand what are your current settings and why would you even want to switch the application from server A to server B, so a little more information would wield you a better answer.
Austin's PSExec approach is probably the easiest approach to executing an EXE on a remote machine, but you may want to consider a potentially more robust solution:
You could modify your command-line app to run as a service and to respond to requests for work and/or data via a WCF (binaryXML/TCP or XML/HTTP) call.
I want to run an exe on client system from my c# asp.net website. When I use Process.Start()
it throws an error:
The requested operation requires elevation.
How do I set permissions to run that exe?
You can't spawn processes on the client machine from server-side code.
When you use Process.Start in server-side code, it is attempting to execute the process there, on the server where the website is hosted. If you wanted to create processes on the clients computer then you would need to expose a download for them (and not in employing subterfuge, like malign sites might do to install software - supply it gracefully, and normally (and with permission)), or a Silverlight application or something along those lines.
The bottom line is that the code you want to execute (even if that is just to spawn a process) must reside on the client, and be executed there.
You can't run an application from a web server like that. You will have to have the user download the application by supplying the EXE, a setup file or using ClickOnce.
Or you can develop an ActiveX control that you can have the browser automatically download from a Trusted Internet Zone.
Once downloaded, proper signing with a certificate (signed from the trusted (corporate) root certificate) will avoid the user getting a prompt to ask whether he wishes to allow the ActiveX control to install/be activated -
The ActiveX control can subsequently do anything the interactively logged on user could. This means that to actually install a program you'd need to elevate (UAC on Vista+); But if the goal was just to run a standalone executable, you should be good to go.
This all assumes white-hat purposes in a (larger) corporate setting, because it relies on PKI infrastructure and central browser policies, to name just two.**
This would, really, lead to some excellent questions on serverfault or superuser
I noticed you said you wanted to run an exe file on the client, but you didn't say explicitly that the exe is on the server and you want to push it to the client. Everyone seems to be assuming that is the case.
You CAN accomplish this fairly easily with a small JavaScript if you have a few prerequisites:
The executable is already present on the client machine.
All of your clients are running IE
You can enforce a policy to put your site in the Intranet or Trusted
Sites zone.
So basically this means it's a corporate intranet application. I am assuming this is probably the case since, well, if you were expecting to do this with a public app, I would be surprised.
For the script to accomplish this, please see my answer to this question:
How can I get a program on a client machine to run from an ASP.NET page?
I am writing a Windows application using C#. I am planning on later to allow it to be controlled over the intranet using browser also. So in future we should be able to control it both using the local interface or over the intranet from the browser.
Is there any pre-defined architecture which will allow me to do this? What are the methods of achieving this? I am new to C#/.Net.
EDIT:
The windows application needs to access the communication ports extensively, and needs to be pretty stable and would probably run for some days together.
Thanks...
I can't tell you if a specific package exists that would ease the development. But, if I were to attempt it, after Googling and not finding something already available and meeting my needs, I would likely make my application a WCF host. Create service entry points to accept control messages remotely. You would also need some well-know location where to register your application so the remote system could find it. You should be sure to provide the user with a way of disabling the application remote control feature.
Your host interface will need to run on its own thread to remain performant. Since you are new to C#, and presumably windows forms application development, you will need to read up on how to properly talk to the GUI controls from a non-GUI thread.
Alternatively, you may want to implement your application as two distinct units, one with a GUI that does all the user interaction. It would form service requests to send to the host portion (with no GUI). Your app could then operate locally or be controlled remotely.
One solution I have used in a similar situation has three parts :-
1) Win32 (local) Service
Manages the COM ports and does whatever is necessary with the attached hardware
2) WinForms/Console Application
Runs on the local machine and communicates with the local service via named pipes or TCP.
3) Web Server + Web App
Runs on local or remote machine & communicates with local service.
The local user can shut the WinForms application down and log-off without affecting the service or remote users.
The newest version of Silverlight (the version that ships with Visual Studio 2010) allows what Microsoft terms the "Out Of Browser Experience" (OOB for short).
This allows the user to set up the Silverlight application as a desktop application as well as running through a browser.
Rudi Grobbler has just blogged about how he went about setting this up on his PC.
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.