Here is situation:
I have a large collection of videos on a computer, and it will be hooked up to my TV. I would like to make an app to open my videos on my computer from my mobile device (Yes, I know it exists, I am just working on it for fun)
So I have setup a web service, and an app to consume said webservice. The webservice gathers a list of folders/files, and sends them to my device as well as can take in a file path and open it with the default program using System.Diagnostics.Process.Start(path)
When I am using IISExpress, it works fine, but I would like to use IIS. When I use IIS, I open the video file and hear it playing in the background, but it doesn't show up on the monitor. VLC appears in the task manager, and when I kill it, the sound stops.
I'm assuming the issue is the identity under which the app pool is being run, but when I tried to change the identity, it didn't make any difference. If it helps, I am running Windows 8. Does anybody have any thoughts on how I can make the app pool run under my identity, or open the process on the desktop of the active user, rather than open it under the app pool's name?
This is something rather difficult to implement due to Windows session isolation. IIS as well as its worker processes are in session 0, while your logon session is usually > 0. Via native Win32 API it is possible for something in session 0 to launch executable in other sessions, but I don't think it is worth the while.
Please use IIS Express, as it runs in your logon session directly, and don't need to cross the session boundary at all.
With regards to the Process.Start() problem I think in addition to changing the identity of the application pool you also need to go to Services under Administrative Tools and check the box "Allow the service to interact with desktop" under the Log On tab for the World Wide Web Publishing service. I think this has already been addressed in the following question: System.Diagnostics.Process.Start not work from an IIS
Now, if I had to put an app like this together I would try I slightly different approach: in addition to what you have already, I would build a small desktop app that autostarts and sits in the system tray when you log onto your desktop. It will listen for messages from the asp.net application on named pipes or tcp or something similar and start the processes from within the correct user context. That seems a more stable approach, which will also allow you to separate the web server from the desktop where the videos will be played.
Related
I have a ASP.NET MVC app, hosted on IIS on a dedicated server. At some point I need to create a com activex component. I use Interaction.CreateObject from Microsoft.VisualBasic.Interaction for this.
The issue is that this activex component shows some dialogs when starting and waits until they are closed before actually registering as COM component.
I wrote some simple code that closes the windows via Windows API using FindWindowEx etc. and it works on a dev machine when hosted under VS, but it looks like on IIS these windows are never shown even in Windows API and ActiveX component just freezes waiting for dialogs to close that never exist.
I tried:
Using Process.Start and then Interaction.GetObject instead of Interaction.CreateObject
Setting AppPool in IIS to run from a real user identity
Setting Load User Profile to True in IIS
Using https://github.com/mj1856/SimpleImpersonation library to run the code as a user
I also looked in dcomcnfg (and this is my best bet on what I need to do). I thought I need to find my COM component there, and set Identity to specific user - but for some reason the ActiveX COM component I'm running does not exist there. I see "cannot register COM component" in Event Viewer if the component run crashes by timeout (because it waits for dialogs before registering as COM), - so I know AppID, but it does not exist in the list in dcomcnfg. Maybe because the ActiveX is exe, not ocx?
I know IIS is not supposed to run anything with windows, and it of course cannot show them, but I was at least expecting to see them with Windows API and being able to close them, especially given that the component waits for them to be closed, so they exist somewhere. I think I'm missing some clever setup on the server.
I am developing on my local machine (Windows 7), and using IIS 7. I usually create a new website by right clicking on sites -> Add New Site. Then do the usual stuff by pointing to the physical files, and I'd stop all other websites which I didnt need. I could then run the site on port 80 without any binding conflicts.
I then recently started doing some ASP.NET development. When I published from my VS 2010 to local host I could run the website, and it all worked great. I then stopped the site (asp.net) but I couldnt start any of the other sites (not even the default). I am not sure why.
I started to read about App Pools and someone said to remove all the application pools. So I removed all my application pools (except the default app pool), and I also removed all the websites (as they had a red x next to them).
I now cannot start the default site as the restart, start and stop are greyed out. I cannot find out any way to reset the IIS server. One error I have received is;
the object identifier does not represent a valid object iis7
I dont know really know what this means, and when I search for this error it seems that many people have come across this error but in different contexts.
Is there any way to reset IIS so I can build simple websites again? Do I need to uninstall IIS and reInstall?
Uninstall IIS and reinstall would probably be the easiest and fastest way to accomplish this.
Other than that check the event logs see if you can find any clues there.
You'll want to ensure there is a one-to-one relationship between the number of sites & the app pools that host them. If they are 32-bit apps hosted on a 64-bit server, you'll need to enable this property (set it to True) on the app pool you want to use for your site. You'll want to run:
C:\inetpub\AdminScripts>cscript adsutil SET W3SVC/AppPools/Enable32bitapponWin64 1
The .NET Framework obviously needs to be installed, but then the separate step of running the ASP installation command needs to be done (C:\Windows\Microsoft.NET\Framework\v2.0.xxxx\aspnet_regiis.exe -i). If it already is, re-install them - it could be malfunctioning/corrupt.
After all that, I noticed IIS 7 puts on this generic app pool identity account to run the app pool with. I created a service account, gave this account Admin rights just to see if the site would run, and added it onto the app pool as the "Custom account". I no longer get the HTTP 503 error. The account should have the "Log on as a service" and "Log on as a batch job" rights. If it will be using impersonation and going out to a SQL database, the "Impersonate client after authentication" and "Allow log on locally" rights are also needed (hence why I like just giving it admin privileges to see if it works, first).
I am developing an ASP.NET website. The users can open up the web page and work with data when they are online. But I want to make them able to work when they are offline and submit their changes later when they are online again. The offline application must be very simple to run and I don't want to develop a separate windows application for this purpose.
So I want to build an executable that when starts, first starts up a local IIS and then opens the startup page of my website (which is locally available) in the user's browser.
And of course it would be great if this executable can be installed on the user's system along with my website files, IIS and SQL Server Express all in one package.
OK I re-read your question and see that you will have local IIS and local Database installed on all client systems.
So then the solution is very simple.
The Applicaiton (main form)
Create a windows forms application.
Put a WebBrowser control and a StatusStrip control on the form.
Add two string resources named say LocalStartUrl and OnlineStartUrl, which holds the addresses of your local and online website home/startup pages.
On Form_Load, check for online internet connectivity and accordingly launch either LocalStartUrl or OnlineStartUrl in the webbrowser control. You can show messagebox and use the StatusBar to inform the user of the same.
The sync module:
The database sync module runs in the timer/separate thread and synchronizes your local database with online database in the background. It sends any unsaved changes to the server and downloads any missing data from the server to local database. You would need to control the speed of this module so that user doesn't face difficulty browsing other websites or using the application smoothly etc. It should be slow and steady and send/request only small chunks of data at a time.
When in offline mode, it just periodically checks for online connectivity at regular intervals. As soon as an internet connectivity can be found, the user is informed. If they permit, it switches over to online mode. Otherwise the user continues to work offline until the application is closed and launched again.
In online mode, the sync module syncs data to & from the online database. This doesn't affect the user because they are not connected to this database. Instead they are connected to the online website and database.
It will take efforts to streamline this approach, but ultimately it is achievable easily.
This won't be just a single task. It would be a series of task working together in sync.
Your windows application does the following:
Write the offline changes to a disk file/database etc.
Periodically check the online availability of your website/ftp site.
Whenever the website is found to be available, and there are some cached changes, submit the file to the website/ftp site.
Your server does the following:
Whenever a file is recieved, check for its validity and integrity. If found correct, put it in a specific folder.
A service on your server watches the folder and as soon as any file is found there, processes the file(s)
The service moves the file to another folder (backup) after processing.
I have an ASP.NET application on Windows 2008 R2 (.NET Framework 4.0, IIS 7.5) and I want to run a console application when I click a button on a web page. Here is the code:
protected void btnUpdate_Click(object sender, EventArgs e)
{
string fileLocation = #"D:\DTDocs\App_Code\LoadDTDocsXML.exe";
ProcessStartInfo oStartInfo = new ProcessStartInfo();
oStartInfo.FileName = fileLocation;
oStartInfo.UseShellExecute = false;
Process.Start(oStartInfo);
}
When I run ASP.NET application from within Visual Studio 2010 (with its internal IIS), the console application run Ok. But when I run the ASP.NET application outside the VS 2010, I haven't an error but the console application doesn't make his job (it must create an xml file on the disk).
I think the problem is the configuration of IIS 7.5, I don't know exact to which account I must give access rights to the folders involved in my console application.
In IIS 7.5, I set Physical Path Credential for Specific User = my windows account, but that not solve the problem.
Thanks.
Just to add to the other 2 answers - Do you really need to run an exe from your webserver?
I've had to do it in the past and it's almost always the option of last resort - It weakens your security considerably (Now all someone has to do to run executables on your system is find a single flaw in your code) and has a whole host of other problems (the webserver isn't "logged on" to the server so it doesn't have a desktop, impersonation is a real pain in the a$$ to get working properly (assuming you're going to run the executable with different permissions to the webserver), etc.
If there's any other way to accomplish your goal, it'll almost certainly be simpler.
An option we went for was to have a new app with a WCF endpoint that the webserver can communicate with. So, when someone pushes the button, the WS call's our app via WCF and tells it to run various commands. This way, you've got:
Clean seperation between web and console code.
A dodgy console app won't take down the webserver & vice-versa
If the console app is long-running, this allows you to stagger your releases for website/console app so that you don't kill the app mid-execution just because you need up upodate some CSS and publish.
Huge security benefits - web server can't run executables even if compromised.
The WCF app will be able to closely examine requests to decide if they're valid before execution.
Be aware that however you do it, if someone malicious works out what's going on and can kick off the process, they could probably DoS you with almost zero effort - Make sure that this method is locked down TIGHT.
Edit: having read your comments above, I think you're hitting the "desktop" issue. When launching an executable from the server, the app will never be visible to the logged on user as the logged on user's desktop isn't accessible from IIS and vice-versa. This is very similar to the issue of having a GUI on a windows service.
This may also be of interest.
the first problem I see is security/file access. when running from within VS the server and client are the same machine under your credentials. when run in testing/production environment the server and client are physically different machines and IIS will run the website under restricted permissions. therefore there is a very good chance that IIS cannot access the file at D:... because of security.
the next issue is running a console app from the website. console is another form of UI just like html and a WPF. personally I wouldn't execute the console from the web (unless there was no other choice). I would integrate the API into the web application. 2 UIs sharing the same logic.
ASP.NET Dev Server runs under credentials of current user (it's you).
IIS 7.5 runs ASP.NET applications under user specified in application pool settings -- usually ApplicationPoolIdentity (to which you can refer as user "IIS AppPool\[ApplicationPoolName]", when configuring file permissions). You can also change it to "Network Service" (Default value in IIS 7.0).
Please check, which identity is configured for your application pool, and give this user required permissions.
I have a program running on my desktop machine that makes a WCF service available. This is a regular Windows Forms application that I run when logged in as a normal user.
I put the WCF interface in so that I could see the status of the program from an external web page. This works great, I can see the status of the running program and even change things as I see fit.
The only thing I can't do is start the program. If I go to the web page and the program is not running, I'd like to be able to start it. A simple Process.Start(programEXE) doesn't suffice because while the program starts, it is not on the desktop and I can't see it, though it does show up in Task Manager.
I tried creating credentials and launching the program with those credentials, but it exits with a very vague "Program failed to start" error, or starts with my credentials but still doesn't show up on the desktop. In the latter case, I see it in Task Manager under my name, but don't see the actual program.
So, How do I start a program on the server, visible on the desktop of the logged-in user (There's only one user and that user is always logged in)?
Also, what are some things that I can do to ensure that this doesn't become a security hole? One thought I had was to run the launcher.aspx in its own virtual directory, under a userid that only has read permissions to the one directory where program.exe is located, and has no other read or write permissions. Any other suggestions?
Finally, just to be clear: I am not trying to launch anything on the user's computer. Clicking on the "launch program" link should launch a program on the web server and not on the client machine, and that program should be visible to the logged-in user on the server.
I'm almost positive that you can't do that. Your IIS runs as service and does not have a specific desktop environment associated with it. What you're trying to do doesn't really work in the web/server environment.
I'd recommend that you change your win form app to a windows service and then you'd be able to start/stop it via web site. If you enable "interact with desktop" with the windows service then I think you'd be able to have a form.Show() bring the app to the current user's desktop environment.
If you are the only person that needs to run the winform app, then why not just start the app yourself? You state that it'll probably never be used by any computer other than your own computer, so it seems like a complicated method of accessing a local web site to start a local winform app when you could just start the winform app via shortcut.