Using the Desktop Bridge (formerly known as Project Centennial) through the DAC, one can create a full-trust UWP App. I thought this meant you can now create a Full-Trust UWP App and if so, how do you do that?
What I am trying to figure out is what configuration can I manually set on my UWP Project to grant it full-trust.
If you need some background, I need to create an Enterprise tool that has to be UWP. The application is going to be run on my company and one of the features that would make the UX better is to be able to access some parts of the file system outside of those allowed by UWP and preferably without the summoning of a dialog. Being able to run other DLL would also be a big plus; perhaps DLL Hell is desired this time around.
#Anzurio - just stumbled across your question and thought I'd share our experiences building the new Windows Terminal.
We originally set out to create the Terminal as a UWP app, with a nice modern XAML UI, but quickly found that the UWP app platform couldn't support a couple of our key requirements:
1. Terminal must be able to be launched elevated
2. Terminal must be able to launch & connect to arbitrary executables (e.g. cmd, powershell, wsl, etc.)
Because of these limitations, we had to create the Terminal as a standard Win32 process which contains a XAML Island which hosts the Terminal's Tab Bar and Terminal XAML Control instances in the main window frame.
We have taken care to keep as much app lifetime/logic code OUT of the Win32 host as we can, so that we'll have less work to do if/when the app platform does support our requirements and we get to ship a real UWP Terminal apps.
We are working with the app plat team to figure out how we might be able to build/full-trust modern apps more cleanly in the future.
In the meantime, I hope this response helps, and hope the Terminal source gives you some inspiration as to how to craft your own apps.
I don't know such of options. Yes, DAC can contain the Full-Trusted Win32 apps, but it is only applicable for Win32. UWP - WinRT - apps are restricted with App Container.
The alternative option is - using the "Special capabilities".
Special and restricted capabilities
There are many of declarations that overcome the restrictions of sandbox. Some of these are not applicable for store submission - only for in-house deployment apps. Others need registration for Microsoft to deploy with store. If your requirement is matched, you can use it.
(Added - June 2017) From Win10 AU, we can use the "FullTrustLauncher" API to launch the Win32 component from UWP App. But, yes, it does not mean we can run the "UWP" - WinRT process with full-trust rights. It's applicable only for Win32 process. And, the Win32 app executable should be contained in the application's AppX package and the manifest should declare the executable as "windows.fullTrustProcess".
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="fulltrustprocess.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="SyncGroup" Parameters="/Sync"/>
<desktop:ParameterGroup GroupId="OtherGroup" Parameters="/Other"/>
</desktop:FullTrustProcess>
</desktop:Extension>
</Extensions>
FullTrustProcessLauncher Class
Related
The requirement is to be able to run a kiosk application on Windows 10 which has unrestricted capability on the host computer to make arbitrary system calls and launch any kind of app including Appx and Win32. The kiosk app can be fully trusted - it may be thought of as a side-loaded in-house app for machines equipped with conventional keyboard and mouse to be used in a public setting. The user should not be able to circumvent or escape the kiosk app.
Assigned access fits the general idea, except that assigned access only works for Appx which are not full trust (no access to the needed APIs to launch Win32 apps, etc.). These restrictions appear to be by design, so it would be unlikely this approach could successfully meet the stated requirements. Although it is possible to author a WPF app as a "full trust" Appx, it won't work in kiosk mode.
Replacing the Windows shell with a custom one (the kiosk app) would work except that some of the tasks the kiosk app needs to be able to perform require the presence of the explorer shell (e.g. launch an Appx - requires services provided by the explorer shell).
Running a Win32 app above the lock screen might be a solution, if it were possible (I believe this is what assigned access does with its Appx).
Running an app in any normal fashion would require that many hotkey combinations are disabled or intercepted, including [CTRL][Alt][Del], which seems to be a major issue/challenge. It seems there is no way to prevent the user from invoking task manager or otherwise circumventing an app to gain unsecured/unmediated access to the system.
Is there any way to meet the requirement as I've outlined? If so, what is the technique and (if relevant), what APIs are central to the approach?
Update:
Although the full-trust converted WPF AppX could be installed and selected for assigned access, it "did not work" because of some issues found to have been recorded in the event log, specifically: Applications and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI/Operational. Observed behavior was that upon user login, a blue screen would be displayed with the familiar Windows spinner, which would flicker every second or so as if something was being retried over and over. The associated event log messages (all source "Apps") are:
ActivateApplicationForContractByAppIdAsUserWithHost of the app LockDownSample_y1sem70fxfdf6!LockDownSample for the Windows.Launch contract failed with This app does not support the contract specified or is not installed.. (Event ID: 5985)
The app LockDownSample_y1sem70fxfdf6!LockDownSample is not registered for the Windows.Launch contract or is not installed. (Event ID: 5951)
The app Microsoft.WindowsMaps_8wekyb3d8bbwe!App is not registered for the Windows.PreInstalledConfigTask contract or is not installed. (also Event ID: 5951)
Activation via contract helper of the app Microsoft.WindowsMaps_8wekyb3d8bbwe!App for the Windows.PreInstalledConfigTask contract failed with Class not registered. (Event ID: 5990)
Is this due to an intentionally imposed limitation, or is this something which can be resolved?
Update 2:
Found this recent question:
Windows 10 assigned access app fails to start due to not registered for Windows.Launch contract
This fairly accurately describes my experience with Assigned Access for a full-trust kiosk app, concluding with the answer "not yet supported".
So basically what my trivial research on debuggers lead me to was a debugger works by creating a wrapper around the original process and the process runs within the wrapper.(Not in the scenario where debugger is attached to an already running process). So how does it work for metro apps? Metro apps can only run inside the app container which is allocated to them when they are installed ( actually metro apps are not installed in the true sense) and the mapping between app container and metro app is recorded in a registry key. (All from my research,dont know how correct please correct me if I am wrong). So does the debugger also run within the same app container?
EDIT: A short note on the driving force why I wanted to learn this. I am stuck with this. So I was thinking if I can achieve this IPC by making the desktop app as a debugger (Or automating the debugger, drats this is getting even more creepier) and simulating the communication between metro apps and desktop apps using DebugBreak(From inside the metro app) and Continue statements(From the pseudo debugger app)
The mental image of a "wrapper" is wrong. A debugger is just a separate process that uses the built-in Windows support for debugging. It has the SE_DEBUG privilege and is initiated by an app that has the normal desktop app privileges. Like Visual Studio. So it doesn't run inside the AppContainer itself.
Han's answer is correct. For Metro style apps, we introduced a new feature that allows you to start the app suspended and we will launch the registered debugger with command line options to indicate what process to attach to. See the IPackageDebugSettings API for information on this feature, or check out the http://winrt.codeplex.com project for an example usage. I'm not certain, but there may be developer license restrictions around this API.
As to your original intention of supporting IPC between a Metro style app and a desktop app - as the linked thread states, this is unsupported.
I need to write an application that can detect if the "Bing - Get me there" application is installed on the current phone and if so, launch it.
Is this possible? The app would need to do this for other external applications as well, so a generic method or interface for this would be helpful.
Applications run in a sandbox on Windows Phone and there is no way to tell if other applications are installed unless you are writing both of them and you use a method to announce to other applications that you are installed and they know how to read that announcement.
2 approaches to such announcements would be:
Have both (all) apps synchronise with a web server and report which devices they have been installed on. The apps can the query which other apps have been installed on that device.
Have all apps write a file to a location where all apps can access. The only place to do this is the PicturesLibrary so you have to embed the identifier in the name of the image or in its contents and be able to query all images to identify the other installed apps. The user could manually delete any images you create in this way though.
Beware, neither method can tell if the other app has subsequently been uninstalled though so this is far from foolproof.
As far as I know, there's no way to do that.
Applications on Windows Phone run in complete isolation, and can not act with other applications, other than some highly specialized apps (i.e. for playing media).
I need to create Solution Architechure for Windows Mobile and have following queries:
My application is like a service that will start in phone startup and that should run in background and have no UI (this is not a problem). I am using third party dlls (with source code) in my project. Does windows mobile have any problem of loading dlls when we put the application in start-up? If yes, should I include all souce code in my application (may be in AppCode folder)?
If I include all third party source code in application, my application executable size will be bigger. Will bigger size executable cause problem (slow mobile on startup or simply hang) if I put my application in start-up?
I have seen this video regarding starting applications quickly but seems that it does not apply to my case as my application does not have UI.
How should I create structure of my application such that loading application as service in start up will not have any issues?
Apps launched from the Startup folder actually launch pretty late - well after the shell is up. So no, there are no issues with launching from there. There are no problems with loading DLLs eitehr so you can put the library code in your app or leave it as a library - it makes no difference.
I'm creating a multiplayer game for windows phone 7. How can I run multiple instances of the emulator in order to debug it?
You can indeed run multiple instances of the Windows Phone 7 emulator at the same time, and even debug them simultaneously, as I show in my blog post.
Open the folder [Your Drive Letter]:\ProgramData\Microsoft\Phone Tools\CoreCon\10.0\addons
Locate the file ImageConfig.en-US.xsl
Take a copy of it, leaving it in the same directory, and name it something like ImageConfig.en-US 2nd Instance.xsl
Open the copy in a text editor.
Locate the element DEVICE and change it's Name attribute, also assign a new GUID value to ID.
Scroll down the file to locate the part that says PROPERTY ID=”VMID”:
Put a new Guid inside that element – make sure though that you use capital letters rather than lower case.
Save the file
Re open the XAP deployment tool, or Visual Studio, if you already have them open, and you’ll see your new Emulator instances.
See the blog post for more details, and screenshots to clarify some of the steps
You can only run one instance of the Windows Phone 7 emulator at a time on a single machine - that's set by default, and if you don't want to mess with custom configurations. When you deploy from Visual Studio, the same instance is shared between the running instances of the development environment.
However, you can create additional instances of the WP emulator if you follow the instructions in this article. Make sure you backup the config files before editing them.
I had the same problem, trying to test my multiplayer game, and i eventually bought a WP7 device (HTC HD7) on ebay, unlocked it for development purposes, and used it and the emulator for testing.
Since I have experience with the android environment, I can say that denying the possibility of multiple emulator instances really damage the development efforts. Hope Microsoft will change this.
BTW, i'm using the Skiller SDK for the multiplayer and social side of my game (Their official WP7 SDK will be avialable in a few days, and you can download it from http://dev.skiller-games.com). I totally recommend it.
Good Luck.