Version exception about clowd.squirrel HOT 10 CLOSED

Yes I was looking at all the First() calls in that function and wondering if that may have been the issue. Thanks for reporting this, I will push an update with a fix soon.

from clowd.squirrel.

I'm not sure how this could happen, can you upload a sample that reproduces the issue? or can you point at the specific line or area of code where the version is duplicated?

from clowd.squirrel.

I'm not sure how this could happen, can you upload a sample that reproduces the issue? or can you point at the specific line or area of code where the version is duplicated?

I honestly cant say. within ValidatedOptionSet the Execute fires off and debugging is lost. when it comes back from that it will validate version number again and thats when its duplicated. Its worth noting I am managing some fairly old software(15ish years) We just recently bumped the dotnet version to 6 which is when we had issues with Squirrel.

After some investigation I realized our nuspec file had a version of 0.0.0.0 which appears to be the source of the issue. However upon removing that I am now seeing the pack correctly packing the file but when it creates a release package the version is once again wrong.

1>[INFO] NugetConsole: Successfully created package 'C:\Users\MYUSERNAME\AppData\Local\SquirrelClowdTemp\tempc\MYAPP.2.4.0.nupkg'.
1>[INFO] Program: Creating release package: C:\Users\MYUSERNAME\Desktop\projects\MYCOMPANY\Releases\MYAPP.1.0.0.nupkg

It should be creating a 2.4.0 release on that last line. This causes the following error

1>[ERRO] System.InvalidOperationException: Sequence contains no matching element
1>   at System.Linq.ThrowHelper.ThrowNoMatchException()
1>   at System.Linq.Enumerable.First[TSource](IEnumerable`1 , Func`2 )
1>   at SquirrelCli.Program.<>c__DisplayClass4_0.<Releasify>b__9(String pkgPath, ZipPackage zpkg) in ./Program.cs:line 225
1>   at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func`2 releaseNotesProcessor, Action`2 contentsPostProcessHook) in ./Internal/ReleasePackage.cs:line 123
1>   at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 193
1>   at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 124
1>   at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
1>   at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
1>   at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 77

Its worth noting once again that switching back to Squirrel.Clowd 2.7.34-pre the exact same setup will run to completion without error.

from clowd.squirrel.

Is there already file called "MYAPP.1.0.0.nupkg" in your Releases directory? Squirrel will attempt to process every file ending in .nupkg in the release folder (this is logic that was handed down from the original Squirrel). Can you try a fresh release (eg. with a brand new/empty Releases directory) using the latest Clowd.Squirrel and confirm that even with an empty Releases directory the pack command fails? If so, it really does look like a bug, but without reproduction steps it may be difficult to track down.

I have also added a guard which will fail the release early on if an invalid 0.0.0 version if provided.

from clowd.squirrel.

Is there already file called "MYAPP.1.0.0.nupkg" in your Releases directory? Squirrel will attempt to process every file ending in .nupkg in the release folder (this is logic that was handed down from the original Squirrel). Can you try a fresh release (eg. with a brand new/empty Releases directory) using the latest Clowd.Squirrel and confirm that even with an empty Releases directory the pack command fails? If so, it really does look like a bug, but without reproduction steps it may be difficult to track down.

I have also added a guard which will fail the release early on if an invalid 0.0.0 version if provided.

Yes i can confirm with an empty releases the same error occurs. (The sequence contains no matching element) I wrongly assumed it was because it was building a 2.4.0 release but looking for a 1.0.0 release. They dont seem to be related at all. I'll dig into this further tomorrow and report back.

from clowd.squirrel.

Can you share the command line arguments you are using to create the package?

from clowd.squirrel.

pack --packId "MYAPP" --packVersion "2.4.0" --packAuthors "ME" --packDirectory $(OutDir) --allowUnaware --setupIcon "MYICON.ico"

from clowd.squirrel.

The issue appears to be rooted in the fact that our binary has been squirrel unaware which has been fine as long as there was no more then one it worked fine in previous squirrel instances. However due to the following code

                    // record architecture of squirrel aware binaries so setup can fast fail if unsupported
                    var pearchs = awareExes
                        .Select(path => new PeNet.PeFile(path))
                        .Select(pe => pe?.ImageNtHeaders?.FileHeader?.Machine ?? 0)
                        .Select(machine => { Utility.TryParseEnumU16<RuntimeCpu>((ushort) machine, out var cpu); return cpu; })
                        .Where(m => m != RuntimeCpu.Unknown)
                        .Distinct()
                        .ToArray();

                    if (pearchs.Length > 1) {
                        Log.Warn("Multiple squirrel aware binaries were detected with different machine architectures: " + String.Join(", ", pearchs));
                    }

                    // CS: the first will be selected for the "package" architecture. this order is important,
                    // because of emulation support. Arm64 generally supports x86/x64 emulation, and x64
                    // often supports x86 emulation, so we want to pick the least compatible architecture
                    // for the package.
                    var archOrder = new[] { /*RuntimeCpu.Arm64,*/ RuntimeCpu.X64, RuntimeCpu.X86 };
                    var pkgarch = archOrder.First(o => pearchs.Contains(o));

squirrel unaware is no longer an option because it checks if the squirrel aware binary matches the architecture needed. This doesnt take into account if the binary is squirrel unaware.

from clowd.squirrel.

Closed by 7273039 and will be in the next pre-release

from clowd.squirrel.

This has been released in 2.8.1-pre.

from clowd.squirrel.