We are working on a WPF desktop app packaged using the Desktop Bridge MSIX wrapper, and we need it to detect and automatically apply updates when they are detected, restarting the software.
Research so far suggests it might be possible to use PackageManager from UWP to get hold of the package and check like that, or creating a new "Windows Runtime Component" project with an IBackgroundTask that listens to the windows.updateTask extension.
I don't know which one is the right one, what's going to be easiest or most reliable. Has anyone had to do this and knows what works?
Thanks
Related
I'm currently developing a UWP application that now needs access to APIs that are normally not accessible by apps in an AppContainer.
As I'm not (yet) able to migrate to WinUI3, I want to try using DesktopBridge to do the otherwise restricted work.
As both processes have to communicate with each other, I thought of COM as it should make things relatively seamless once everything has been set up.
According to this page this should be possible using "Packaged Com".
I now have...
An Out-of-Process Com Server (c# net5.0) that is accessible by non-packaged win32 apps (e.g., PowerShell) but not my own UWP App.
The UWP App with the main logic and UI.
A Packaging Project, which creates a package out of both projects.
(Manifest)
The code is on GitHub: Repo.
Does someone have an idea how to solve this problem or got an alternative for IPC?
PS: Tutorials I used
Packaged Com
Out-Of-Proc COM in c#
Packaging / DesktopBridge
So if I understand you correctly, you want to communicate between a UWP app and a Win32 app, and these two apps are packaged inside a Windows Application Package Project. Please let me know if it is not correct.
For your scenario, since the two apps are packaged together with desktop bridge, I'd suggest you use the App Service. App service could be used not only between UWP apps but also between the UWP app and desktop app.
These are the detailed steps:
You need to declare the AppService connection in the Manifest file of the package project.
You need to call the App service API in the win32 application.
You need to handle the connection in the App.xaml.cs in the UWP app
You could check the detailed code and sample from Stefan Wick's blog - UWP with Desktop Extension – Part 3.
In my VS2017 solution, I created a UWP and .NET Standard Library 2.0.3 projects. Referenced Library project from UWP. Library project is using a System.Diagnostics.Process to start a process. In debug mode, I get access denied error at line Process.Start(...) of the code inside Library project.
I thought the purpose of new .NET Standard Library project was to support various platforms (.NET, .NET Core, UWP etc) uniformly. But I guess, the sandbox nature of UWP apps is probably not allowing me to run Process.Start(...) albeit the process is running inside Library project. Question: What I may be missing and/or how can we resolve the above issue?
You cannot launch process directly from UWP, but there are some alternative ways to do that. The first one is using FullTrustProcessLauncher, if you need some example, check this post series. Another way is using a WPF or WinForms application to host UWP Controls with the Xaml Islands where there aren't restrictions to call any .NET APIs, but remember, through this way, your app will work only on Desktop devices.
According to this answer, you can't use Process.Start in a UWP app. There are some alternatives for launching other apps, but you can't execute arbitrary .exe or other processes.
I have an existing project for Windows 10 (UWP).
It creates an app that can go into Windows Store and be sideloaded, and that works fine.
... but now I would like to create a desktop-version (an exe-file) from the same code base (to avoid sideload-security issues in local network).
I created a VS 2015 4.5.2 WPF project and started to reference the components (dll's) used in the UWP project. But the importer states that some of the components depends on .Net-Core, and cannot be referenced.
So: Is it possible to mix .NET-Core and .NET-Framework components in the same WPF project?
Or: Can I create a .Net-Core console-app, create the used windows, use XAML, and export an exe (with dependencies) that can run standalone?
Thx!
Unfortunately what you are tying to achieve is not possible.
UWP and WPF are different stacks and unless you are using PCLs code cannot be shared between them.
Even then, the XAML layer is different and not compatible from one stack to another.
So no, you cannot reuse your code in a WPF application
As for the other solution, you cannot have your UWP app run as an .exe because Universal Apps run a different Application Model called appx which is fundamentally different than the exe application model.
There are ways to wrap an exe application in an appx (See the Desktop App Converter) but there is no converter/repackager to take you from appx to exe.
I am new to using Xamarin and have always used Visual Studio, however I now require to develop a desktop application which will run on both Mac and Windows, OR at least a package which will let me package for both.
I have created a GTK 2.0 Project, connected to a MySQL database etc and all is fine, however I can only see options to create a .exe and no .dmg file for OS X but the debugger lets me run it on my Mac.
Does anyone have any ideas or pointers?
We use Xamarin.Mac to enable us to develop a Windows and Mac client using c#.
We chose to re-build the core code in Xamarin Studio and use interfaces to abstract the OS dependent code.
We share 90% of our code in the Xamarin.Mac/VS solutions.
Do let me know if I'm helping... if so I can provide more detail if need be.
Check the following link on how to create an .app bundle with Xamarin:
How to set Xamarin MonoMac project so its build outputs .app package instead of .exe?
An app bundle is basically a special kind of folder structure that contains all app data, including e.g. graphical resources, configuration files, localisations, etc...
A .dmg file is used for distribution and can be created using other tools like Apple's own Disk Utility, once you've created the app.
I have made a Kinect Application in Microsoft Visual Studio 2010. I need to make an exe of the application which can run on any windows based system. If I need to do that than is there any requirements that the system should fulfil? and If yes, then how do I do that?
I tried to use the exe in application/bin/debug/application.exe by copying it in another folder but it shows an error but if I run the exe from the bin/debug/application.exe it works. Am I missing something here or is it the only way to do that?
"Any Windows based system" isn't going to work. Assuming you're using the Kinect SDK, it will only run on Windows 7 (and supposedly Windows Server 2008). The computer running the application will need either the Kinect Runtime, which only works with the new Kinect for Windows sensor, or the Kinect SDK, which also works with the Kinect for Xbox. Microsoft wants to sell more Kinect for Windows sensors, so they don't allow the runtime to work with the old Xbox Kinects. Makes sense in a way, but man that bugged me when I first found out about it. There's a short post showing how to test for the existence of the Runtime on application load, so you can show an appropriate error message instead of just crashing out.
You need to copy any files that the program relies on, such as DLL files, along with the executable. There's instructions here for how to embed the DLL files into the executable; I've not tried it but it might be worth a shot.
The correct .NET version should be installed when either the Runtime or the SDK is installed; you shouldn't have to worry about this.
#Coeeffect is right, but you can also publish version 1.0.0.0 of your app by going to project -> properties -> publish -> publishing wizard to publish your application to then use on ther computes ect. Hope this helps!
You need to copy all non-standard DLLs that your program uses.
The target computer needs the appropriate version of .Net.