This doesn't seem to build once forked..

[benstaniford]

I tried for a day or so to get my own project to build via this method but couldn't due to some very obscure errors that I couldn't seem to google. In the end I thought I might clone this sample and tinker with it to suit my needs but once I'd forked it, I found it doesn't seem to build any more:

Here's the CI output:

https://github.com/benstaniford/github-actions-for-desktop-apps/actions/runs/3197448618

[LanceMcCarthy]

That error usually means some sort of an SDK issue.

This demo uses NET Core 3.1 and Project reunion (WinAppSDK 0.8.x). The end of life for this pathway is 0.8 because WinUI dropped WPF, so it will never go over 1.x

If you want to see a more modern approach in a production WPF app (which is built as a .NET app), take a look at my builds here where I build CI and also CD for both appinstaller and Microsoft Store.

• Repo home: https://github.com/LanceMcCarthy/MediaFileManager
• Workflows: https://github.com/LanceMcCarthy/MediaFileManager/tree/main/.github/workflows
  • CI build - no bundle/packaging
  • Appinstaller build - Packaged and signed (this one you're probably most interested in)
  • MS Store build packaged, but unsigned (Microsoft signs the package in DevCenter)

[edit] Cleaned up formatting

[LanceMcCarthy]

Side Note: it's been 2 years since main has been built. I am investigating now and will push any needed changes so that main is built successfully.

[benstaniford]

Thanks @LanceMcCarthy , I'll check out that project. I'm actually looking at writing a Windows service which consumes ETW events, and my initial inclination was to do it all in C++ but I thought I'd investigate Self-contained .Net Core + Build everything on GitHub as part of my initial research which is what lead me here. Thanks for answering.

[LanceMcCarthy]

I don't see any reason why you couldn't do that. GH Actions have been an absolute savior for me (in many many projects) to automate the build process and produce the desired artifact.

With a self-contained, single executable .NET app (I would choose .NET6), you do not have to package it in MSIX unless you need distribution/installation capabilities. You can get a single-file executable if that's all you're looking for (the MSIX makes it easier to distribute and install that single-file compiled app).

Self contained tutorial is here => https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli

In short, with .NET 6 you can do this:

dotnet build myproject.csproj -t net6.0 -RID win-x64 --self-contained

Notes:

• When choosing self-contained, you cant use any for a target platform, it has to be a value for rid (runtime identifier, see the catalog https://learn.microsoft.com/en-us/dotnet/core/rid-catalog). The tutorial I linked to above explains that in the first section.
• I'd be careful when enabling AOT or publish-trimmed features. It can severely affect any dynamic part of your code (i.e. refection). If the code doesn't directly get referenced, that specific code can be stripped out and not included in the final compilation. you don't notice any problems until it hard-crashes at runtime because of the missing dependent assembly or code.

[benstaniford]

That's really helpful, thank you again.

[LanceMcCarthy]

Okay, fixed the build 😎 => https://github.com/microsoft/github-actions-for-desktop-apps/actions/runs/3199140513

• I had to update several components, but the main reason for such an error is that the version of msbuild .NET is using outdated. I fixed that by bumping the .NET SDK to 6.0.x (even through the project might still target 3.x).
• In addition to that fix, I did several other improvements, see the PR for details https://github.com/microsoft/github-actions-for-desktop-apps/pull/49

In your fork, GitHub will show you an easy rebase button that says "sync fork". That will pull in all the new commits I just added.

[benstaniford]

That's amazing, thanks so much for your efforts Lance, that's really helpful.