Portable executable not supported for non-exe targets

[seppeon]

Brief description of your issue

When trying to create a package for PlantUML, I found that the .jar file was renamed by winget-cli from plantuml.jar to plantuml.exe. This prevents packages of non-executable.

Steps to reproduce

Grab the manifest from here:

1. https://github.com/microsoft/winget-pkgs/pull/110767
2. run winget install --manifest F:\Files\Git\winget-pkgs-1\manifests\p\PlantUML\PlantUML\v1.2023.9\
3. open up the directory which it was installed, for me this was C:\Users\David\AppData\Local\Microsoft\WinGet\Packages\PlantUML.PlantUML__DefaultSource.

Expected behavior

The file saved as plantuml.jar

Actual behavior

The file is renamed to plantuml.jar.exe

Environment

Windows Package Manager v1.4.11071
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.1848
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.11071.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[denelon]

Java archives aren't yet supported. They require a Java runtime to be present on the system. WinGet doesn't have a native mechanism to support them.

The best current solution I see for this issue is for the validation service to report a more specific error based on the extension not being .exe for a portable package.

[stephengillie]

Non-portable Java applications either bundle a JRE or JDK, or require one as a dependency.

[Trenly]

@denelon - Is this more of a feature request than a bug?

[blaubaer]

This issue leads to other unexpected behavior. Although .cmd and .bat files are not real executable files itself, they are treated like executables in Windows - like the same feature in Unix based operating systems.

.cmd and .bat files are very common in the software engineering environment for many tools, like Apache Maven, Gradle, NodeJS, Microsoft Visual Studio (several tools) and many more.

From my perspective there is not that much that holds us away from supporting it. I would purpose the following changes:

1. The way how the links in %USERPROFILE%\AppData\Local\Microsoft\WinGet\Links are generated needs to be adjusted. Instead of bare symbolic links which leads to issues like #3749.

   If we instead create wrapper binaries: Small binaries which simply contains (for example in the resource table) to target link, they can determine how to execute them the best way: Just by executing it the direct way (in case of .exe) or pick the right executor from the Registry.

   As a result this links:

   1. ... can be created also without elevated permissions or developer mode (no strange behavior like #3749) anymore
   2. ... and programs which are simply do not support to be executed via symbolic links (try to evaluate a symbolic links in .bat files 😏) will work, too.

2. The automatic validation of winget-pkgs should be adjusted to also either execute .exe directly or for the other files pick the right executor from the registry.

If these both issues are solved, I assume many portable installations which are using these approaches will work.

BTW: I faced this issue while I'm working on winget-pkgs#123118 to solve winget-pkgs#65391.