I have one asp.net simple page, on button click I'm trying to start one process(.net console application) but I'm having access denied exception..
If the process is simple windows applications like notepad.exe, or anything else "not .net assembly" the code works...
The problem only happens when I'm running the code from IIS, but from Visual Studio it works.
Where is the .net console application located?
The 'Access Denied' message indicates that it's probably located somewhere that the user the application pool is running as doesn't have access to.
If you run Internet Information Services Manager (from Control Panel > Administrative Tools) and navigate to Internet Information Services > MACHINE NAME (local computer) > Application Pools in the treeview at the left of the window, you'll see a list of application pools (processes that IIS uses to run your website). Then:
Expand each one in turn until you find the one that has your virtual directory listed underneath it.
Right-click on the one application pool that's the correct one (probably DefaultAppPool) and choose Properties
In the window that appears go to the "Identity" tab
The window will tell you what user the website is running as, you need to make sure that user has permissions to your console application, or, change the user to one that already does.
Related
i write wpf application that can checks for update on my host,
if update is available,it downloads new files and when download completed i start another console application with Process.Start and close my wpf app ,
in my console application ,all downloaded files will replace with orginal files
my problem: when i start my console app with Process.Start in my wpf app,windows show a dialog to confirm allow app to make changes to pc for unknown publisher,if user click no button, an error exception occurred,how can i manage exception?
bellow is my code in wpf app:
(updaterApp.exe is my console app)
System.Diagnostics.Process.Start("UpdaterApp.exe");
this.Close();
There should be several workarounds to make this work properly; however, they will depend on the circumstances.
Will this application only run on your machine?
Will this application be deployed to multiple devices along with the application that is stated to be by an unknown publisher?
The easiest thing to do in this case would be to right click on the application "UpdaterApp.exe" and select properties. Under the general tab there will be an option at the very bottom saying to unblock the application. If you select unblock it should suppress this prompt from coming up anymore. Just be aware that this will only affect the application on your machine. If it needs to be deployed to multiple devices, as long as you make that selection before deployment you should be just fine.
I have a single form application which checks user states continuously via timer. I want to start the same .exe by using process.start("C:\inetpub\wwwroot\mywebapp\Checker\checker.exe") in Web Application. The exe appears in System processes list (not appear in application list in Windows Task Manager) after the code executed but it does nothing. It is not changing the user states nor sending Data to Database. But when I start same .exe manually on double clicking, it start working and it also appears in Windows Task Manager Application list and in Process Lists. The .exe is made with C#.Net and is executed file of C# windows application.
When launched by IIS the process will run under the account that started it, which will be the w3wp processes that is running your web application. Because this isn't your account it won't show up in task manager until you select the "show processes from all users" option. When you run it via a double click it is running under your account, so will be visible.
If the changes and database access rely on using your account to gain access then this wont work when it runs from within IIS. For example, if your database connection is done using "Windows Authentication" then it will try to log in as the IIS account, which is unlikely to work.
To fix this you can launch the processes by specifying a username/password in the ProcessStartInfo structure. However, this will require you to embed your password somewhere, which may not be desirable. Alternativly look at changing the database connection string so that you specify the logon credentials explicitly.
Basically, I have an application that is installed on the users computers.
The users are on Windows 7.
The users are NOT given admin access.
The application, however, needs to be able to save files to its own Program Files directory.
The path I wanted to take was:
Download various binaries (web service).
Write binary to files in temporary folder.
Launch a console app. (Console App waits for the main app to shutdown)
Console App copies the temporary files to the Program Files directory.
Console App relaunches the main app.
Console App shuts down.
The problem is that I know Windows 7 does not allow applications that are not running as administrator to write to the Program Files directory, and I understand why (for security), but since I am writing this app myself, installing it on the machines myself, is there any way to make my app be able to write to whichever directory it resides in (platform independent because it uses relative paths) without having a popup box ask to run the app as admin? Can't the app be signed to ALWAYS run as admin?
In fact, I don't even need the main application to be the one that runs with administrative access. I need the console-app (the one that copies the temporary files) to be able to copy those temporary files as permanent files.
Update: Yes, this is for an auto-updating application. I thought about ClickOnce and the such, but there are additional requirements which lead me to create my own internal updating, mainly because the updates need to be silent and piece by piece. Sometimes (depending on the pieces updated) the application needs to shutdown, move the files in, restart. Other times the application simply needs to move the files in and continue running.
ClickOnce just didn't work for my situation, and our organization was looking for something in-house so it can be customized to fit our future needs.
As the comments already pointed out: ProgramFiles is inaccessible if you have a somewhat recent version of Windows (Vista+), UAC enabled (the default) and non-admin users.
Your updated question says that you need to update (at least parts of) your application and that might need a restart. You created your own way to update the modules.
My suggestion is the following: Don't write to ProgramFiles
Either install your application completely to the user profile or split it up.
I'd try to create an executable that does very litte:
Sets up shadowing so that assemblies are not locked
Look up an assembly in a writable location (ProgramData or in the user profile) and load it
Run the app from there
In case of an update you can overwrite your assemblies (since they are shadowed and stored in a sensible location) and, if necessary, stop the program/ask the user to relaunch/implement a restart mechanism. You shouldn't need administrative privileges for this.
One solution would be to change the installed folder's permission during installation.
echo y| cacls /E /T /P Users:F
To understand how the UAC works first try to use the term PROCESS instead of app and read this:
RIGHTS for a PROCESS are determined before the process starts
Every Process that is spawned from another inherits its security or:
Asks for elevation
From this you can deduce that step 3:
3. Launch a console app. (Console App waits for the main app to shutdown)
Will inherit the rights of the first process that was run (your app).
At some point you will need to ask for elevation. If that is before your app is run or before running asubprocess, is your choice.
The most user friendly way to do this is to modify folder permissions once at first start or installation. That is a way to not bother the user each time. But some UAC will surely pop to the user at some point.
I found this nice snippet of code online:
rkApp = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Which runs great but alas on windows 7 and vista I suspect, it crashes cause it doesn't have permission to write there.
So then I research (on stackoverflow of course) how to avoid this, quickest method:
rkApp = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Simple enough! Though there is two issues remaining. One is with both methods (on a XP Box that is), the program thinks its relative path is somewhere in the C:\windows folder now...so I.e. it won't find my path relative help files etc. The second issue is, on windows 7, my program won't startup until I log in. I want it to start up in the background if possible before anyone logs in.
Its a simple .exe that hangs out in the systray when its running. I didn't want to create this monstrosity of an installer to get around these admin and pathing issues.
I Think I would have to create it as a service (no clue how to do that) to get it to start up when the machine reboots before anyone logs in. Secondly to do that I am sure I have to figure out the admin privileges, and since I don't want to have to approve the program to run every time it starts up it sounds like I would have to figure out its admin privileges during install time, but alas no installer.
So just curious what routes I might take to get this to work. I can even suffer it coming up only after when the user logs in, but my current methods that work this way really screw up the pathing of my program since it tries to write stuff out to a new directory (not the one I originally started the EXE from). Etc...and I have no clue how to go about fixing that pathing issue.
It sounds like you need two programs here.
You can't have an application run in the system tray and run prior to login. The system tray doesn't "exist" until the user logs in and has a valid desktop.
The normal way to handle this is to make two programs. First, create a windows service that does the bulk of your work. This will run on startup, and be independent of any user logins.
Then, make a user mode application which uses IPC to communicate with the service. This can run on login, and "talk" to the service remotely, thereby providing your system tray requirements.
If you want your program to start as a service before anyone logs on, then it's going to need to be installed and run as an admin user. There's not getting round this fact.
There's a Microsoft Knowledge Base article on creating a service which should get you started.
There's a project template for a Windows Service installed by default in Visual Studio 2008:
"File > New > Project > Visual C# > Windows > Windows Service"
We have to run a process from a windows service and get a screenshot from it.
We tried the BitBlt and PrintWindow Win32 calls, but both give blank (black) bitmaps.
If we run our code from a normal user process, it works just fine.
Is this something that is even possible? Or could there be another method to try?
Things we tried:
Windows service running as Local System, runs process as Local System -> screenshot fails
Windows service running as Administrator, runs process as Administrator -> screenshot fails.
Windows application running as user XYZ, runs a process as XYZ -> screenshot works with both BitBlt or PrintWindow.
Tried checking "Allow service to interact with desktop" from Local System
We also noticed that PrintWindow works better for our case, it works if the window is behind another window.
For other requirements, both the parent and child processes must be under the same user. We can't really use impersonation from one process to another.
Currently i can't find the corresponding links, but the problem is, that a windows service runs in another session than a normal user application.
In XP this was not fully true. Here are all services started in Session 0 and the first user who logs into the system will also run in Session 0. So in that case, tricks like Allow service to interact with desktop work. But if you fast switch to another user he gets the Session 1 and has no chance to interact with the service directly. This is also true if you connect through RDP to a server version (like 2003 or 2008). These logins will also start in a session higher than 0.
Last but not least there is another drawback by using the interaction with the desktop:
If you enable this option and your service is running under the (default) SYSTEM account it won't be able to create a network connection anymore.
The correct way to get a custom GUI that works with a service is to separate them into two processes and do some kind of IPC (inter process communication). So the service will startup when the machine comes up and a GUI application will be started in the user session. In that case the GUI can create a screenshot, send it to the service and the service can do with it, whatever you like.
Have you tried to run as Local System with the "Allow service to interact with desktop" checked?
I don't think this is possible.
We had to change our scenario where our application wasn't started from a service, but was a standard windows program that has a NotifyIcon in the corner.
If someone still finds a real answer, let me know.
It works using Local System with the "Allow service to interact with desktop"
You can set it programatically using this sample code:
http://www.vbforums.com/showthread.php?t=367177 (it's vb.net but very simple)