UPDATE: I have been using the WiX Toolset to build installers for at least 10 years. Now, I am trying to add a Maui application to the installer, but...
MSIX only installs for the current user - I need it to be a machine-wide install.
MSIX installs to a hidden folder in C:\Program Files\WindowsApps... which I don't like. I want to install it into a folder I have control over.
My question is how can I build the Maui app and take the contents in the ...\bin... folder, run HEAT (a WiX utility) to create the WiX xxx.wxs file and build a WiX bundle with the other components in the application. It is not possible to deploy a MSIX file in a WiX bundle and even if it did, the issues I list above make this unfeasible.
How can I get all of the necessary files so that I can deploy a Maui app and not use MSIX?
#ToolmakerSteve - yes, I deploy .NET6/7 projects via WiX. The actual question here was how to publish a MAUI app in an unpackaged way. #jfversluis describes the process here:
.NET MAUI Windows Unpackaged Apps
Related
I am building a standalone Windows C# console application using .NET Framework 4.5. Since I want it to run in background without command prompt appearing, the output type is set to 'Windows Application'.
Most answers I found in the internet is how to build application that doesn't require .NET Framework to be installed but in my case, I want the application to run without requiring users to install it in Windows.
I was able to do that if the target framework is .NET Core but when the target framework is .NET Framework, the published application has no .exe file but only application manifest & setup files which upon running will open an installation wizard.
Even when publishing the application in Visual Studio 2019, the publish wizard asks "How will users install the application?". Is that mean any console application using .NET Framework shall be installed first before it can be executed? Many thanks in advance for any help/answer.
How about instead of publishing it just copy the .exe from the bin/debug folder? Then it should work without installing or publishing it. (if it is just 1 Assembly)
So, we finished a few wpf conversions to .net core, and now we have a need to ship one to an external client as an installer. Previously we used ClickOnce, but that has been deprecated in .net core and will not be ported according to MS, with them recommending MSIX. However, as we understood from docs, even though we'll sideload a WPF application it will still run in a sandbox with a virtualized file system. And that is a no go for us, it has obviously been designed with UWP+Marketplace delivery in mind. We need the application on the file system with full access to file system, the "good old way".
We could just ship them as a zip file and have the client unpack, but management deemed that as not-so-professional, so we need a delivery package similar to what msi/clickonce had. Has anyone delivered apps on core outside MSIX?
EDIT: Microsoft has announced they are going to include ClickOnce support in .NET 5
You can deploy .NET Core and .NET 5 applications internally in an organization by sideloading msix packages.
I have been successfully using Clickonce for deploying .NET line of business applications for years.
Now that I’m updating my apps to .NET Core I wanted something similar to Clickonce. In other words: publishing your installer in a network share and deploying your autoupdating app to your clients by simply coping a shortcut to your installer.
You can achieve this with msix packages. The problem is that you are limited to Windows 10 version 1709, and later
The solution came on December 19th with MSIX Core 1.1. Packaging your app with msix core support you can target Windows 7 SP1 and later, and this is something I needed because at work we are slowly transitioning to Windows 10 from Windows 7 and I still have to support old versions of windows.
The steps for packaging your .net core app using msix core are:
Create a Windows application packaging project in your solution.
Right click on the Applications subfolder of your Windows application packaging project and select Add Reference. Then select your target project.
Change your Package.manifest (reference: msix-packaging/MsixCore at master · microsoft/msix-packaging · GitHub) Right click your Package.manifest file and select View code Change your to:
<Dependencies>
<TargetDeviceFamily Name="MSIXCore.Desktop" MinVersion="6.1.7601.0" MaxVersionTested="10.0.10240.0" />
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.16299.0" MaxVersionTested="10.0.18362.0" />
</Dependencies>
With this you stablish your min version to MSIXCore.Desktop in other words Windows 7 sp1.
Right click your Windows application packaging project and select Publish then Create App Packages.
Choose Sideloading then check Enable automatic updates.
In order to install the package in the client machine you must sign it. I recommend you to create a self-signed certificate. You must install the certificate in the client machine so that the package is trusted and you can install it. If you are in a domain you can deploy your self-signed certificate with a group policy.
The optimal situation is to sign the package with a trusted certificate provided by a trusted root certification authority. My personal choice is to create a certificate in my own windows certification authority (which is trusted in my local domain). If you decide to sign your package with a trusted cert this is the command line:
.\SignTool.exe sign /fd SHA256 /a /f yourcert.pfx /p yourpassword *.appx
Select Generate app bundle to Never.
Select your network share for publishing the package
In order to execute your package installer in Windows 7 sp1 machines you must previously install msixmgrSetup-1.1.0.0-x64.msi or msixmgrSetup-1.1.0.0-x86.msi accordingly. You can find the installer here
Windows 10 machines will recognize the installer right away.
If you want to know more about msix packages you have a good explanation here
I hope this guide helps you to get your deployment system working.
Well, apparently, we are again faced with "our way or the highway" from MS, so we just used Inno Setup. Until such time we get a proper installation process or MSIX allows unsandboxed setup without unnecessary file system abstraction, this will have to do.
There are other tools such as Advanced Installer or InstallShield that can create a MSI/EXE installer now and later in case you decide to go with the MSIX, you will just add a new build to your current project.
The tool will automatically sync the content of the MSI with the MSIX, or at least this is what Advanced Installer does for you.
They also have a VS Extension, so you can build the installer inside your Visual Studio IDE.
So I am building a test application using the basic Vuforia implementation in Unity for export to UWP (universal windows platform). I am running into issues when trying to install the packaged application on computers other than the one I developed it on.
When running the installer I get an error after initializing the install from the packaged .appx file:
I run the installer on the computer that I built the unity application on, the installer works fine, it installs the application and runs perfectly and builds without errors.
However, when I try to move the .appx by itself to another computer and install it there, it is giving me this error on all computers I try.
"App Installer failed to install package dependencies. Ask the developer for Microsoft.NET.CoreRuntime.1.1 package."
I tried to install the .NET.CoreRuntime.1.1 package with no avail from the .NET Downloads page
FYI - the .appx file generated is the "Release" version for x64.
What am I missing here? How can I include the dependencies in the .appx file itself?
What am I missing here? How can I include the dependencies in the .appx file itself?
The Microsoft.NET.CoreRuntime.1.1 could not be Integrated into the app package directly. You need to install the dependencies package separately before install the app.
The store will install package dependencies to your machine automatically when install the app with Microsoft Store. So you could publish your dependent package to the store.
If you only want to install the app through the sideloading, you could make PowerShell command to install the package dependencies in the Dependencies folder where under the appx folder.
For Windows 10 Fall Creators Update, related sets can now be installed via App Installer. This allows distribution and deployment of related set app packages to users. And this is documentation you could refer to.
I have a Windows Setup project that installs 2 windows services, copies over a bunch of executables and driver files, and then installs a driver. I want to add a WPF project to my solution, and then deploy it with the same behavior as ClickOnce -- I want an entry in the Add/Remove Programs list, with an option to Uninstall. I know that I won't be able to update this program without updating and redeploying the MSI, unlike ClickOnce which has automatic updates.
I have tried adding the project output to the custom actions, file system, programs folder, and desktop. This only copies the final .exe for my wpf application to these areas, but it does not register the application as part of the system apps.
The actual setup project has a row created in Add/Remove Programs, so I can uninstall all my services and remove the copied files from the system, but I also want another row in Add/Remove Programs for the WPF application.
Please let me know if there is a way to install the WPF application as part of my windows setup installer, and also a way to uninstall if the setup project is being uninstalled or rolled back.
Thanks,
Misha
If I create a WPF or WinForms app, I can launch it by its executable in Debug folder. Why do all programs come with an install wizard and how do I create one for my WPF/ WinForms app?
Programs usually come with an installer because it can put the program in a known location, add things to the start menu, add registry keys, etc.
You can create an installer using NSIS.
installers will be run (most of the time) by administrators. This will allow you to modify protected things of the system during setup such as the file system (Program Files folder), registry and install services and such.
The actual program then will not need these privileges and can be run by non-admins.
Also: Microsoft Logo requirements make the use of Windows Installer (the service that installs MSIs and adds them to your control panel for easy removal) mandatory.
While deploying a windows based application to a client machine we need to take care about several aspects like installation location,Registry values and to ensure that the required version of .Net framework is present in the client machine.Such kinds of things can be automated using an installer.You can create an installer by using the setup and deployment project or using clickonce
Check the below links for more
Setup and Deployment Projects
Deploying a WPF Application (WPF)
Deploying a Standard WPF Application Using ClickOnce and Visual Studio
WPF 3.5 SP1 Deployment
For example, almost any program produced by Visual Studio 2010, if copied to a freshly installed Windows XP system, will fail to run. This is what installers do well that is hard to get right: dependencies.