I need to launch or run an windows exe file from a OEM in Win store App.
can below be used? I try but have error but why since diagnostic is in the framework
using System.Diagnostics;
Process myProcess = new Process();
try
{
myProcess.StartInfo.UseShellExecute = false;
// here I point to the OEM windows exe file
myProcess.StartInfo.FileName = "C:\\HelloWorld.exe";
myProcess.StartInfo.CreateNoWindow = true;
myProcess.Start();
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
-- Update
# Michal :
Thank you. This method works using URI.
One problem :
the WinRT app goes into background after launching. How to make the winRT app not going background?
Is there any other way? I need to integrate the Exe from the OEM into Win Store App.
Note:
I want to know is this can be done or I am doing something which is not allowed?
If I didnot make my case clearer, please tell me what I miss.
I tried it but it did not work. So my solution should be using similar approach like Diagnostic but what it can be?
Recycling bits from https://social.msdn.microsoft.com/Forums/windowsapps/en-US/0a822355-909f-44b4-9c79-cb986087fe27/after-launching-or-activate-an-app-the-main-app-goes-into-background?forum=winappswithcsharp
This is expected behavior and there's no good way around it. Launching a file or protocol switches to the default handler with no expectation of return.
Launching an app via protocol like this a hack in the first place. Since you are a side-loaded app look into writing a Brokered Windows Runtime Component to allow proper use of desktop API and communication with a desktop back-end.
See the Brokered Windows Runtime Component docs at http://msdn.microsoft.com/en-us/library/windows/apps/dn630195.aspx
Related
I'm playing with Microsoft's UWP AppServiceBridgeSample (here).
It is working well, but I would like to get rid of the console window of the BackgroundProcess application. The reason for this is that my BackgroundProcess starts another Win32 desktop application and works only as a mediator, so I don't want to disturb users with a console window. (Yes, it can be minimized, but I would rather not show it at all).
I have tried to hide it using the API mentioned here, but with no luck, the console window is still visible. Neither did switching the project's output type from Console Application to Windows Application.work.
Another thing I have tried was to create other BackgroundProcess project as a Windows application. It runs fine until I call AppServiceConnection.OpenAsync(), which causes the BackgroundProcess application to exitstrong text, thus the connection to UWA is not available.
static async void ThreadProc()
{
try
{
AppServiceConnection connection = new AppServiceConnection();
connection.AppServiceName = "CommunicationService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
AppServiceConnectionStatus status = await connection.OpenAsync();
//status check etc. ...
}
catch(Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
It seems that opening the AppService connection is only possible from a console app.
So here are my two questions:
Is it, by any chance, even possible to hide the background process' console window?
Can I use the background process as a Windows application, without AppServiceConnection failing during OpenAsync calls?
Re 1: Go into the project settings and change the output type from Console to Windows app. Also make sure the Main() function doesn't exit until you are done with the background process. Here is a better sample that shows this with a Windows Application:
https://stefanwick.com/2017/05/26/uwp-calling-office-interop-apis/
Re 2: AppServiceConnection works the same way from a windowed application as well. Make sure you add the right reference to the Windows.winmd to be able to build. If you have trouble with that, please post a specific question with details of the problem you are seeing
link app with windows process so that when user terminated or end the process it says used by another process and also need to insert it into system file like shutdown file using c sharp so that my app never end or terminates
i tried that material but not usefull
this.ShowInTaskbar = false;
I also tried that code in click:
WindowsImpersonationContext ctx = null;
if (!WindowsIdentity.GetCurrent().IsSystem)
{
ctx = WindowsIdentity.Impersonate(System.IntPtr.Zero);
}
string thisuser = WindowsIdentity.GetCurrent().Name;
But have a look at image it is still present in process, what I want is that my process never stops.
what I want is that my process never stops.
To ensure that your process is always running and is started when Windows boots it's easiest to create a windows service instead. It will probably still show up somewhere in task manager and could be killed manually by the user. But windows will try to keep it running.
How to create a service:
https://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx
And if you need other programs to communicate with your service I find it easy to use a WCF service instead.
https://msdn.microsoft.com/en-us/library/bb386386.aspx
I am creating a complex service on Windows 7, which starts off by loading an .exe application. The only way to achieve this was to enable to "Interactive Services Detection" service in services.msc.
As a test application, I added the following code which simply opens the system calculator. It works, however not as intended. I first get the following message when starting the service:
When clicking "View this message", it loads the calculator as it is supposed to, but opens a blue full screen mode, and contains the calculator within it.
My question is basically the following: How can I make the application display automatically, and not have to prompt the user to "view the message", and more importantly, how can I get the application to display normally, rather than in this "interactive services detection" sandbox?
This is the code of my sample service:
public partial class OpenCalculator : ServiceBase
{
public Process process;
public OpenCalculator()
{
this.ServiceName = "Open Calculator";
InitializeComponent();
}
protected override void OnStart(string[] args)
{
start_calc();
}
protected override void OnStop()
{
process.Kill();
}
protected void start_calc()
{
try
{
process = new Process();
process.StartInfo.FileName = #"C:\Windows\system32\calc.exe";
process.StartInfo.CreateNoWindow = true;
process.StartInfo.ErrorDialog = false;
process.StartInfo.RedirectStandardError = true;
process.StartInfo.RedirectStandardInput = true;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.UseShellExecute = false;
process.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
process.Start();
using (StreamWriter writer = File.AppendText("C:\\Users\\scaruana\\Desktop\\test.txt"))
{
writer.WriteLine(process);
}
}
catch (Exception ex)
{
using (StreamWriter writer = File.AppendText("C:\\Users\\scaruana\\Desktop\\test.txt"))
{
writer.WriteLine(ex.Message);
}
}
}
}
Services run in session 0, whose desktop you cannot see. Interactive desktops are hosted in other sessions. So, for instance, the first interactive logon runs in session 1. This means that services cannot directly show UI on an interactive desktop.
In older versions of Windows (XP and earlier), the first interactive logon shared session 0 with services. And so when you enabled the allow service to interact with desktop option in the service control manager, the service could show UI on an interactive desktop. However, all that ended with Vista because it was a security risk.
So, you need to start a new process and specifically force it onto the desktop of an logged in interactive user. That is not easy to do. This MSDN blog article covers your options: Launching an interactive process from Windows Service in Windows Vista and later.
Now, that's how you go about starting a new process from a service, and putting the new process onto an interactive desktop. But that is almost certainly the wrong way to solve your problem. As you can see by reading the linked article, doing it that way is complex. The standard solution to your problem is to run an interactive process on the logged in user's desktop. This remains hidden until your service needs to show UI. The service then communicates with the desktop app using your preferred IPC mechanism, and then the desktop app shows the UI.
This question has been the cause of great frustration, and I have finally solved my problem. Yes, I have managed to make a service load a GUI application, even though everyone says that it is impossible. There is a warning though - the "fix" can be considered as exploiting a loophole in Windows, as the code which I used basically passes the Vista and Windows 7 UAC. Essentially, the application is always executed with full rights and bypasses the UAC.
If anyone has this same problem, what you need to do is iterate through a list of logged in users on the PC, and choose to open the UI application in this session (which has the user's desktop), rather than in session 0 where the service is supposed to be running (and which does not have a desktop).
For some people, this might not be a solution as it is not secure. But in my case, security is not a main concern, and I just needed it to work (had to be a service by force).
Hope this helps anyone who has the same problem that I had.
I need to start an application from another application. It looks like I have to use the shell to do it (since I need to be able to close the launcher), but I also would like to downgrade the rights given to the launching application.
Is this possible? The launcher must run as administrator, but I'd like to have the launching application run as user.
this is how I currently run the process:
Process process = new Process();
process.StartInfo = new ProcessStartInfo();
process.StartInfo.FileName = name;
process.Start();
Forgive me I forgot to add a couple of details:
I need to run it in .net 3.5 on mono
I'd prefer to not use native code
I need to run the launcher application in admin mode
This seems to be have discussed before, check this out: How do you de-elevate privileges for a child process
Looks like an UAC elevation is strictly one-way, so the solutions are a bit gnarly, i.e. code injection into explorer and stuff like that.
http://www.codeproject.com/Articles/18946/High-elevation-can-be-bad-for-your-application-How
Eventually I decided to create a bootstrapper that could run the launcher as administrator, but then the application as normal user. Once the launcher is done it goes back to the bootstrap executable which launches the application.
Is it possible to embed a DOS console in a Windows Form or User Control in C# 2.0?
We have a legacy DOS product that my Windows app has to interact with, and it's been requested that an instance of the legacy product should run within the Windows application.
At the moment, I'm using the user32.dll to locate the window that the DOS product is running in, minimising then maximising the window, and typing characters into the window. This isn't a very good solution to the problem, as it means my application has to store the window name in application settings, and requires that the user returns to the correct page of the DOS app before using the interaction function.
EDIT: Some more information
The legacy app needs to be visible to the user, but not in a separate window.
I've tried TimothyP's answer and it works very well, but is it possible to achieve the same functionality, but with the DOS window visually embedded in a windows form or user control instead of popping up in it's own window? Preferably in a ShowDialog() way so that the user cannot interact with the app wile they are in 'Legacy Mode', so to speak.
It's possible to redirect the standard input/output of console/dos applications using the Process class. It might look something like this:
var processStartInfo = new ProcessStartInfo("someoldapp.exe", "-p someparameters");
processStartInfo.UseShellExecute = false;
processStartInfo.ErrorDialog = false;
processStartInfo.RedirectStandardError = true;
processStartInfo.RedirectStandardInput = true;
processStartInfo.RedirectStandardOutput = true;
processStartInfo.CreateNoWindow = true;
Process process = new Process();
process.StartInfo = processStartInfo;
bool processStarted = process.Start();
StreamWriter inputWriter = process.StandardInput;
StreamReader outputReader = process.StandardOutput;
StreamReader errorReader = process.StandardError;
process.WaitForExit();
You can now use the streams to interact with the application.
By setting processStartInfo.CreateNoWindow to true the original application will be hidden.
I hope this helps.
Concerning your question on how to display the DOS app inside the Windows app.
There are a few solutions.
The first one is to simply not display the DOS app (with CreateNoWindow)
and "simulate" the UI of the DOS app in your Windows application by reading and writing to the streams.
The other solution would be to use the Win32API, get the Windows Handle (Whnd) of the Console/DOS application window and set its parent to your form. I'm currently not at home
and since it has been ages since I've done this, I can't remember by heart how it is done. If I'm not mistaken you'll need to use the following Win32 API calls:
FindWindow
GetWindow
SetParent
If I have some time left later today, I'll see if I can find better samples.
You can use the CreateProcess function and the hStdInput, Output, and Error members of the STARTUPINFO argument, this will allow you to intercept standard input and output of the application.