No this is not enough as the deploy is actually deploying a UWP app, which isn't from MSBuild. Using things like the WinAppDeployCmd SDK tool might be an option here, but I think also a powershell script is probably the easiest...I haven't looked to see if anyone started one or not.

https://docs.microsoft.com/en-us/powershell/module/appx/add-appxpackage?view=win10-ps#examples

I've got a work item assigned to me for this. It's possible to deploy it as a "dev build" with Add-AppXPackage and using the AppManifest.xml as a path target with the -Register switch, but this install lacks taskbar and start menu icons (it's just a black square.) Additionally, I've had intermittent problems with launching the app like this - occasionally it opens with a blank white window and hangs.

The long-winded way to install it is to create a self-signed certificate (New-SelfSignedCertificate), add it as a local trusted root, and run the generated Add-AppDevPackage.ps1 that sits in the Cascadia output folder. Additionally, you have to run a Release build (use bzc rel) as the Debug build won't generate an AppXBundle by default as it's a lengthy process. It should be obvious that we cannot ship a self-signed .pfx in the project as this would be dangerous - just ask Lenovo (Superfish)

When you deploy the Cascadia project with Visual Studio, it handles the certificate part for you.

@oising I can't locate the AppManifest.xml file in the project. Does one need to create it manually? If yes what exactly should be in it?

AppManifest.xml is auto-generated by visual studio when building the package. It's possible that msbuild would build it too, but I'm not 100% positive on that. I know it's generated from package.appxmanifest, as well as some other metadata the project knows about it's dependencies.

So I think self-signed is fine for dev builds but for official released builds, a proper certificate i needed. To put in simple terms, it's easier to grab the appx bundle from Artifacts from latest commit and install it (either double-click or PS script) than to have to grab Visual Studio and build the solution. Right now attempting to grab an appx from Artifacts and installing it will fail unless you have Developer-Mode on as there is no cert or it's considered untrusted by Windows. Unfortunately Developer Mode breaks Win32-OpenSSH, which I and a bunch of other people use (It can be more convenient than opening a WSL session just to remote into another host).

I mean, both building it from source and trying to run it from the build artifacts are both harder than just installing it from either the store or github, both of which have been available for some time now...

Developer Mode breaks Win32-OpenSSH

???
We all use Win32-OpenSSH with developer mode turned on all the time. This is the first I’m hearing of this.

There's a known bug for it but appears to only affect some hosts. I believe having to install some software on an isolated network tends to make installations a bit more difficult (can't grab Dev Mode packages, SmartScreen prevents some app installs since it can't verify trustworthiness) and in Terminal's case, installation outside of Store and Chocolately, even with proper dependencies installed result in Terminal being unable to run with Windows thinking there's a network connection error (not sure why it's looking for a network connection to start with but suspect it's due to not finding the local file path to the executable, which is even stranger).

Also idea of self-signing the dev builds is basically to add the equivalent of the ConEmu feature where you get to choose between stable, beta, and alpha (which is essentially in most cases master branch). The process would need to be manual for now but since the software needs to be physically moved in some cases to a different network (via USB or portable HDD/SSD) , it's a manual process regardless.

I am trying to build and run Windows Terminal from the command-line. I did manage to build it using the PowerShell module, but I am unable to launch either WindowsTerminal.exe or wt.exe. There's a mention that one cannot launch it outside of Visual Studio, but why is that? Is code signing mandatory in order to launch Windows Terminal? I have successfully copied the files from an existing MSIX installation into a temporary directory and launched it from there, so what's different from trying to launch one that was just built from source?

So, the most annoying part of the modern app platform is that there are multiple different parties responsible for "laying out" an application. Visual Studio has one version of "layout", and the commandline build tools have another. In fact, the CLI doesn't actually lay the app out, it just makes a zip file (well, msix file) with source/destination paths. It never puts the application all into one folder where it can just be run.

VS lays the app out correctly on disk and registers that layout with the OS as a "loose package". It's not code signing, just... a bunch of sqlite gunk in a database somewhere plus a folder in the right layout with a resources.pri file in it. Annoying, but necessary.

If you want to figure out how to possibly maybe get it running from the CLI, check out the VSCode project configuration, where we have an obnoxiously long deployment command.

How does the Windows Terminal team automate their builds, then? I'm pretty sure it's not someone pushing a button in Visual Studio from their work laptop, and then deploying it for millions of people to use :) Or at least I hope that's not the case!

Hah! So, our release builds are produced by that "list of loose files -> msix package" step I mentioned above for the CLI build. It produces a single unsigned msix which you can (1) extract to a temporary folder and run or (2) codesign and install directly.

• This will build the .msix (CascadiaPackage -> %OPENCON%\src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test\CascadiaPackage_0.0.1.0_x64_Debug.msix)

  "%msbuild%" "%OPENCON%\OpenConsole.sln" /p:Configuration=%_LAST_BUILD_CONF% /p:Platform=%ARCH% /p:AppxSymbolPackageEnabled=false /t:Terminal\CascadiaPackage /m

  • This takes 25s, on my desktop, even if there's nothing to build. So this takes a while.
  • This still needs to get deployed! This will only build the msix.

• I think these will deploy the package:

  # If you haven't already:
  Import-Module tools\OpenConsole.psm1;
  Set-MsBuildDevEnvironment;
  
  # The Set-MsBuildDevEnvironment call is needed for finding the path to
  # makeappx. It also takes a little longer to run. If you're sticking in powershell, best to do that.
  
  Set-Location -Path src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;
  if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) {
    Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'
  };
  New-Item ..\loose -Type Directory -Force;
  makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;
  Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown

  Or the cmd.exe version:

  @rem razzle.cmd doesn't set:
  @rem set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
  @rem vsdevcmd.bat does a lot of logic to find that.
  @rem
  @rem I'm gonna hardcode it below:
  
  powershell -Command Set-Location -Path %OPENCON%\src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) { Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'};New-Item ..\loose -Type Directory -Force;C:\'Program Files (x86)'\'Windows Kits'\10\bin\10.0.19041.0\x64\makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown

  (yes, the cmd version is just calling powershell to do the powershell version. Too lazy to convert the rest by hand, I'm already copying from .vscode\tasks.json)

• Now, INTERESTINGLY, building the package from VS generates the loose layout to begin with, and then registers the loose manifest, skipping the msix stop. That still takes 7s to do on my desktop (even with nothing to do), but it's a lot faster than the commandline inner loop here. I wonder if there's some config flag that can be passed to the wapproj build to get it to make the loose layout rather than the msix...

Note to self: After the changes to unpackaged, portable, etc in 1.18, there might be better ways of doing this from the commandline in the near future.

Refer to #15133 - that was one of the tip PRs for calling makepri manually. We may be able to find a way to modify that to just rebuild the package resources without needing to do the whole commandline deploy.

Now, if only we could get the FastUpToDate check