modlist-report does not work after latest update

[Styyx1]

Describe the bug

wabbajack cli still doesn't work for modlist-report (see error below)

Additional Context

windows 11 -- 23H2

Wabbajack Version

Wabbajack 3.7.4.1

Logs

doesn't look like the cli commands get logged so i copy the cli error here instead of a wabbajack log:

C:\WabbajackInstaller\3.7.4.1\cli>wabbajack-cli modlist-report -i "C:\WabbajackInstaller\compiles\Nocturnia\rework\Nocturnia.wabbajack"
00:00:00.000 [INFO] Loading modlist...
Unhandled exception: Nettle.Compiler.NettleRenderException: Exception raised during rendering:

The path '$.Name' does not contain a property named 'Name'.

ModelBinding { Signature = {{$.Name}}, StartPosition = 101, EndPosition = 111, Length = 10, BindingPath = $.Name }
 ---> Nettle.Compiler.NettleRenderException: The path '$.Name' does not contain a property named 'Name'.
   at Nettle.Compiler.TemplateContext.GetPropertyValue(Object model, NettlePath path, String propertyName)
   at Nettle.Compiler.TemplateContext.ResolveNestedValue(Object model, NettlePath path)
   at Nettle.Compiler.TemplateContext.ResolvePropertyValue(String propertyPath)
   at Nettle.Compiler.Rendering.NettleRendererBase.ResolveBindingValue(TemplateContext context, String bindingPath)
   at Nettle.Compiler.Rendering.ModelBindingRenderer.Render(TemplateContext context, CodeBlock block, CancellationToken cancellationToken)
   at Nettle.Compiler.Rendering.BlockCollectionRenderer.RenderBlock(TemplateContext context, CodeBlock block, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at Nettle.Compiler.Rendering.BlockCollectionRenderer.RenderBlock(TemplateContext context, CodeBlock block, CancellationToken cancellationToken)
   at Nettle.Compiler.Rendering.BlockCollectionRenderer.Render(TemplateContext context, CodeBlock[] blocks, CancellationToken cancellationToken)
   at Nettle.Compiler.Rendering.TemplateRenderer.Render(Template template, Object model, CancellationToken cancellationToken)
   at Wabbajack.CLI.Verbs.ModlistReport.ReportTemplate(Object o) in c:\oss\wabbajack\Wabbajack.CLI\Verbs\ModlistReport.cs:line 46
   at Wabbajack.CLI.Verbs.ModlistReport.Run(AbsolutePath input, Boolean browser) in c:\oss\wabbajack\Wabbajack.CLI\Verbs\ModlistReport.cs:line 98
   at System.CommandLine.NamingConventionBinder.CommandHandler.GetExitCodeAsync(Object returnValue, InvocationContext context)
   at System.CommandLine.NamingConventionBinder.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()

[Styyx1]

Add-on to that, not that i expected a different result, but using the wabbajack-cli command via my installed powershell resulted in the same error

[AlexDickerson]

I believe this comes down to how its being published. I'm guessing that the Nettle package is sensitive to the change that was made to how RIDs work in .net 8. https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

I don't have a complete understanding of the mechanics but I'll do my best to explain.

Long story short, certain os/os-version specific libraries don't get pulled in during the build anymore as everything is just 'win-x64/86" rather than "win7-x64", "win8-x64", etc. There's some pretty specific ways you need to publish these projects to ensure all the right DLLs are there in order for this stuff to work.

I could not reproduce this when running from visual studio (which is a good indication this is the kind of problem we're dealing with) but it does reproduce when run from a file published with the scripts the build.bat file.

I could publish a executable that worked with this command though.
.\msbuild C:\Users\Alex\source\repos\wabbajack\Wabbajack.CLI\Wabbajack.CLI.csproj /p:OutputPath=c:\tmp\publish-wj\app\cli /t:publish /p:TargetFramework=net9.0-windows10.0.19041.0 /p:RuntimeIdentifier=win-x64 /p:SelfContained=True

[tr4wzified]

This indeed has to do with dotnet trimming assemblies it shouldn't be trimming on publish. It should've been fixed here though, maybe @halgari publishes it differently?

0d5d163