.NET 6 WPF project won't build
lukasz
Posts: 7 Bronze 1
I know there's no official announcement on .NET 6 support (any news appreciated), but posts in this thread seem to suggest that version 8.1.0.4892 does indeed support it: https://forum.red-gate.com/discussion/88589/net-6-support-in-smartassembly
Trying to use this version of SA to obfuscate a simple WPF .NET 6 test app results in the following error when building the project:
The same app builds fine when target framework is set to .NET 5. A simple .NET 6 console app builds fine too.
Full support for .NET 6 is required as soon as possible. .NET 5 is reaching it's end of support date in a few weeks!
Trying to use this version of SA to obfuscate a simple WPF .NET 6 test app results in the following error when building the project:
The same app builds fine when target framework is set to .NET 5. A simple .NET 6 console app builds fine too.
Full support for .NET 6 is required as soon as possible. .NET 5 is reaching it's end of support date in a few weeks!
Tagged:
Answers
Smart Assembly v8.1.1 now provides .Net 6 support.
Download
Release notes
Yes we've reproduced the behaviour you've described and are presently tracking this on our internal reference SA-2490. Once a fix is released this reference will appear in the release notes, but I'll also make a note to come back here and update you.
Explicitly defining the exact assembly path via MandatoryPath
or
Defining a directory hint path
Please see https://documentation.red-gate.com/sa/troubleshooting/unexpected-behavior-and-technical-questions/how-smartassembly-searches-for-dependencies
I'd expect the former to be more accurate, but if the second option works for you, it will require less effort.
My "dotnet publish" build log shows "WindowsBase.dll" many, many times, and always in the same path shown in the error message:
Thank you for sharing your findings, Smart Assembly should automatically detect the bitness but given the nature of this dependency resolution issue, that could too be compromised.
The issue you'd described (ref SA-2490) is our current focus concurrently with .Net 7 support, we hope to have a release addressing this in the near future.
If you don't need .Net 6 support for your application, you could work around the issue by dropping to a version preceding v8.1.1 where the issue was introduced, while we work on a solution.
Please accept our apologies for the inconvenience this issue has caused.
We've just released Smart Assembly v8.2.0 which substantively overhauls the dependency resolver, please could you update and let us know your findings?