I'm working on creating custom Cortana commands. The commands are registered and executed using a Universal Windows Platform Application. (GitHub)
For instance, I've registered the following command
<Command Name="ShutDown">
<ListenFor>Shut down</ListenFor>
<Navigate/>
</Command>
To run this function in a UWP application
static async void ShutDown()
{
var dialog = new MessageDialog("This is where I would shut the computer down.");
await dialog.ShowAsync();
//System.Diagnostics.Process.Start("Shutdown", "-s -t 10");
}
But after setting this up I learned System.Diagnostics.Process isn't supported in UWP.
The custom commands I want to run involve some sort of execution such as launching external programs, running other scripts, or opening websites.
It makes sense that UWP doesn't support them given that it's universal and an XBox or a phone might not be able to do these, but I was hoping there was some alternative or hacky way to accomplish this on a Windows 10 PC.
Is there a way for me to execute Process commands or something else with similar functionality in a UWP application? It seems like even though I can get Cortana to execute my C# code, UWP doesn't support much that would be useful in this situation.
Thanks in advance.
There are - limited - ways to achieve similar behavior.
You could use LaunchUri to trigger other apps which registered for a certain URI-Scheme. This should work for your webbrowser scenario. More details here:
https://msdn.microsoft.com/en-us/library/windows/apps/windows.system.launcher.launchuriasync.aspx
You could trigger another app and get results back from it using LaunchForResults. The called app has to support this. More details here:
https://msdn.microsoft.com/en-us/library/windows/apps/mt269386.aspx
You could trigger App Services provided by another app. The called app has to support this. The app service will be executed in background. ( I think this is pretty cool.) More details here:http://blogs.msdn.com/b/mvpawardprogram/archive/2015/06/11/writing-windows-10-app-services-in-javascript.aspx
This is a little hacky: I'm not sure if this still works but it did work for Windows 8.1: You could create a so called "Brokered Component". This allows you to trigger everything from you app on you machine, but you won't be able to publish a brokered component into the store. This also allowed Process.Start() on Windows 8.1. It only worked for sideloaded apps. I'm not sure if it still works on Windows 10.
More info here: https://msdn.microsoft.com/en-us/library/windows/apps/dn630195.aspx
Summary:
Starting another app is pretty easy as long as the target app registered as app service or registered a protocol handler (Uri scheme).
Starting scripts or other *.exe is impossible if option 4 doesn't work any longer.
With the Windows 10 Anniversary Update (1607) there is an option to enable this scenario on PC. With this API in the Desktop Extension SDK you can launch a fulltrust process that runs at the full user privileges:
https://learn.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.FullTrustProcessLauncher
This way you can light it up on the platforms where it is supported, i.e. PCs running 1607 or above. And your app will still be universal:
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}
i have a project this year wherein i need to connect windows phone to pc through a wifi connection and perform basic synchronization operation. . .
being new to this application development i have no idea where to start
the problem i am facing is
which protocol and service should i use .
i just want to know a basic code to establish connectivity between emulator and computer and transfer a simple message or something else...
i searched many sites but couldn't find a simple connectivity code.
i am using Microsoft Visual Studio 2010 Express for windows phone
But there are several ways to pull data from within an application to the phone:
Webservices, you create a web service and your application calls the webservice (sample)
Socket based (for example UDP)
If you want to do something without your app running (not being visible to the user) then you might have a look at background tasks. A sample is here. Though you're limited in what can be done in a background task, refer to Microsoft's documentation.
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app
I am trying to start a windows application from a windows Service using the below code
Process.Start(#"filename.exe");
In windows 7 I receive a popup that says, "A program running on this computer is trying to display a message"
You cannot start an interactive application from a Windows Service. This was changed in Windows Vista and 7.
Some other advice was given in this Stack Overflow answer on the same subject.
When I've needed to do this, I had to change my Windows Service to a Console Application, and invoked it in that manner.
A work-around I found for this issue was to use the windows task scheduler. You can schedule the application to run some amount of seconds later by creating a batch file.
At my previous company we had this issue and we wrote a console app that ran in the sys tray and acted as a bridge from the service to the desktop. Basically via remoting (I'd use WCF now of course) we let the service request that the console app start up another application.
I have window XP 2003 server, which is placed in a room where no one can enter to logon it.
for monitoring some applications
I created a console application myServer.exe, which dont have any UI,
I want that this application (e.g., myServer.exe) start automatically as window bootup (e.g., before window logon)
and I need to do this work using windows service.
(note: please don't suggest me any other solution, I need to use windows service to accomplish this task)
The WinNT resource kit includes a utility called SRVANY.EXE that can be used to run any application as a service. ocdecio's solution is better but if for some reason you can't redesign the app SRVANY.EXE may work. Here's the KB Article.
You can develop Windows services directly in C#. If you have Visual Studio Professional, there is a built-in project template for a Windows service.
MSDN has a walkthrough of creating a service with C# that explains the process clearly.
If you don't have Visual Studio Professional, you can still create a service. You'll just need to create a class that inherits from System.ServiceProcess.ServiceBase manually.
A quick Google search turned up a couple of other links that may be helpful to you:
http://www.codeproject.com/KB/system/WindowsService.aspx
http://www.c-sharpcorner.com/UploadFile/mahesh/window_service11262005045007AM/window_service.aspx