trenly / winget-pkgs Goto Github PK

View Code? Open in Web Editor NEW

This project forked from microsoft/winget-pkgs

3.0 3.0 0.0 257.29 MB

The Microsoft community Windows Package Manager manifest repository

License: MIT License

PowerShell 100.00%

winget-pkgs's People

Contributors

Stargazers

Watchers

winget-pkgs's Issues

Detection of existing PR should not be done while removing manifests

I want to remove a manifest because its InstallerUrl is 404 not found but when ContinueWithExistingPRs: never is set, it gives the "Existing PR Found" message and exits. Hence, detection of existing PR should not be done when script mode is 5 (Remove a manifest).

Add a third parameter "mode"

Description of the new feature/enhancement

When specifying PackageIdentifier and PackageVersion, we should be able to specify the Mode of the script so that we can directly jump to the download URLs prompt.

[Bug]: When creating a new package the yaml-language-server for defaultLocale is locale

Brief description of your issue

Just noticed this issue when upgrading rammichael.Textify in microsoft#37544
Apparently the yaml-language-server for the defaultLocale is locale when you create a new package, however quickupdate or autoupdate fixes the issue

Steps to reproduce

Create a new package

Expected behavior

# Created with YamlCreate.ps1 v2.0.4 $debug=NVS1.7-2-0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.1.0.schema.json

PackageIdentifier: Test.Test
PackageVersion: 1.8.10
PackageLocale: en-US
Publisher: Test
PackageName: Test
ShortDescription: Test
ManifestType: defaultLocale
ManifestVersion: 1.1.0

Actual behavior

# Created with YamlCreate.ps1 v2.0.4 $debug=NVS1.7-2-0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.locale.1.1.0.schema.json

PackageIdentifier: Test.Test
PackageVersion: 1.8.10
PackageLocale: en-US
Publisher: Test
PackageName: Test
ShortDescription: Test
ManifestType: defaultLocale
ManifestVersion: 1.1.0

Environment

YamlCreate version 2.0.3/2.0.4

Advanced Modes / Dev Modes

Description of the new feature/enhancement

Add "Developer Modes" which can be accessed through the enablement of a setting

Proposed technical implementation details (optional)

Add the setting "EnableAdvancedOperations"
Add mode for moving a manifest
- Requests package identifier & version from
- Requests package identifier & version to
- Moves the package
  - UpdatesPackageIdentifier in all applicable files
  - Updates PackageVersion in all applicable files
- Creates PR
- Deletes old package
- Creates PR
Add mode for auto update static URL's
- Requests package identifier & version
- Copies manifests exactly
- Updates InstallerSha256 hashes automatically
- Updates SignatureSha256 where applicable
- Updates ProductCode where applicable
- Updates PackageFamilyName where applicable
- Deletes old package

Change prompt that is displayed while removing a manifest

Instead of this prompt:

a prompt to select "why are you removing this manifest" would be better.

I am saying this because it will be easier for the moderator to approve/suggest changes if the PR title contains <reason>: <package identifier and version> instead of just Remove: <package identifier and version>.

Some of the reasons, user can be prompted for:

[1] InstallerUrl is 404 Not found. (PR title: "404 not found: <package identifier and version>")
[2] Moving the manifest to a different PackageIdentifier. (PR title: "Moving: <package identifier and version>")
[3] The application does not install silently. (PR title: "App doesn't install silently: <package identifier and version>")
[4] Custom

Improvement in automatic detection of `PackageFamilyName`

Description of the new feature/enhancement

When a user selects manual entering of Installer Hash:

then the option for finding PackageFamilyName should download the URL instead of throwing an error:

Proposed technical implementation details (optional)

if ($null -eq $script:dest)
download the installer
else
continue with installation of package and find PackageFamilyName

[New Feature]: Alphabetical sorting

Description of the new feature/enhancement

I'd like to sort some field alphabetically

The most important field is probably FileExtensions
The second field could be Tags

The less noticeable fields are Commands and Protocols

Proposed technical implementation details (optional)

No response

My Demo Issue in Trenly/winget-pkgs

[New Feature]: Neutral/Better if newer version

Description of the new feature/enhancement

Currently we sometimes see Add version: when its actually a New version:

Proposed technical implementation details (optional)

