We Keep Coding

Are apps launched by URI in a UWP app also sandboxed?

I inherited a UWP app and was asked to add a button to launch a 3rd party application. The 3rd party application is built with Qt and has an exe as the main program that launches a second exe that acts as a service. The UWP app is to be run on tablets running Windows 10.
I created an installer that adds registry values for the URI for the 3rd party application so I can do URI activation (LaunchUriAsync method). If I change the target of the URI to a different application it works fine, so I know the URI is setup properly.
When I hit the button the 3rd party application does not open. I used ProcMon to see what was happening and confirmed that it begins opening but then stops before launching the second exe. Nothing is written to the event log because that would be too helpful.
I haven't found any documentation about this, but I have to assume that an application launched from a UWP app is also sandboxed. Does anyone know if this is correct? I'm not sure what to do other than rebuild the app as WPF or something and that isn't very appealing.

The answer to your question is: no, that they are not being run sandboxed.
Launching an app that runs in fulltrust from a UWP via protocol is a supported scenario (e.g. that's how composing email works if Outlook is your default mailto: provider).
I suspect that is something missing in your protocol registration, or how you invoke it, but there is not enough detail in the question to troubleshoot this.

I was able to launch my 3rd party application by making a new console application for the UWP to launch that then starts a new process for it.
Console app is just this:
var proc = new Process();
proc.StartInfo.FileName = filePath;
proc.StartInfo.WorkingDirectory = Path.GetDirectoryName(filePath);
proc.Start();
proc.WaitForExit();
var exitCode = proc.ExitCode;
proc.Close();
The "WorkingDirectory" was required and from the UWP I don't see a way to set that.

IIS7 does not start my Exe file by Process Start but it's running in task bar

I have created a project with process start in c# it's running in local visual studio build,when I hosting it in IIS it's not running but it's starting the processes and nothing is displaying I checked it in task manager.Code sample:
Process process = new Process();
process.StartInfo.FileName = "calc.exe";
process.StartInfo.UseShellExecute = false;
process.Start()process.WaitForExit();
And I have tried following solutions
IIS7 does not start my Exe file by Process Start
Foo.cmd won't output lines in process
System.Diagnostics.Process.Start not work from an IIS
nothing helped.If any one knows please help me

Try setting the value of the Load User profile to True for the ApplicationPool that you are using for your application.
You can just select the application pool and select advanced settings under advanced setting you can find this option.
This worked for me.
ApplicationPool Settings screen shot
EDIT : but as spender said it is not advisable to launch an EXE from your IIS server as this may open up some way for hackers to attack on your application.

I have searched a lot and finally I find a solution,It my be helpful to some one.
Solution :
Asp.net with IIS runs as a service application, which means that it runs under another Window Station and Desktop. However, in Windows, the default visible Window Station and Desktop is WinSta0\Default, which is where the Shell(explorer.exe) runs. So the .exe you created is displayed in an invisible desktop.
Actually, Window Station and Desktop is a good sandbox for GUI security, since Windows do not want the normal GUI application to communication other Services applications through Windows Message.
To display the GUI from a non-visible service application, you have to break the security sandbox of WinSta0\Default, which is a little complex.
However, if you want to create a visible process, it is really hard. Normally, the recommended solution is creating a second GUI application like Winform, and the Asp.net and Winform can communicates through .Net Remoting or other Inter process communication technologies. When the Asp.net wanted to create the visible notepad process, it can tell the Winform client through Net Remoting, then Winform will simply Proces.Start notepad.exe on behalf of Asp.net process.
.Net Remoting is the solution to solve this problem
(refer this link .NET Remoting with an easy example )
Download sample from Click Here

What is the best way to keep a C# Console app running [duplicate]

This question already has answers here:
How to keep a .NET console app running?
(9 answers)
Closed 6 years ago.
I have developed a console app which must run in the background. The app must constantly check a database for new records. If new records are returned they are processed. My app as it currently stands uses while(true) to keep the application running. Is using a while loop the best solution.
A snippet of my code:
static void Main(string[] args)
{
while(true)
{
// Query db for new records
if(record_count > 0)
{
// Process the records
}
Thread.Sleep(500);
}
}

Create as Windows Service Application
What a Windows Service is ?
Enables you to create long-running executable applications that run in their own windows session.
Can be automatically started when the computer boots, can be paused and restarted without any user interaction.
Easily installable by running the command line utility InstallUtil.exe and passing the path to the service's executable file.
Why a Windows Service?
One of the most common requirements of some businesses is long-running scheduled jobs based on some time interval. For example: sending a newsletter everyday afternoon or send an email alert to the customer for every one hour.
So building a Windows Service could be one of the reliable solutions to do the goal that can do the required job in the behind the scenes without interfering others users on the same computer.
Please refer the link for step by step implementation -
http://www.c-sharpcorner.com/UploadFile/naresh.avari/develop-and-install-a-windows-service-in-C-Sharp/

Your approach to keep your console application continuously running is absolutely fine. Only thing is that you want to keep it running in background silently without user to know anything. Since a console app has a windowed UI (a command console) the user will keep seeing it. Here is what you can do to get rid of command console. Since you already have your console application with you, here is what you need to do :
Go to project properties -> Go to application Tab -> Change the Output type to Windows Application
Phew! Now your same console application will run without a command console and your code will keep running.
Creating a windows service will be too much of a kill for such a simple logic. Also installing a windows service is an extra overhead, though I am not aware of the deployment you are looking forward to for your application in production.

Better option would be to use Windows service that run in background.
Creating a Windows Service Application
Develop and Install a Windows Service in C#
Just google and you can find lots of article and tutorial on Windows Service.

There is no need to make your program running as a services. Services aren't for these small tasks. You should simply create a Windows (GUI, WinForms) application with a hidden window. Or, just don't create a window and just keep the Main running. Main would launch a thread and would itself wait for that thread.
A service has to be installed as a service and not all users would have permission to do that. It is complex task to have service, manage it, have security attributes settled et. al.
The hidden application can simply run in current user account (the service would be running in high-privilege SYSTEM or NETWORK account). Your application won't demand any privilege from current user - it just need SQL database/table read access.

Create a windows service which will check if your console app is running. If console app is down, then windows service will execute it again.
Don't write your console app's code into windows service. Because if it will start automatically at windows start up, then it may not work correctly as your console app.

Launch program under interactive logon user from .NET WinService

At the moment we have .NET WinService started under LocalService user at windows start. The service launch another WinForms Application using Process.Start().
But there are several problems in this solution:
We don't wait for an interactive user logon and the Application falls because it tries and fails to initialize DirectX device.
Application launched under LocalService perfectly interacts with user desktop in Windows XP. But it doesn't work in Windows 7 because of there are different graphic stations for each user in win7.
Sometimes we need to run application with current interactive logon user rights.
Does anybody know how to wait for user interactive logon in the service and start WinForms Application with these user rights?
I think this helps to solve all problems.

You will need a separate client app. Check out this document, page 6: http://msdn.microsoft.com/en-us/windows/hardware/gg463353.aspx.
For your monitoring/restart scenario look at CreateProcessAsUser as mentioned in the document. You will almost certainly need to have your client app coordinate with the service for this, and it's still pushing a square peg into a round hole.

I would try using a combination of the answers above.
To solve #1
At user logon, launch the Winforms application using autostart in registry or startup folder. Make it notify the service that it was started successfully.
To make sure that the Winform app is started successfully after user log on:
Have your service that checks if application is started running in the background as you have now but don't let it do the initial startup.
Instead just let it register when user logs on, should be possible to do by listening to OnSessionChange.
Set a delay for X number of seconds to allow the login/startup process finish before it starts checking for a running application (ok maybe not the best solution).
If the service discovers that the application is not started or crashes, restart it from the service using the method Mark points out, CreateProcessAsUser.

Is it possible that this just isn't the right approach for what you're trying to do? It seems possible that you'd be better off putting the monitoring logic or whatever has the uptime requirements into the service so that it's "always on" so to speak. Then you would be left with UI logic in the WinForms app, which could be open or closed with no ill effect.

invoke exe(with GUI) on remote machine

can we invoke exe of application(made in .net) on remote server using local machine.
we have full credentail on all machine to execute process.
how can we achive that ?its require to open GUI on remote machine.
we tried using WMI/.dat file invoke but all opens process on Task Manager & could not lunch GUI..
anyone have idea to accomplish same??

You can use psexec for this.
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

At one point in time, you could write a Windows Service, run it under the local system account, and allow it to interact with the desktop. However, this will only work on Windows XP. Vista (and I assume Windows 7) show the UAC prompt first, which is annoying and sometimes only shows up on the taskbar until it's clicked.
We got around this by writing a WinForms app that had no visibility on its own, but this app watches for a trigger. When the trigger occurs, the program then launches the appropriate exe.
For example, the trigger may specify to open up a web page on our intra net. The program uses the System.Diagnostics.Process.tart() to launch the web page in the default browser.
The trigger can be one of many things... The exe can poll a database, web service, etc. The exe can host a WCF host use remoting, or it could use a FileSystemWatcher.
The most complicated part of writing such an app is figuring out the appropriate trigger. Launching the app is trivial using the System.Diagnostics.Process.
For our situation, we set the program up to just launch when Windows starts, USG a registry setting.

Use PsExec tools
with -i switch
Like
psexec \\remotecomputer -u username -p password -i 2 "your exe loacation"