I would like to download a file to the DownloadsFolder in a Windows Store App. And then I'd like to bring up a Windows Explorer open on the DownloadsFolder (actually on the folder I create in the DownloadsFolder)
But I can't figure out how to do it.
This stackoverflow question Launching a Desktop Application with a Metro-style app suggests using Launcher.LaunchUriAsync. But the documentation claims:
You cannot use this method to launch a URI in the local zone. For example, apps cannot use the file:/// protocol to access files on the local computer. Instead, you must use the Storage APIs to access files.
And indeed, I was trying to use the "file:" protocol to bring up the explorer window. When I did try this mechanism Launcher.LaunchIUriAsync fails.
If the browser can do this, why can't I?
Is there a way for me to bring up windows explorer, or is that outside the real of possibility?
I don't think you can launch the Windows Explorer from metro. One thing you can use, however, is the File Picker.
http://code.msdn.microsoft.com/windowsapps/File-picker-app-extension-0cb95155
If you're willing to have some non-Windows Store components in your solution, there is a workaround for this. Although you can't launch a process directly, you can always run a HTTP listener inside a Windows service which listens for commands from your sandboxed Windows Store (Metro-style) app and launches Explorer (or any other process) for you. A trivial way to do this would be a Web API service inside a Windows service - just implement the GET action in your controller and have arguments for the executable to launch and optionally executable arguments as well.
This is kind of doing an end-run around the sandbox security, though, so you might want to have a tailored Web API instead which just launches a pre-packaged set of apps (like Explorer or one of your own apps).
Of course, for consumer apps this is not a good solution because you can't just install everything from the Windows Store. For LOB apps, though, it's not a bad compromise because you typically have more control over the environment. This is a good way to surface some metrics or other data into a live tile and have your desktop app launch when the tile is clicked. Whether or not this makes for a good user experience is a totally different conversation.
BatRT allows you to run batch file commands from WinRT applications. It utilizes URI calls. This can be used to open up applications or perform file operations.
Related
I have a program where i want to have the ability to launch a local application (for example Spotify) from my UWP App. I have searched the web for a solution as (Process.Start()) doesn't work. As i have understood the UWP applications is kind of sandboxed for saftey and stability reasons. But is there a (simpel) way to work around this.
I only want the ability to start and close a program inside my own frame/Window. No need to interact/send/recive data between my applications and the external program
That is not possible with all apps. Some desktop apps handle protocol launches and that can be a way of launching another app. Spotify actually has a protocol registered so you could do this to launch it:
await Launcher.LaunchUriAsync(new Uri("spotify:"));
I have a program where i want to have the ability to launch a local
application (for example Spotify) from my UWP App.
You can utilize Windows.System.ProcessLauncher API.
Here is a sample about how to launch an external process (exe) from a Universal Windows Platform (UWP) app you can reference.
Make sure add systemManagement capabiity.
For more information reference ProcessLauncher.
I am currently developing an integration between a web app and a windows application, where everything works fine on standard setups. However, introducing Citrix to the equation complicates everything quite a bit.
The current solution
At the moment we have a POC (proof of concept) running with custom Uri Scheme registration to a little exe we have developed, and listing active instances with Global Atom (using this trick to list search all entries). This way, we can see if an instance of our application is running. If it is, we call it via SendMessage, and if not, we start the application in a new process, and wait for it to be ready, for us to call it.
The issues introduced with Citrix
Now, when using Citrix Desktop Sessions, we do not suspect we will run into any issues, but with Application Sessions (AKA XenApp) the Citrix documentation states: "URL redirection works only for desktop sessions, not application sessions.", and we have therefor run into a brick wall with our implementation. So to sum up, we now have issues with accomplishing the following steps:
Registering a custom URI Scheme handler: That might not at all be supported. The way we use it now, it points to an application on disk, but the Application is installed on a server.
Detecting if an instance is running: We do not know if Global Atoms are even possible in this setup, and I have been unable to find any documentation on this.
Calling a XenApp window with SendMessage: When running the simplest XenApp configuration we could reproduce, we can inspect the hosting process and get the handle to our application, but the application never gets the message sent at it.
Solving it within the current solution scope
Can the above scenario be accomplished in a Citrix environment using Application Sessions? If so, how? The tests I have performed so far, appears to confirm my suspicions that it is simply not supported within this setup.
Solving it in similar fassion
The POC we have developed is simple and modular, and changing how instances are located and communicated with is easily implemented and made configureable to our clients specific setup. It will then require other ways of detecting, launching and communiting with the primary application.
Just detecting a running application has proven difficult (another question hat has not yet been answered), and the Global Atoms approach does not seem to work.
Launching the app if it is not running, is something I have pretty much given up on, given how many different ways the app can be distributed in such a setup, so it will probably have to be a requirement that the application is already running.
Even though I can retrieve what the handle is for the mainwindow, I am not able to use SendMessage either in a Citrix setup. It simply does not process the message I am sending at it. Is that also something XenApp does not support? I could not find find any documentation on this. Alternative ideas to call into the hosted application are very welcome.
In the end the solution(s) was extremely simple for our citrix customers, as they could either:
Open our software first, launch a browser window from within (we have various links that opens browsers), and navigation now works flawlessly.
Customize a hosted browser application, to run in the same server environment as our software, and then our POC was able to launch our software as though it was a regular desktop environment.
I need to launch a couple of commands from my WinRT application, like if it were a Command Console, in order to do this, on not WinRT apps the class to be used is System.Diagnostic.Process but on Win RT his class is not available, is there any equivalent class or method that i could use?
Thanks in advance :)
Windows Store Apps cannot launch other processes directly, as Marylin already said. You can only use Launcher.LaunchFileAsync to launch the default application for the file type (file ending) the passed file has. Using this you could define a self-defined file type like .process in Windows and set its handler application to a windowless desktop application you write. The desktop application reads the process file which has the path to the application stored that is to start and launches it using Process.
This trick would certainly fail the certification but may be useful in apps you deploy to businesses skipping the Store.
A problem would be that the Windows Store App is set to the background if a Desktop application is launched. I think this is one reason that Microsoft does not allow it for certified apps.
You cannot do that from a Windows Store application - those are sandboxed and do not have access to other processes. More details here.
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
To summarize, as we all know,
a) Silverlight is expected to be hosted by a browser, and runs in an isolated sandbox so that there won’t be any security issues
Silverlight don’t have direct access
to the file system, other than the
isolated storage area
There is no
direct way to open common dialog
boxes like File Save in Silverlight (Though Opendialog box is supported).
b) Silverlight can’t access local resources like a printer
What are the ways to go beyond the sandbox, so that I can host a Silverlight application locally, to read files and save them back if required, to hand over data to a printer, and so on..
Update:
Is full WPF is not an option for me? No. I'm also interested in a cross platform solution - for instance, you could host Silverlight in Mono Web browser control, so that you can run it virtually anywhere.
The idea is to re-use the same application that I'm building for web in my desktop as well, by providing separation of concerns at some areas - like persistence, resource access etc.
Scenarios:
1- Some kind of gadget container, with access to local resources.
2 - A desktop Silver light based media application
Update:
I just did a POC to enable me to access printer and save files locally, of course through a shell where I'm hosting my Silverlight application. If you wan't you can have a look at the post here in my blog
Two ways I can think about is,
Create a "Shell"
Host the HTML Page with Silverlight, in a Winforms desktop application, using a web browser control, and communicate to and fro using HTML DOM. Then I can request the hosted shell to do things like printing. See details here
Mono also has a web browser control - based on FireFox XULRunner instead of IE - not yet succeeded in loading Silverlight inside that. Another option might be using Webkit.
Embed a web server
Embed a light weight web server with in the Host application, and handle requests to perform such operations. You can probably define a protocol on top of HTTP for things like saving to a local folder, sending data to print etc.
Is a full WPF application not an option for your situation?
As you probably know Silverlight uses a subset of WPF so you may be able to change your application relatively easy.
A wpf app would be easier than having a web server etc bundled within your application.
You wont in the foreseeable future be able to have access to resources such as printer and files (apart from isolated storage) through Silverlight as you know.
You could have a seperate part of your app to upload files to the webserver then read these in your silverlight app from a service.
Depending on your printing requirements (e.g. if you just want to send everything to an office printer) you could send the informaton you wanted printed to a service that will then print it for you. However I am guessing you want each client machine to be able to print in which case this wont work for you.
I am attempting to also reuse a codebase for both desktop and silverlight. There are two options that I know of in addition to the ones mentioned
If you directly reference (instead of a project reference) a silverlight dll from a normal project, it should work. This would let you reference a silverlight dll for both projects.
Have two project files (one wpf, one silverlight) that point to the same set of files. You might have to have to use a few compiler flags here and there, but this should let you use the same files for both.