Not sure if we're already sorting the current versions as neutral?

Validate file name before downloading

Some URLs result in an invalid file name. These should be caught and handled before attempting to download the file

Automatically find available information from installer

Description of the new feature/enhancement

Since we are making most of the things automatic in the script, I think we can automate the process of finding PackageVersion, and some other fields. We can use the logic from PackageParser.cs which I guess finds most of the information (like InstallerType, Architecture, PackageVersion, etc.) and fill it while generating the manifest.

Since @Trenly, please don't mind, but I think you are familiar with both PowerShell & C#, so you can do that pretty easily. Also, I read about running C# code directly in PowerShell and found this:

$code = @"
using System;
namespace HelloWorld
{
	public class Program
	{
		public static void Main(){
			Console.WriteLine("Hello world!");
		}
	}
}
"@
 
Add-Type -TypeDefinition $code -Language CSharp	
iex "[HelloWorld.Program]::Main()"

So, I guess we can tweak the code a little and run the code directly or you can completely convert it into PowerShell code.

I may be demanding too high, but after this, we can use the script in CI/CD the same way wingetcreate is used and this will also greatly reduce the chance of the wrong PackageVersion, Publisher, InstallerType, or InstallerSwitches.

Use system proxy setting for downloading

Description of the new feature/enhancement

System.Net.WebProxy doesn't automatically use proxy in system proxy settings by default. When system proxy is enabled, the script can manually obtain the proxy address from registry and use it for downloading.

Proposed technical implementation details (optional)

This is the code I am using as a workaround:

$WebClient = New-Object System.Net.WebClient
if ($(Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable).ProxyEnable) {
    $WebProxy = new-object System.Net.WebProxy
    $WebProxy.Address = $(Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyServer).ProxyServer
    $WebClient.Proxy = $WebProxy
}

Problems in parsing the manifest when there is no en-US locale

From logs of workflow run vedantmgoyal9/vedantmgoyal9#98 on my repo:

Actual behaviour:
https://github.com/microsoft/winget-pkgs/pull/29305/files

I think the problem occurs because the is only one locale: ko-KR.

Question:
Is it compulsory that en-US should be there with a package?

Provide option to delete previous manifests

Description of the new feature/enhancement

Provide the option to or automatically remove previous manifests if either

The URL's for the new version are the same as the previous version
The previous version URL's return 404's

Proposed technical implementation details (optional)

Before we begin the work on this; We need to understand how wingetbot handles this, as well as how to properly create the PR's so that they are correctly processed in the pipeline

Condense common installer parameters to manifest level

Description of the new feature/enhancement

When all installers have the same values for keys which are valid at the manifest level, the keys should be removed from the installer level and added to the manifest level

Proposed technical implementation details (optional)

Use defaultLocale schema file and Locale schema file

We should be using both Locale and defaultLocale schemas in creation of manifests

Return to Stable, Stability Testing, Bug Fixes, and Enhancements

I think it's about time that we begin the long process of getting this 2.0 branch of YamlCreate merged back in to stable master. This is dependent on MSFT adding the component governance, and I hope that won't take too much longer.

At this time, I am not planning on adding any additional complex features to the 2.0 version. Any issues which are enhancements may be deferred or worked on in a separate branch. The goal of this is to ensure that that any bugs in the current version of the script are found and worked out before it is merged back in. I will primarily be focusing on fixing bugs that are found with the script so we can pull the 2.0 version back into master.

[New Feature]: Add `-SkipPRCheck` switch

Description of the new feature/enhancement

For packages like KDE.Kate, the version is the same and only InstallerUrl is changed (w/ InstallerSha256). If some user has set ContinueWithExistingPRs: never, the user is required to change the setting to always/ask and then revert it back again. Therefore, we should add a switch -SkipPRCheck so that it continues ignoring the setting.

Proposed technical implementation details (optional)

if -skipprcheck, then,
skip pr check and ignore the setting
else
do nothing, continue normally

Error while upgrading some manifests

A screenshot is enough to describe the issue 🙂

[New Feature]: Clear and prompt for DisplayVersion under AppsAndFeaturesEntries if defined

Description of the new feature/enhancement

Test manifest/reference manifest: AnyDeskSoftwareGmbH.AnyDesk (not direct link since it may change)

