mirror of
https://github.com/quamotion/dotnet-packaging.git
synced 2026-02-15 05:35:56 +00:00
System.ArgumentException: Specified preset is not supported #49
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @buckstephenh on GitHub (Jun 12, 2019).
Originally assigned to: @qmfrederik on GitHub.
System.ArgumentException: Specified preset is not supported
at Packaging.Targets.IO.XZOutputStream.Write(Byte[] buffer, Int32 offset, Int32 count)
seems to occur with larger project with many nested folders but not sure yet.
@qmfrederik commented on GitHub (Jun 16, 2019):
@buckstephenh Thanks for reporting this. It would be really helpful if you can share project which reproduces this issue.
@qmfrederik commented on GitHub (Dec 5, 2019):
Oddly enough, I can reproduce this when setting a breakpoint around lzma_code, so this appears to be some sort of timing issue.
@qmfrederik commented on GitHub (Dec 10, 2019):
I just got a repro of this on Windows, but haven't seen the issue on Linux. @buckstephenh Did you hit this issue on Windows, too?
@qmfrederik commented on GitHub (Dec 10, 2019):
It looks like the lzma port in VCPKG is buggy or is using a buggy version of lzma; replacing lzma.dll with a copy built directly from https://github.com/xz-mirror/xz/ master works.
@buckstephenh commented on GitHub (Dec 10, 2019):
Sorry I haven’t replied. I switched projects/jobs and haven’t been able to return to this topic. MS also has an issue with single file EXE builds related to duplicate references that are not identified/caught in normal build. Probably not related to this.
@FRvanderVeen commented on GitHub (Feb 24, 2022):
@qmfrederik I run into this issue too. I'm building on Windows. The strange thing is that sometimes the error occurs, but there are also times it doesn't.
Don't now if it helps, but this is the stack trace I see:
Using packaging.targets\0.1.220\build\Packaging.Targets.targets(105,5)
@andyjmorgan commented on GitHub (Jan 19, 2023):
did you manage to find a workaround for this?
@RealOrko commented on GitHub (Feb 16, 2025):
Definitely seeing the same thing on linux using Ubuntu 24.04 with dotnet 9.0. Will post more when I find it.
@RealOrko commented on GitHub (Feb 16, 2025):
So I tried enabling LD_DEBUG=all and found the following.
Everything works as expected. So I think the output from LD_DEBUG is slowing things down enough to confirm the race condition mentioned here. The question is where though?
There is 4 flavours of System.Diagnostics.Process involved in this solution. We should start by harmonising to dotnet 9? Please see screenshot.
@dj3mu commented on GitHub (Sep 2, 2025):
Happens for Deb packages in my case.
The problem seems to appear randomly.
But what I observed is that with three build nodes the problem seems to persist for some time on the same node. Even multiple retries selecting same node fail with the same error. A run on a different node, immediately works.
Few days later, surprisingly the previously working node might start to fail while the other one starts working.
All nodes different physical hardware, all Docker runners using MS SDK image, only one build run per node at a time.
It seems pretty reproducible. But I'm totally puzzled which "condition" triggers this and no clue, why it suddenly disappears again. I'm not able to prove this. But I suspect either of or a combination of load, latencies (during NuGet download?) or caching (of corrupt? artifacts) may be causing this.