You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if il-repack intends to be a drop-in replacement for ilmerge. I had a quick look at the readme and the wiki, and I can't find a migration guide or known differences list.
Tests that ran the merged/repacked nuget.exe were failing, relating to a type provided in /AllowDup.
It turns out NuGet.exe uses NuGet.Core.dll which has an old implementation of NuGetFramework, and the repo contains the current implementation in the NuGet.Frameworks project. Basically, it appears that ilmerge was taking NuGetFramework from NuGet.Frameworks.dll, whereas ilrepack.exe was taking it from NuGet.Core.dll, given all the same arguments.
We were generating the ilmerge/ilrepack arguments from an MSBuild <BuildArtifacts Include="$(OutDir)\*.dll" />, so taking them alphabetically, hence ilmerge was taking the later assembly with the AllowDup types, but ilrepack was taking the first. I didn't validate what happens with ilmerge's output after moving NuGet.Core.dll's order, but after moving it ilrepack.exe appears to be building a nuget.exe that is passing tests that failed previously.
Activity
KirillOsenkov commentedon Aug 26, 2025
I'd say just specify all assemblies to be merged explicitly and in the correct order, it will help with the determinism.
zivkan commentedon Aug 26, 2025
What is the "correct order"? The order that worked for ilmerge doesn't work for ilrepack.