I want to deploy my in-house UWP app only to selected Windows Phone 10 devices via a download link.
This already works for iOS and Android, but I have troubles with WinPhone 10.
On my development device, I can just download and install the created appxbundle file. However, it seems that the appxbundle does not include the dependencies (Microsoft.NET.CoreRuntime.1.0.appx, Microsoft.VCLibs.ARM.Debug.14.00.appx). Therefore the installation does not work on devices, which have never been used to develop the app (and therefore do not have the dependencies installed).
Is there a way to create a complete appxbundle which also installs the dependencies?
Building the app in release mode solved the problem.
The .NET native toolchain includes all the required dependencies into the executable and therefore the installation of the dependencies is not required.
Related
how to create apps for winget using electron.js, I first thought of using portable in target but it just installs the app but I can't use it again, is the any other targets which I can use?
Today, you would need to be able to provide an installer for an electron.js app. The Windows Package Manager supports three types of installers as of the 1.1 release.
MSIX
MSI
.exe installers
Work is in progress for portable applications (just a loose executable like NuGet), and for installers inside of a .zip file. These are targeted for the 1.3 release.
Is it possible to get Tauri to use webview2 fixed version? It looks like this functionality was under consideration via the Tauri bundler config (https://github.com/tauri-apps/tauri/issues/1378 )? The reason is we're considering moving away from .net/cefsharp to rust/tauri but the app is enterprise and we can't guarantee the existence of the webview2 runtime and we don't we want to be in the business of installing the runtime on customer PCs. Currently the CefSharp binaries are included in the app.exe directory and deployed via msi (Wix). We're not too concerned about webview2 updates because the app only presents canned html included in the distro.
I've tested (unsuccessfully) executing our Tauri app from within the root of the webview2 directory created by extracting the webview2 cab file.
The Tauri app works fine when executed on a Windows PC with the webview2 runtime installed (as expected).
I have a problem. I recently installed VS 2015 and Windows 10 on my computer.
Having Universal Apps are amazing and I plan to convert some of my programs on UWP.
But I have a problem. In one of my programs, I allow the user to save its datas on its OneDrive. And if OneDrive is unavailable, the datas are stored on local devices.
And when OneDrive is available, the newly stored datas are pushed to OneDrive. Synchronisation in fact.
So it is the problem. In the UWP dll named Universal.Live I have installed Live SDK 6 with Nuget. During the package installation, there is some work done to see if the Live SDK is compatible with UWP.
Great ! It's compatible and successfully installed.
But when I wrote
using Microsoft.Live;
The name is not recognized. And if I use the class LiveAuthClient which is in the namespace, it isn't recognized too...
This is a real problem :( Any ideas ?
I had the same issue adding the Live SDK to my app. For some reason the Package.JSON isn't correctly resolving and downloading the package (or recognizing it).
Either way, just add the DLL to your references the old fashioned way. Personally, I'd just add it to a console app (not using the new Project.json package), get it from NUGET, and grab the DLL from the Packages.
After you have the DLL:
Right click on References
Add Reference -> Browse...
Find the DLL and add it. ("...\\packages[LiveSdk]...")
It works!
Download it from here, Compile it, and grab the desktop SDK:
https://github.com/liveservices/LiveSDK-for-Windows
You can also download the msi, install it, figure out where the DLL is installed to and grab it from there:
https://www.microsoft.com/en-us/download/details.aspx?id=42552
According to this GitHub issue, LiveSDK isn't supposed to be used for Universal Windows Platform apps: https://github.com/liveservices/LiveSDK-for-Windows/issues/58
Instead we should use these SDKs that cover the same functionality:
Mail/Calendar/Contacts: https://dev.outlook.com/
Files/OneDrive: https://dev.onedrive.com/
I'm having trouble getting a nodejs app which relies on JSDom to work on Azure due to it depending on a native module - Contextify, I understand Azure does not provide compilation for native modules.
However according to Azure documentation
Since Windows Azure Cloud Services rely on the node_modules folder being deployed as part of the application, any native module included as part of the installed modules should work in a cloud service as long as it was installed and compiled on a Windows development system.
It all works fine on my dev box as it's compiled during npm install, what I don't understand is why it isn't working on Azure as I am providing the compiled version? If it works on my windows dev box the compilation is clearly successful. I deploy to azure form a local git repository so I'm wondering if the compiled files are being left out when I commit?
UPDATE: the latest Azure release (specifically, the Mobile Services backend) supports arbitrary NPM modules - See the section on Mobile Services: NPM Module Support
From the JSDom docs on the npm:
Unfortunately, doing this kind of magic requires C++. And in Node.js, using C++ from JavaScript means using "native modules." Native modules are compiled at installation time so that they work precisely for your machine; that is, you don't download a contextify binary from npm, but instead build one locally after downloading the source from npm.
https://npmjs.org/package/jsdom#contextify
Since your "native modules" don't have the same signature as whatever machine in azure's "native module" would be signed, it doesn't load.
I have an application that uses unity and the logging application block. I recent checked-out the application from the repository after these assemblies were added and I got a few error. Eventually I installed enterprise library on my pc and it's now working. My question is do I have to install Enterprise Library on every pc that uses it? If so is there a workaround?
The issue is that your project which references the Enterprise Library assemblies is referencing where the Enterprise Library is installed - probably the Program Files directory. Instead of referencing them there, you could add the Enterprise Library references via Nuget, then check the packages into your source control as part of the project. That way you have the project and its dependencies all in one place, and it shouldn't be necessary to install the Enterprise Library everywhere.
Hi I have no idea how I fixed it. I think that my problem was that I was using the dlls and the config exe's from the enterprise library labs. I should have installed ent lib 5 on my pc. I had the same problem in my ci server so I deleted my project from the repository and added it again as my local was working.
So in a nut shell. Install entlib 5 and don't use the dlls from the labs in your project. I don't need to install ent lib in my deployment all I need is to copy the dlls.