I am developing a UWP app wherein I have created a UWP project, Windows Packaging project, Class library, console application(windows application).
Here the UWP app communicates with the console app(win23) by sending request and getting responses from the methods created in the Win32 app. This is done by using FullTrust permission.
But, now I want to add another Fulltrust permission app in this project that will run independently whenever i call this app. Also, these two win32 apps will not have any user interface but will only acts as a background process. So in the new win32 I am implementing the functionality where I am accessing my Microsoft Office outlook contacts.
So If I declare this new win32 app in the Package.manifest file of the Packaging project and run the app. It gives me an error saying We can have only one fullTrust permission in the project.
Please can you guide me how to go about this.
While you can have only a single fulltrust process extension declared in the manifest, you can certainly launch as many full trust processes as you like. The way to do this is by creating a launcher process and declare that as your fulltrust process extension. From that launcher you can then launch any number of other EXEs depending on a parameter that you pass to the launcher.
This approach is explained in detail here with complete sample code:
https://stefanwick.com/2018/04/06/uwp-with-desktop-extension-part-2/
For completeness: another option (more complex and maybe not what you want) is to declare multiple objects in your manifest. The additional objects can be fulltrust applications that you launch from your UWP via the AppListEntry API.
Related
I would like to use nice UWP bluetooth classic APIs in my app. However my app has to be used as .exe, and it has to be portable (no installation in system). Is this possible?
The API used by UWP comes from the Windows Runtime Api, if you need to integrate Windows Runtime API in your desktop application, this is feasible.
Here is the document: Call Windows Runtime APIs in desktop apps.
But there are still some restrictions:
Due to the reference to the corresponding version of the SDK, your application can only run on the corresponding version (and above) of the Windows 10 system. May not work properly on lower version systems.
According to the description of this document, the Bluetooth API in Runtime is not yet fully supported in desktop applications.
In the description, you mentioned that you want to use portable application. Although many application functions can only be used in applications with a package identity, Windows.Device.Bluetooth is not listed here.
If the class under the Windows.Device.Bluetooth namespace has the Windows.Foundation.Metadata.DualApiPartition attribute, it means that the class can also be used directly in desktop applications, you can view related APIs in the Windows.Device.Bluetooth document.
I have a WPF application which is converted to UWP using the desktop bridge, Now I need to call this app/exe from windows scheduler to do some stuff. Now my problem is getting access denied. If any app trying run from task scheduler getting this access denied error.
I have identified a workaround to achieve this. My actual requirement was 'I need to trigger an action in my Desktop bridged UWP app from windows scheduler' unfortunately windows scheduler has not read/write access to the uwp apps folder
The workaround was I have packaged a simple exe along with my UWP app package during first launch of the app the packaged exe will be copied to outside uwp sandbox, from the windows schedule I will execute this copied 'exe' say sample.exe and sample .exe will send a custom windows message to my UWP app.
The work around provided by thunderbird would work only with the Desktop Bridged UWP app. Native UWP app cannot do this way.
I followed these two docs (Doc1, Doc2) to integrate Feedback hub in my app. I used NuGet to install the Microsoft Store Services SDK.
As recommended I am using StoreServicesFeedbackLauncher.IsSupported() to check if the Feedback hub is available or not. This works locally on my machine, but in production all customers hit System.Exception with message "Method 'StoreServicesFeedbackLauncher.IsSupported()' was not included in compilation, but was referenced in HomePage.<feedback_tapped>d__23.MoveNext(). There may have been a missing assembly."
I have read the docs again and don't seem to have missed any of mentioned the steps.
Edit
This app is a Desktop Bridge app. The solution has a UWP app which communicates with a win32 exe. I am trying to launch the app from UWP app. The solution has a Windows Application Packaging project to package the app.
For an app for Windows 10 IoT Core on Raspberry Pi2, I need to use a launcher app or StartUp-Task, which creates a shadow copy of my app and launches it. I need to use this approach to be able to substitute DLLs during runtime, without having a lock on the DLLs and without disrupting running services. That's needed as the device running it, would be remote somewhere out of reach, deployed at a client's site and I need my app to be running to service the device. After updating my DLLs, I would restart it and it would run with the new libraries, start the launcher as default app, which then starts my app.
Before Windows 10 and UWP the approach was to use System.AppDomain from mscorlib.dll in the .NET Framework to create a new AppDomain in a cached directory. The config, executables and DLLs would be copied to a cache directory and run from there. That leaves the original DLL available for substitution and doesn't put a lock on them. This was also a very useful technique used in IIS and webapps, which needed to run without interruptions even if the code needs updating. The open threats keep servicing open requests until these are done and new requests will be serviced using the new updated versions.
Now in Windows 10 System.AppDomain is not available anymore. I tried Windows.System.ProcessLauncher but encountered several issues with it. First I have to register the EXE in the registry to allow launching it. Then it tells me I can only run it from an app container. I didn't get it to work as of now. It's just a tedious and messy approach IMHO.
Now to my question: What would you use as an alternative to the described old approach on Windows 10 IoT Core? Does anyone have a small snippet of sample code to share? Or perhaps a link pointing in the right direction? Any advice would be appreciated.
This approach is not compatible with the Universal Windows Platform app model.
You will have to push an updated package of your app.
I currently have 3 projects which produces 2 executables
Class library to do work
Windows Service project that uses library #1
WPF App that uses the library #1
The class library is used to perform some client-server interaction.
What I want is to only have 2 projects, the class library, and another that produces an executable that can be run as a Console, WPF, or a Windows Service. Is it possible (or advisable) to do it this way? What should the project output type be?
The main reason is that we have automated scripts to run that expect some fixed file paths. I want to avoid having to duplicate the scripts for the WPF executable and the Service/console executable.
I'm not sure about being able to do WPF, but TopShelf will allow you to run an executable as a console application or as a service.
http://topshelf-project.com/
There are two ways to use TopShelf - exe as a service or using shelving.
To run as a console application you just run yourprogram.exe.
To install as a service it's simply yourprogram.exe install.
I know this question is a bit old, but...
You can start a new project as a WPF project, then right-click it in the solution explorer and change "Start As" to console application. Your WPF app will still run exactly the same, but a console window will appear where you can use things like Console.WriteLine() calls.
You could then accept a command-line parameter that tells your application to suppress the rest of the UI, leaving only the console part. I don't think this will allow it to run as a service, though.
You have to go for Windows Communication Foundation aka WCF, Click link to learn basics
http://msdn.microsoft.com/en-us/netframework/dd939784