The first step into AppsAndFeaturesEntries we can take is probably clearing and prompting for the DisplayVersion under AppsAndFeaturesEntries IF its defined

Once winget-cli and wingetcreate actually supports manifest schema 1.1.0 we can probably move the ProductCode to AppsAndFeaturesEntries

Proposed technical implementation details (optional)

No response

Support 1.1.0 manifests

Description of the new feature/enhancement

Be prepared to switch to Manifest version 1.1.0 once microsoft/issues/27937 is completed

Proposed technical implementation details (optional)

Review the 1.1.0 manifest schema for any important fields that should be prompted for (see also microsoft/winget-cli/issues/1243
Ensure validation for all fields is correct

Other Considerations

Do we need to support 1.1.0 and 1.0.0 schema manifest creations

[Bug]: Simple Update replaces the Architecture

Brief description of your issue

Noticed in a manifest of @vedantmgoyal2009 that the Architecture was messed up, tried to update NotepadsApp and realized it did the same

Steps to reproduce

Select Mode:

  [1] New Manifest or Package Version
  [2] Quick Update Package Version (Note: Must be used only when previous version's metadata is complete.)
  [3] Update Package Metadata
  [4] New Locale
  [5] Remove a manifest
  [Q] Any key to quit

Selection: 2

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: JackieLiu.NotepadsApp

[Required] Enter the version. for example: 1.33.7
Version: 1.4.6.0


There may already be a PR for this change. Would you like to continue anyways?
JackieLiu.NotepadsApp version 1.4.6.0 - https://github.com/microsoft/winget-pkgs/pull/33920
  [Y] Yes
  [N] No

Enter Choice (default is 'N'): y
Found Existing Version: 1.4.6.0
Installer Entry #1:

        Architecture: x86
        InstallerType: msix


[Required] Enter the download url to the installer.
Url: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
Installer Entry #2:

        Architecture: x64
        InstallerType: msix


[Required] Enter the download url to the installer.
Url: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
Installer Entry #3:

        Architecture: arm64
        InstallerType: msix


[Required] Enter the download url to the installer.
Url: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle

Expected behavior

- Architecture: x86
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513
- Architecture: x64
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513
- Architecture: arm64
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513

Actual behavior

- Architecture: x86
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513
- Architecture: x86
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513
- Architecture: x86
  InstallerUrl: https://github.com/JasonStein/Notepads/releases/download/v1.4.6.0/Notepads_1.4.6.0_x86_x64_arm64.msixbundle
  InstallerSha256: 741EAF5D350C9DFFB37A104B717100629CD8E2135028ECA33DB86A5E990B9410
  SignatureSha256: E3B5A1FCEE7EBB5979662DC8CCB5625896D0F0129418C14D83196228A4801513

Environment

# Created with YamlCreate.ps1 v2.0.2

Do not require Sha256 when URL is the same

Description of the new feature/enhancement

When entering an Installer URL, if the URL is the same as one previously entered, use the same InstallerSha256 as was detected/entered from the previous URL

Proposed technical implementation details (optional)

Refactoring of the script to update the manifests in-place where applicable

Upon further review; This should also include a refactoring of the script to update the manifests in-place where applicable, instead of always creating new ones.

Logic Flow:

------------------------------
During read previous flow
------------------------------
If old singleton manifest exists
> Create new empty multi-manifest
> Copy existing fields from singleton into the appropriate multi-manifest file

If old multi-manifest exists
> Set new installer manifest equal to existing installer manifest
> Set new locale manifest equal to existing locale manifest
> Set new version manifest equal to old locale manifest

If no manifests exist
> Create new empty manifests

------------------------------
During data entry flow
------------------------------
For any new required entries
> Set the appropriate Manifest['Key'] value directly instead of using script variables

For any optional values
> If the value entered is null or empty, do not update the field
> If the value entered is not null and is valid, update the value in place

------------------------------
During file creation flow
------------------------------
Directly use the new manifests which were updated in-place 
Re-Sort the keys to ensure accuracy

Originally posted by @Trenly in #30 (comment)

`Resolves PR Title #48` instead of `Resolves #48`

Description of the new feature/enhancement

I would like to see the full title instead of just the PR Number when adding Resolves in the PR

Proposed technical implementation details (optional)

Not sure how GitHub does it, but it seems like you need to add * or - infront of the line like

Resolves #48

Resolves #48

Instead of Resolves #48

Setting for "Submit a PR"

Description of the new feature/enhancement

Some people who are regularly using the PowerShell script for creating/updating/removing manifests would like to automatically submit PR at the end.

Proposed technical implementation details (optional)

We can add another setting named:

AutoSubmitPR: <true|false>

which would skip the following prompt:

and would continue further:

[Bug]: System.AccessViolationException: Attempted to read or write protected memory.

Brief description of your issue

I don't know whether this problem is occurring only on my machine or others also do experience this error.

Found Existing Version: 1.0.0-rc.6
Installer Entry #1:

        Architecture: neutral
        InstallerType: inno


[Required] Enter the download url to the installer.
Url: https://github.com/LinwoodCloud/Butterfly/releases/download/v1.0.0/Butterfly-Setup.exe

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at Microsoft.Security.ApplicationId.PolicyManagement.PolicyEngine.AppIdPolicyHelperClass.NormalizeFilePath(String bstrFilePath)
   at Microsoft.Security.ApplicationId.PolicyManagement.FileManager.NormalizeFilePath(String filePath)
   at Microsoft.Security.ApplicationId.PolicyManagement.FileManager.GetFileInformation(String filePath, Boolean collectPublisherInformation, Boolean collectHashInformation)
   at Microsoft.Security.ApplicationId.PolicyManagement.Cmdlets.GetAppLockerFileInformationCmdlet.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
   at System.Management.Automation.CommandProcessorBase.DoExecute()
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
   at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
   at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.DlrScriptCommandProcessor.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.DlrScriptCommandProcessor.Complete()
   at System.Management.Automation.CommandProcessorBase.DoComplete()
   at System.Management.Automation.Internal.PipelineProcessor.DoCompleteCore(CommandProcessorBase commandRequestingUpstreamCommandsToStop)
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
   at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
   at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
   at System.Management.Automation.CommandProcessorBase.Complete()
   at System.Management.Automation.CommandProcessorBase.DoComplete()
   at System.Management.Automation.Internal.PipelineProcessor.DoCompleteCore(CommandProcessorBase commandRequestingUpstreamCommandsToStop)
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
   at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
   at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
   at System.Management.Automation.DlrScriptCommandProcessor.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
   at System.Management.Automation.DlrScriptCommandProcessor.Complete()
   at System.Management.Automation.CommandProcessorBase.DoComplete()
   at System.Management.Automation.Internal.PipelineProcessor.DoCompleteCore(CommandProcessorBase commandRequestingUpstreamCommandsToStop)
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
   at System.Management.Automation.Runspaces.PipelineThread.WorkerProc()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

[process exited with code 3221225477]

Steps to reproduce

Run the following command:

.\YamlCreate.ps1 -PackageIdentifier LinwoodCloud.Butterfly -PackageVersion 1.0.0 -Mode 2 -SkipPRCheck

Enter InstallerUrl: https://github.com/LinwoodCloud/Butterfly/releases/download/v1.0.0/Butterfly-Setup.exe
Get a weird error.

Expected behavior

No Error.

Actual behavior

Error.

Environment

Name                           Value
----                           -----
PSVersion                      5.1.22523.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22523.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[Bug]: Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.

Brief description of your issue

Just updated WinRAR Beta to 6.10.3 and got this error:

InvalidOperation: C:\Users\User\GitHub\winget-pkgs\Tools\YamlCreate.ps1:112
Line |
 112 |      [string]$_.ToLower()
     |      ~~~~~~~~~~~~~~~~~~~~
     | Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.

This is most likely caused by WinRAR having a file extension 001 which got removed during the upgrade, i'm guessing ToLower fails when there is no letters

Steps to reproduce

Selection: 2

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: RARLab.WinRAR.Beta

[Required] Enter the version. for example: 1.33.7
Version: 6.10.3


There may already be a PR for this change. Would you like to continue anyways?
RARLab.WinRAR.Beta version 6.10.3 - https://github.com/microsoft/winget-pkgs/pull/37513
  [Y] Yes
  [N] No

Enter Choice (default is 'N'): y
Found Existing Version: 6.10.2
Installer Entry #1:

        InstallerLocale: en-US
        Architecture: x64
        InstallerType: exe
        Scope: machine


[Required] Enter the download url to the installer.
Url: https://www.rarlab.com/rar/winrar-x64-610b3.exe
Installer Entry #2:

        InstallerLocale: en-US
        Architecture: x86
        InstallerType: exe
        Scope: machine


[Required] Enter the download url to the installer.
Url: https://www.rarlab.com/rar/winrar-x32-610b3.exe

Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.locale.en-US.yaml
InvalidOperation: C:\Users\User\GitHub\winget-pkgs\Tools\YamlCreate.ps1:112
Line |
 112 |      [string]$_.ToLower()
     |      ~~~~~~~~~~~~~~~~~~~~
     | Method invocation failed because [System.Int32] does not contain a method named 'ToLower'.


Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.installer.yaml

Yaml file created: C:\Users\User\GitHub\winget-pkgs\manifests\r\RARLab\WinRAR\Beta\6.10.3\RARLab.WinRAR.Beta.yaml
Manifest validation succeeded.


Do you want to submit your PR now?
  [Y] Yes
  [N] No

Expected behavior

No error 🤡

Actual behavior

Error 🤡

Environment

YamlCreate.ps1 version 2.0.4

Unique Branch Name throws error while removing manifests

A screenshot is enough to describe the issue.

Retry logic for downloading file

Description of the new feature/enhancement
I am not saying to implement it but should there be a retry logic when downloading InstallerUrl fails.

Additional Reference
https://github.com/vedantmgoyal2009/winget-pkgs-automation/runs/3821800418?check_suite_focus=true#step:3:1199

[Bug]: The process cannot access the file because it is used by another process.

Brief description of your issue

Found a issue when i wanted to update the metadata for Oracle.JDK.17
I've found no workaround for the issue, wingetcreate does not have this issue.

Steps to reproduce

Option 1, 2 or AutoUpdate

PackageIdentifier: Oracle.JDK.17
Version: 17.0.1.0 (AFAIK it does not matter)
Url: https://download.oracle.com/java/17/latest/jdk-17_windows-x64_bin.msi

Expected behavior

For it to work like any other update

Actual behavior

Get-FileHash : The file 'C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp' cannot be read: The process does cannot access the file C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp because it is used by another process.
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:805 char:50
+ ... erSha256'] = (Get-FileHash -Path $script:dest -Algorithm SHA256).Hash
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ReadError: (C:\Users\Esco....1.1.winget-tmp:PSObject) [Write-Error], WriteErrorException    
    + FullyQualifiedErrorId : FileReadError,Get-FileHash

Get-AppLockerFileInformation : The process cannot access the file because it is used by another process. (Exception from H
RESULT: 0x80070020)
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:808 char:41
+ ... e = [string]$(Get-AppLockerFileInformation -Path $script:dest | Selec ...
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-AppLockerFileInformation], FileLoadException
    + FullyQualifiedErrorId : TestAppLockerPolicyCmdlet-FailedProcessingFile,Microsoft.Security.ApplicationId.PolicyManage  
   ment.Cmdlets.GetAppLockerFileInformationCmdlet

Remove-Item : Cannot remove item C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp: The process does cannot access the file  C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp ecause it is used by another process.
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:844 char:13
+             Remove-Item -Path $script:dest
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\Esco....1.1.winget-tmp:FileInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
The file could not be downloaded. Try running the script again
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:802 char:13
+             throw [System.Net.WebException]::new('The file could not  ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], WebException
    + FullyQualifiedErrorId : The file could not be downloaded. Try running the script again

Environment

Latest YamlCreate update as of 2021-07-17

PowerShell 5 Version          : 5.1.22000.65
PowerShell 7 Version          : 7.1.5

Windows Terminal Version      : 1.11.2921.0
Tabby Version                 : 1.0.159

Windows Package Manager Manifest Creator v0.4.1.1

[Bug]: Quick Update and Auto Upgrade removes any ProductCode

Brief description of your issue

I just noticed YamlCreate version 2.0.2 keeps removing the ProductCode when using the Quick Update and Auto Upgrade function (non MSI ProductCodes)

Steps to reproduce

Select Mode:

  [1] New Manifest or Package Version
  [2] Quick Update Package Version (Note: Must be used only when previous version's metadata is complete.)
  [3] Update Package Metadata
  [4] New Locale
  [5] Remove a manifest
  [Q] Any key to quit

Selection: 2

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: Pidgin.Pidgin

[Required] Enter the version. for example: 1.33.7
Version: 2.14.8
Found Existing Version: 2.14.7
Installer Entry #1:

        Architecture: x86
        InstallerType: nullsoft
        Scope: machine


[Required] Enter the download url to the installer.
Url: https://sourceforge.net/projects/pidgin/files/Pidgin/2.14.8/pidgin-2.14.8-offline.exe/download

Expected behavior

Installers:
- Architecture: x86
  InstallerUrl: https://sourceforge.net/projects/pidgin/files/Pidgin/2.14.8/pidgin-2.14.8-offline.exe/download
  InstallerSha256: B237DE10D4FE5D44EABE97A7640D2A74B4D722A7CB2376CF5DF2BE632EDA3F51
  ProductCode: 'Pidgin'

Actual behavior

Installers:
- Architecture: x86
  InstallerUrl: https://sourceforge.net/projects/pidgin/files/Pidgin/2.14.8/pidgin-2.14.8-offline.exe/download
  InstallerSha256: B237DE10D4FE5D44EABE97A7640D2A74B4D722A7CB2376CF5DF2BE632EDA3F51

Environment

# Created with YamlCreate.ps1 v2.0.2 $debug=QUSU.7-2-0
from upstream/master

Parameter to give Installer URLs in Quick Update Mode

Description of the new feature/enhancement

After #64 is merged, we can use:

.\YamlCreate.ps1 -PackageIdentifier <PackageIdentifier> -PackageVersion <PackageVersion> -Mode <1..5>

Can we also add a -Urls Parameter so that we can run YamlCreate.ps1 in unattended mode.

Proposed technical implementation details (optional)

.\YamlCreate.ps1 --Urls <installer-url-1> <installer-url-2> <installer-url-3>

OR (if an array is passed)

.\YamlCreate.ps1 --Urls $installer_urls_array

Also, I think that it can be confusing for I'll suggest enabling it only when EnableDeveloperOptions is set to true.

[New Feature]: Force small letters and - between spaces

Description of the new feature/enhancement

The available fields are Commands, Protocols, FileExtensions, Moniker and Tags

I'm a bit unsure about this, so i'd like a little feedback from @jedieaston, @ItzLevvie and maybe @denelon?

Commands, these do most likely never contain spaces, does it need small letters?
Protocols, same as Commands
FileExtensions we could force small letters for consistent sake
Moniker should force both small letters and - between spaces
Tags, we should probably force small letters and - between spaces, but what if the tag is a alternative name?

Proposed technical implementation details (optional)

No response

Need help [not related to yamlcreate.ps1]

@Trenly I have a JSON like this:

[
     {
          "NAME":  "SOFTWARE1",
          "VERSION":  "BETA",
          "REGION":  "US"
     },
     {
          "NAME":  "SOFTWARE2",
          "VERSION":  "CANARY",
          "REGION":  "UK"
     }
]

I have to update the JSON using PowerShell. I have done:

$file = Get-Content -Path "./softwares.json" -Raw | ConvertFrom-Json
$file | % { if ($_.NAME -eq "SOFTWARE1") { $_.VERSION = "RELEASED" } } | ConvertTo-Json | Set-Content -Path "./softwares.json"

I have tried searching on Internet could not find any solution that works in my case. Can you please help?

Sub-command/Switch for opening settings directly

Description of the new feature/enhancement

Instead of users finding the Settings.yaml file manually by browsing through directories, I would like to have a sub-command/switch that would open the Settings file directly in Notepad or any preferred editor. Something like this would work:

YamlCreate.ps1 -settings

Failed to read FileExtensions and Protocols

Brief description of your issue

YamlCreate option 1 failed to read FileExtensions and Protocols (that i know of) from the previous manifest

Steps to reproduce

YamlCreate option 1
PackageID: Opera.OperaGX
PacakgeVersion: 79.0.4143.60
InstallerUrl: https://get.geo.opera.com/pub/opera_gx/79.0.4143.60/win/Opera_GX_79.0.4143.60_Setup_x64.exe

Expected behavior

Catch and output FileExtensions and Protocols

YamlCreate does not handle manifest-level parameters

Brief description of your issue

Some manifests define installer parameters at the manifest level instead of at the installer level. YamlCreate is unable to properly handle these

Expected behavior

Manifest level parameters should be parsed properly

Proposed solution

When parameters are defined at the manifest level, reading of the previous installer manifest should remove them from the manifest level and add them to every installer at the installer level. This will allow for #29 to be more robust in the event any updates are made to installers which would make these parameters unable to be defined at the manifest level after update

[Bug]: Problem with yaml-language-server comment

Brief description of your issue

The script does not write yaml-language-server comment properly in locales other than the en-US.

Steps to reproduce

Generate a manifest with locales:
- en-US
- any other locale
Observe the second locale file and you will find this:
# yaml-language-server: =https://aka.ms/winget-manifest.locale.1.1.0.schema.json
instead of:
# yaml-language-server: $schema=https://aka.ms/winget-manifest.locale.1.1.0.schema.json
That's all.

Expected behavior

# yaml-language-server: **$schema**=https://aka.ms/winget-manifest.locale.1.1.0.schema.json

(put * for attention)

Actual behavior

# yaml-language-server: =https://aka.ms/winget-manifest.locale.1.1.0.schema.json

Environment

YamlCreate v2.0.2

[New Feature]: Download progress

Description of the new feature/enhancement

I'd like a download progressbar when downloading the file, AFAIK this is possible, not sure if it could show download speed or size, but thats not too important, just want to see if its frozen or REALLY slow..

Also, the download time taken seems to be incorrect..

Proposed technical implementation details (optional)

https://stackoverflow.com/questions/21422364/is-there-any-way-to-monitor-the-progress-of-a-download-using-a-webclient-object

https://docs.microsoft.com/en-us/dotnet/api/system.net.webclient.downloadprogresschanged?view=net-6.0

PackageFamilyName detection from previous manifests

Description of the new feature/enhancement

When there is an installer type that requires PackageFamilyName, it can be detected from previous manifests as it is mostly the same for all the versions of a package.

Proposed technical implementation details (optional)

As the script detects other fields from previous manifests, in the same way, the script can detect PackageFamilyName and print it as:

Discover the package family name?
  [F] Find Automatically [Note: This will install the package to find Family Name and then removes it.]
  [M] Manually Enter PackageFamilyName
  [O] Old Value: <value-from-previous-manifest>

The default option can be changed to 'O' and when the script could not find value from previous manifests or it fails to get the value, then the default option should be 'F'

Remove forced en-US if InstallerLocale is null

Description of the new feature/enhancement

Since some people think the forced en-US InstallerLocale is causing Installation issues i think we should remove it

Proposed technical implementation details (optional)

Moniker is not valid in Locale schema

Do not add moniker to locale files if it is not intended to exist

Quick update not updating SignatureSha256

Create issues related to the winget.exe client here

Brief description of your issue

Quick update does not update SignatureSha256
microsoft#28201

Steps to reproduce

Expected behavior

Actual behavior

Environment

[winget --info]
Windows Package Manager version
Windows: Windows.Desktop version
Package: Microsoft.DesktopAppInstaller version

Any other software?

"Test your Manifest in Windows Sandbox" prompt

Brief description of your issue

I am still being prompted for testing my manifests in Windows Sandbox after adding AlwaysTestManifests: false in YamlCreate script settings.

Steps to reproduce

Add AlwaysTestManifests: false in Settings.yaml.
Create or update any manifest using the script.
The script stills prompts you for testing the manifest in Sandbox.

Expected behavior

The script should skip "Test your Manifest in Windows Sandbox" prompt as the documentation says:

# This setting allows you to **skip the prompt** to test your manifest in windows sandbox
# If this value is set to true, all manifests will be tested by default
AlwaysTestManifests: false

Actual behavior

The script still prompts and waits for the user to enter choice.

Screenshot

Ensure All URL's return 200

Description of the new feature/enhancement

Validate that fields such as PublisherURL, CopyrightURL, SupportURL, etc return a valid status code

Proposed technical implementation details (optional)

Use `FileVersion` as suggested version number?

Description of the new feature/enhancement

I just found something out and even if it can't make 2.0, I think it's worth noting for the future if anyone feels like implementing it (maybe I will)..

The ~~FileVersion~~ ProductVersion attribute is often the same as the ARP version number, and it's super easy to get in PowerShell.

S C:\Users\easton> iwr https://github.com/git-for-windows/git/releases/download/v2.33.1.windows.1/Git-2.33.1-64-bit.exe -OutFile .\git.exe
PS C:\Users\easton> (Get-Item .\git.exe).VersionInfo

ProductVersion   FileVersion      FileName
--------------   -----------      --------
2.33.1       ... 2.33.1.1     ... C:\Users\easton\git.exe


PS C:\Users\easton>

YamlCreate should be able to do this for the user, so that they can hand it a URL (or URLs) for an update and it can handle the rest. wingetcreate already does something like this too.

Proposed technical implementation details (optional)

Just do Get-Item on the file, and look to see if ProductVersion is set. If it is, either suggest that they use that number, or if it's a quick update, then use that number by default.

Rare InstallerSwitches issue

Brief description of your issue

Some manifests are structured and preferred like this

InstallerSwitches:
  Silent: /silent
  SilentWithProgress: /runimmediately
- Architecture: x64
  Scope: user
  InstallerUrl: https://get.geo.opera.com/pub/opera_gx/79.0.4143.60/win/Opera_GX_79.0.4143.60_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB
  InstallerSwitches:
    Custom: /allusers=0 /launchbrowser=0 /setdefaultbrowser=0 /enable-installer-stats=0 /enable-stats=0
- Architecture: x64
  Scope: machine
  InstallerUrl: https://get.geo.opera.com/pub/opera_gx/79.0.4143.60/win/Opera_GX_79.0.4143.60_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB
  InstallerSwitches:
    Custom: /allusers=1 /launchbrowser=0 /setdefaultbrowser=0 /enable-installer-stats=0 /enable-stats=0

Steps to reproduce

YamlCreate option 2

PackageName: Opera.Opera
PackageVersion: 79.0.4143.66
PackageUrl: https://get.geo.opera.com/pub/opera/desktop/79.0.4143.66/win/Opera_79.0.4143.66_Setup_x64.exe
PackageUrl: https://get.geo.opera.com/pub/opera/desktop/79.0.4143.66/win/Opera_79.0.4143.66_Setup.exe

Expected behavior

InstallerSwitches:
  Silent: /silent
  SilentWithProgress: /runimmediately
- Architecture: x64
  Scope: user
  InstallerUrl: https://get.geo.opera.com/pub/opera_gx/79.0.4143.60/win/Opera_GX_79.0.4143.60_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB
  InstallerSwitches:
    Custom: /allusers=0 /launchbrowser=0 /setdefaultbrowser=0 /enable-installer-stats=0 /enable-stats=0
- Architecture: x64
  Scope: machine
  InstallerUrl: https://get.geo.opera.com/pub/opera_gx/79.0.4143.60/win/Opera_GX_79.0.4143.60_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB
  InstallerSwitches:
    Custom: /allusers=1 /launchbrowser=0 /setdefaultbrowser=0 /enable-installer-stats=0 /enable-stats=0

Actual behavior

InstallerSwitches:
  Silent: /silent
  SilentWithProgress: /runimmediately
- Architecture: x64
  Scope: user
  InstallerUrl: https://get.geo.opera.com/pub/opera/desktop/79.0.4143.66/win/Opera_79.0.4143.66_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB
- Architecture: x64
  Scope: machine
  InstallerUrl: https://get.geo.opera.com/pub/opera/desktop/79.0.4143.66/win/Opera_79.0.4143.66_Setup_x64.exe
  InstallerSha256: 3EC1816E7FADB207B14AB0327F0EE7AD94D015A863A04901658B79B4F3FC7FEB

[New Feature]: Platform detection

Description of the new feature/enhancement

This one should probably be pretty easy tbh, any appxbundles should be tagged as - Windows.Universal while the rest gets tagged as - Windows.Desktop

Alternatively take a look at how wingetcreate does it

Proposed technical implementation details (optional)

No response

YamlCreate Settings for Linux

Description of the new feature/enhancement

Some users would like to work with Linux OS. Hence, YamlCreate settings should be supported on Linux too.