[BUG] The secret variable given does not point to a valid password.

[HelenMamalaki]

Project MSIX SDK or Win7Msix

Describe the bug In the MSIX package signing task (using the UI editor), I have added a Password Variable like so $(CertPassword) which contains the certificate password.

No matter what I do I get [error]The secret variable given does not point to a valid password.

[debug]passwordVariable=***

[debug]***=undefined

I have tried 1) CertPassword is defined as a secret Group variable in Pipeline > Library which I have given full pipeline permissions AND in the pipeline definition itself > Variables tab I have added the variable group there as well. 2) I have tried adding CertPassword as a Pipeline variable (unrelated to group variables/ library) 3) I have tried keeping the variable as plain text rather than secret ****

I'm not sure what I am doing wrong. I am not using YAML, I am using the classic editor. I keep reading that you need to do some mapping of variables to Environment variables so that a script can access them, But there are no Environment variables in the signing task - it is not a script task.

Any help would be greatly appreciated. I am building a Win UI 3 app built with MAUI. Thank you!

[florelis]

You need to pass just CertPassword without $( or ). Then the task will internally try to get the value of $(CertPassword). In other words, you need to pass the name of the variable and not the value of the variable.

I admit this is probably not very intuitive. I can't remember the reasoning, probably that we wanted to make sure we didn't get plaintext passwords.

In case you're interested, this is what's going on in the logs:

##[debug]passwordVariable=***
##[debug]***=undefined

Say your password is $(CertPassword) = p@ssw0rd. The task is getting as input $(passwordVariable) = p@ssw0rd (first log line). Then, it is trying to go to the library looking for a variable named p@ssw0rd that should contain the actual value. Then it gets $(actualPassword) = $(p@ssw0rd) = [undefined] because that's not a variable name (second log line). Since p@ssw0rd is the value of a secure variable, AzDO knows to censor it as *** any time it shows up in the logs.

[HelenMamalaki]

@florelis Thank you so much for the quick reply. That fixed it for me! :) This issue can be closed down.

Now that both the Build and Package, and Signing task is succeeding however, there still doesn't seem to be an msix package anywhere. I have added a Publish Pipeline Artefact task and set it to publish the contents of the Output folder (defined in the Build and Package MSIX task.)

I have enabled this setting:

All I am getting is this below. There is no MSIX file in the Output path.

[florelis]

This sounds familiar but I can't remember off the top of my head. I'd expect the pipeline logs to tell you where the msix file is if you do a search for .msix in the text

[HelenMamalaki]

@florelis Thanks. The logs confirm that the msix should be inside the folder path I am publishing. :/

MSIX build and package Log: /p: AppxPackageOutput=D:\a\1\Package\DfTF-WindowsApp.msix

Publish Pipeline Artefact Log: Uploading pipeline artefact from D:\a\1\Package for build #5613

Full log: "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" D:\a\1\s***.sln "/p:Platform=any cpu" /p:Configuration=release /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxPackageSigningEnabled=false /p:AppxBundle=Never /p:AppxPackageOutput=D:\a\1\Package\DfTF-WindowsApp.msix

[florelis]

That's weird. I tried building a project with a pretty similar command line but the package did go where I would expect it to.

Is there anything else interesting in the build task logs? Like any error or other mention of the output path you're using? You said the signing task succeeded. Do the logs there suggest it did find the package?

I'm not an expert at debugging pipelines, so what I would do in cases like this is to temporarily add a script task (Powershell or Cmd) that checked some things, like listing the contents of the directory to try and figure it out.

[HelenMamalaki]

@florelis Thanks. I have disabled the sign task for now. I've looked closely at the logs and it is clearly doing a build but there are no logs for actually creating or publishing an .msix. :(

I am getting things like

Build succeeded.

23 Warning(s)
0 Error(s)

Even with System.debug enabled, there are no logs showing the .msix being created. It prints out variables:

outputPath=D:\a\1\Package\DfTF-WindowsApp.msix
solution=D:\a\1\s\**\*.sln
MSBuild version 17.6.3+07e294721 for .NET Framework

and Creates directories Creating directory "D:\a\1\Package\net6.0-windows10.0.19041.0\win10-x64\

and Compiles and Copy files. But there are no logs for actually attempting to publish the .msix though?

Full logs for MSIX Build and Package task: MSIX build and package.txt

My set up:

[florelis]

I think I know what's happening, and it's most likely an issue with the build task, but I'm not sure what the fix would be. To unblock you, I think you'll need to use the MSBuild or VS Build tasks instead of the MSIX Build one, but I'm not sure what the arguments you need would be.

So, for context: The only thing the MSIX build task does is call MSBuild with the appropriate parameters to make it build the package with the configuration provided. But this assumes that the solution has a Windows Application Packaging project (a project with extension .wapproj instead of .csproj or .vcxproj). It is that project type (and the associated targets) that actually do the work. If you don't have a .wapproj, then when we pass the magic parameters, there is no build task that does anything with them and we end up doing nothing. We should detect when this happens and fail the task instead of continuing; see #586

I see in my VS that the options for creating a WinUI project are "Blank App, Packaged" and "Blank App, Packaged with Windows Application Packaging Project". I'm not sure what mechanism the first project type uses to create the packages, but it probably requires us to pass different arguments to MSBuild.

@dianmsft Do you know if WinUI projects do anything special for building their MSIX packages? Seems like they are not using a .wapproj

[HelenMamalaki]

@florelis Thank you. I am by no means a pipeline automation expert, I am using the UI Editor - to try to publish the Windows app from my .NET MAUI project. I would have thought there would be some docs on how to do this. If there is any work around you can recommend - or can advice what parameters are needed to pass to the VS build task please do let me know.

[HelenMamalaki]

Should I create a new issue for "MSIX Publish task does not support WinUI MAUI packages as they don't have .wapproj" -so you can close this one?

[florelis]

Should I create a new issue for "MSIX Publish task does not support WinUI MAUI packages as they don't have .wapproj" -so you can close this one?

Yes, feel free to create a new issue for .NET MAUI support. I'll close this one now.

to publish the Windows app from my .NET MAUI project. I would have thought there would be some docs on how to do this. If there is any work around you can recommend - or can advice what parameters are needed to pass to the VS build task please do let me know.

I wasn't familiar with .NET MAUI, so I got it confused with WinUI. I think in general what you have to do to build in a pipeline is the same as you'd do when building from command line (not VS). There are docs about publishing a .NET MAUI app for Windows using the CLI. You'd have to use the dotnet command, not MSBuild, so you'd build using the dotnet task instead of the VS Build one.

The command would look like dotnet publish <path to project .csproj> -f net7.0-windows10.0.19041.0 -c Release -p:RuntimeIdentifierOverride=win10-x64 -o <your output dir> Note that you have to point it to the project file (.csproj), not the solution file (.sln); and the identifiers may be different (e.g. not net7.0 or not 19041) depending on your project. I'm not completely sure how that command would look in the pipeline UI

[Richard-Dufour]

florelis post/comment about the variable name MyVariable instead of $(MyVariableName) is what fixed it for me.

Can't thank you enough, spent days trying to figure out what I was doing wrong. Why was this done/implemented this way you ask? Just to drive me nuts.

Thank you again florelis.