C# ClickOnce application could not start. No message, no logs

Question

I'm using VisualStudio 2022, Community Edition. My application is a WinForms app based on .NET 8.0. I have published it successfully several times (also many times before with previous versions of .NET Framework and .NET Core). Suddenly, the application could run after the installation - it got installed properly but could not be launched via the start menu (I'm using Windows 11). There were no messages, no events were logged, and there were no logs in Temporary Internet Files (according to Microsoft, ClickOnce is logging there).

Double clicking on the executable from C:\Users\borja\AppData\Local\Apps\2.0\ ... was starting the program, but, of course, the application version was not there.

After undoing all my changes one by one without success, I have compared <appl-name>.dll.manifest files of my deployments. The section <trustInfo> of the NOT_WORKING one contained the following:

<security>
  <applicationRequestMinimum>
    <PermissionSet class="System.Security.NamedPermissionSet" version="1" Name="LocalIntranet" Description="Default rights given to applications on the local intranet" ID="Custom" SameSite="site">
      <IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="USERNAME" />
      <IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
      <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Allowed="AssemblyIsolationByUser" UserQuota="9223372036854775807" Expiry="9223372036854775807" Permanent="True" />
      <IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="ReflectionEmit, RestrictedMemberAccess" />
      <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Assertion, Execution, BindingRedirects" />
      <IPermission class="System.Security.Permissions.UIPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
      <IPermission class="System.Drawing.Printing.PrintingPermission, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="DefaultPrinting" />
      <IPermission class="System.Net.DnsPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
      <IPermission class="System.Security.Permissions.TypeDescriptorPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
      <IPermission class="System.Security.Permissions.MediaPermission, WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" version="1" Audio="SafeAudio" Video="SafeVideo" Image="SafeImage" />
      <IPermission class="System.Security.Permissions.WebBrowserPermission, WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" version="1" Level="Safe" />
    </PermissionSet>
    <defaultAssemblyRequest permissionSetReference="Custom" />
  </applicationRequestMinimum>
  <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
    <!--
      UAC Manifest Options
      If you want to change the Windows User Account Control level replace the
      requestedExecutionLevel node with one of the following.

    <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
    <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
    <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

     If you want to utilize File and Registry Virtualization for backward
     compatibility then delete the requestedExecutionLevel node.
-->
    <requestedExecutionLevel level="asInvoker" uiAccess="false" />
  </requestedPrivileges>
</security>

The manifest of the deployment that worked contained the following:

<security>
  <applicationRequestMinimum>
    <PermissionSet class="System.Security.NamedPermissionSet" version="1" Name="LocalIntranet" Description="Default rights given to applications on the local intranet" Unrestricted="true" ID="Custom" SameSite="site" />
    <defaultAssemblyRequest permissionSetReference="Custom" />
  </applicationRequestMinimum>
  <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
    <!-- UAC Manifest Options
         If you want to change the Windows User Account Control level replace the 
         requestedExecutionLevel node with one of the following.

    <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
    <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
    <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

        Specifying requestedExecutionLevel element will disable file and registry virtualization. 
        Remove this element if your application requires this virtualization for backwards
        compatibility.
    -->
    <requestedExecutionLevel level="asInvoker" uiAccess="false" />
  </requestedPrivileges>
</security>

I haven't had the manifest file in my project, so the "PermisionSet" bulk must have been contemplated by Visual Studio, for whatever reason. I have solved the problem by adding the app.manifest file to the project and specifying the same parameters under <trustInfo> as I have seen in the manifest of the working application.

However, I've lost a day work on this and it still bothers me: a) why Visual Studio changed the <trustInfo> section in the first place; and b) why there are no messages/log files giving some clue why Windows refuses to run the newly installed application.

Once I've figured out what was going on, it was easy to find this: https://learn.microsoft.com/en-us/visualstudio/deployment/trustinfo-element-clickonce-application?view=vs-2022. And that is an additional issue: do we really need to learn all that just to deploy a desktop application? Or should we be taking a risk by (blindly) adding project parameters without understanding what is actually being specified? There should be some well explained, working default, I believe.

Has anyone else experienced this problem? Could anyone explain where the <PermissionSet> elements could have came from?