Develop Reference

Open application from Universal Windows(UWP)

So for our project, we have this app that's in the Windows Store. It is a Unity UWP app. At some point, we want to check if program X is installed on the user's machine. If yes, we want to launch it, if no we want to provide the user with a download link (or whatever.)
The app we want to launch, however, is a Unity standalone app. The user can download it from our website.
I tried multiple things. PlayerPrefs, Register checking etc. None of these really work. Register checking turned out to work decently well, but that only works between standalone apps. UWP apps seem to have no access to the Register.
Which left me thinking about URIs etc. But, I'm a complete noob regarding all of this and I have no clue how or where to start. Any help or direction is highly appreciated.
Ideal scenario:
User downloads our app from the Windows Store
Users click a button within our app
Our app checks the user's system for App X
If App X is installed, we launch it, if not we do something else
App X opens.

The UWP app cannot interact with the standalone Unity app directly.
You can write another standalone desktop “helper” app that does the actual work of checking the registry and launching the Unity app, and then make this “helper” app part of the UWP package and resubmit the package to the Windows Store.
Keep the “helper” app as simple as possible so it doesn’t have other dependencies.
Use FullTrustProcessLauncher to launch the helper app when the user clicks the button.
And the UWP app needs to have runFullTrust capability in order to use FullTrustProcessLauncher.
runFullTrust is a restricted capacity and when you submit the app to the Windows Store it is required for you to specify the reason why the capacity is necessary for your app. See this answer for more details.

UWP app start automatically at startup

All is in the title, I currently searching a way to launch my UWP app automatically at Windows startup with the UWP framework only, no file manipulation on the machine. The application must be able to be shared on the Store AND open when Windows starts.
Is it a feasible thing? If so how?
Thank you!

#hsmiths wrote easist solution to start app automatically and I'd like to summarize in step by step.
Open File Explorer
In address bar, copy-and-paste shell:AppsFolder
Right-click the app and then click Create Shorcut.
The message box asks to create shorcut on the Desktop. Click Yes.
In File Explorer address bar, copy-and-paste shell:startup
Go to Desktop and copy-and-paste shorcut to File Explorer.
Reboot your computer if you want to test.
+Tip: if you want to by-pass login dialog on Windows startup.
Start > Run
type control userpasswords2
User Accounts window will be opened. Uncheck Users must enter a user name ...
When you click OK, you will be asked to enter account password. Type password.
Reboot your computer if you want to test.

It seems that MS will add this feature - windows.startupTask - not only for converted desktop apps, but also UWP apps.
You can see it from about 37:00
Tip, tricks, and secrets: Building a great UWP app for PC
But this feature is not ready yet - It'll be available with Windows 10 Fall Creators Update.(I've tried with SDK 16225 but not ready yet)
Added 12/18/2017 - You can do it with Win10 Fall Creators Update.Following post show the details.
Configure your app to start at log-in (Windows Blog)
One consideration point is: By the feature, you can just 'start' the app - the app window is not shown. To see the app window, the user should click the app task at the task bar. It's a slightly ridiculous implementation for me. From the view of customer, 'click to start' and 'click to activate' is same behavior. You can do the some task in background before the user activate the app, but this is an another story.

If it's a desktop application converted to UWP you can declare a startup task in your appmanifest like this:
<desktop:Extension Category="windows.startupTask" Executable="bin\MyStartupTask.exe"
EntryPoint="Windows.FullTrustApplication">
<desktop:StartupTask TaskId="MyStartupTask" Enabled="true" DisplayName="My App Service" />
</desktop:Extension>
See Converted desktop app extensions

You can on Windows 10 (I'm not sure about Windows 8 or earlier versions), here's the instructions from Microsoft:
https://learn.microsoft.com/en-us/windows/uwp/launch-resume/create-and-register-a-background-task
Even in Windows 10 IoT you can set an app to autostart through a PS command:
[192.168.0.243]: PS C:\> iotstartup list MyBackgroundApp

You can create a .bat script that execute "start AppID!App"
"AppID!App" string is available in shell:AppsFolder view, you have to add the given column.
Then place the .bat file in the startup folder:
"shell:startup" for the given user,
"c:\windows\system32\GroupPolicy\User\Scripts\Logon" for all the users of the given computer

I think that is not possible, but maybe you can use a trigger in order to activating a background task when something happen..
Here's a list of the available triggers:
SystemTrigger
MaintenanceTrigger
TimeTrigger
PushNotificationTrigger
NetworkOperatorNotificationTrigger
NetworkOperatorHotspotAuthenticationTrigger
However you have some constraint.. take a look here: http://blogs.msdn.com/b/windowsappdev/archive/2012/05/24/being-productive-in-the-background-background-tasks.aspx

process start on dll in c# [duplicate]

I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?

Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...

The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.

WTSEnumerateSessions and CreateProcessAsUser.

Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.

That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7

On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.

I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...

If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.

Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx

How to have a program screenshot itself when ran as a windows service? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Screenshot of process under Windows Service
I am attempting to more or less emulate Infopath Form Services. So I want to be able to approve or disapprove forms via mobile devices (users will be notified via email). I have the ability to approve/disapprove forms, but the problem is that I need the ability to take screen shots of my program for detailed error reporting (in case something goes wrong during the approval process) (the screen shot process is implemented already). I need the ability to run the program on the server without any user logged in. That is where the problem comes in. If I run my program as a service, I dont get an interactive window, but I get the ability to have my program always run. So I need to be able to launch the program when the computer boots, and have it be able to screenshot itself.
Is there any way to have a windows service have an interactive window at boot, even if its drawn off screen and can never been seen by users, or a way to emulate/fake a window to my program so it can screenshot itself without actually needing an interactive window?
Also, my program is written on the .NET framework in c#

In addition to the fact the service have no desktop to render...
We did not implement rendering of InfoPath forms on the server the way you try because it simply will not work correctly. You can cheat for some time, but running an Office application in headless service mode on a server is simply bad idea. You will also run into interesting issues because user's identity will not match process identity (i.e. can't query ACL'ed data).
You options:
Drop InfoPath portion if you just need approval.
Go with existing solution for mobile forms. There is some support for mobile forms in Forms Services, and you can have very simple views specially for mobile devices if it works. There are also existing solutions for mobile rendering of InfoPath forms.
honestly implement rendering of forms. The XSN format is documented...
Render InfoPath on separate machines with logged on user one per user at a time...

c# make a connection between a windows service and a c# project

I have a c# project that prints or take some values from the keyboard to a console application. Can someone tell me how could I start this application from a windows service? I mean..when the computer is turned on I would like to pop up on my desktop the console application in which i can write values and see the result? Need some help. Please print a little code if you have one. Thx!

You just put the shortcut of the application in the Startup folder and it'll work. This is the simplest way, no code change needed

Windows Services usually run non-interactive under a specific system account rather than a desktop user account.
If you want the program to start when a user logs on you can always put a registry key in:
HKLM\Software\Microsoft\Windows\Run
And it will start when a user logs on.