.NET 6 WPF project won't build

• 
  Hi @lukasz at this time Smartassembly 8 doesn't yet support .Net 6. The team are aware that support will be ending for .Net 5 soon and are working on an update which introduces support. We do not yet know their intended release date.

  Ben_P April 07, 2022 16:08

  - 0 +
• 
  Thank you for your patience.
   
  Smart Assembly v8.1.1 now provides .Net 6 support.
  Download
  Release notes
  

  Ben_P July 20, 2022 14:40

  - 0 +
• 
  I'm getting exactly the same error using SA 8.1.1.4963. Attaching my solution together with SA project file. Can someone at your end look into this?

  
  

  To repro:

  1. Build the WPFdotNET6 project in Release mode.

  2. Build the SA project -> error.
  

  lukasz July 21, 2022 13:29

  - 0 +
• 
  Any news? Were you guys able to reproduce? This is extremely urgent for us right now.
  

  lukasz July 27, 2022 11:20

  - 0 +
• 
  Hello @lukasz,
  
  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.

  Peter_Laws August 03, 2022 11:51

  - 0 +
• 
  As a temporary work around, you may be able to overcome the issue by either
  
  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.

  Peter_Laws August 09, 2022 13:02

  - 0 +
• 
  As far as I can tell the problem is not with finding the assembly file, so the MandatoryPath/HintPath approach does not solve it. The path visible in the error message is correct and the DLL does exist there. I've tried specifying it as a mandatory path and the result is the same.

  
  

  SA knows where the assembly file is, but for some reason won't load its contents.

  
  

  Any other workaround suggestions? Any ETA on an update that fixes the problem?
  

  lukasz August 15, 2022 09:51

  - 0 +
• 
  I'm getting almost exactly the same error -- also on WindowsBase.dll:
  

  
  

  
  
  

  - SmartAssembly 8.1.2.4975

  - ASP.NET Core 6.0.11.22523 (x86)

  - Desktop Runtime 6.0.11.31823 (x86)

  
  

  - WPF .NET 6.0 app; entire FolderProfile.pubxml looks like this:

  <?xml version="1.0" encoding="utf-8"?>

  <Project>

    <PropertyGroup>

      <Configuration>Release</Configuration>

      <Platform>Any CPU</Platform>

      <PublishDir>..\..\Publish_Files</PublishDir>

      <TargetFramework>net6.0-windows10.0.17763</TargetFramework>

      <RuntimeIdentifier>win-x86</RuntimeIdentifier>

      <DebugType>embedded</DebugType>

  
  

      <SelfContained>false</SelfContained>

      <PublishSingleFile>false</PublishSingleFile>

      <PublishReadyToRun>false</PublishReadyToRun>

  
  

      <PublishTrimmed>false</PublishTrimmed>

      <PublishProtocol>FileSystem</PublishProtocol>

      <Verbosity>minimal</Verbosity>

    </PropertyGroup>

  </Project>

  
  My "dotnet publish" build log shows "WindowsBase.dll" many, many times, and always in the same path shown in the error message:

  
  

  "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.11\ref\net6.0\WindowsBase.dll"

  
  

  I added the "MandatoryPath" entry to my .saproj file so that line looks like:

  
  

  <Assembly AssemblyName="WindowsBase, Culture=neutral, PublicKeyToken=31bf3856ad364e35" MandatoryPath="C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.11\ref\net6.0\WindowsBase.dll">

  
  

  Changed "MandatoryPath" to "HintPath" and got the same error. Tried it again with BOTH "MandatoryPath" and "HintPath" and got the same error.

  
  

  Spent numerous hours back at "Project Settings" disabling all other features, one by one, until I nailed it down to the first checkbox in the "Obfuscation" group. The error only appears when "Obfuscation" is checked -- and that's the main feature I really need to be working. Only "Selected Software" is populated; no other features are enabled INCLUDING no assemblies checked in "Dependencies Merging" nor in "Dependencies Embedding".

  
  

  ONE thing I noticed is that my project is for x86, but this error message says "C:\Program Files\..." not "(x86)". All my .csproj files have this under 'Release|AnyCPU':
  

  
  

  <PlatformTarget>x86</PlatformTarget>

  
  

  ...however "x86" doesn't appear anywhere in my .saproj file. So... hmmm...
  

  
  

  Thoughts? Questions? Answers?  :-)
  

  
  

  Many thanks in advance!

  
  

  
  

  JeffElliott December 02, 2022 20:08

  - 0 +
• 
  Hello JeffElliott,
  
  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.

  Peter_Laws December 05, 2022 08:21

  - 0 +
• 
  Can be (temporarily) resolved by setting MandatoryPath to
  

  
  

  C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.18

  
  

  instead of
  

  
  

  C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.18
  

  
  
  
  

  Stevie1 August 25, 2023 09:17

  - 0 +
• 
  Good morning,
  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?

  Peter_Laws December 05, 2023 09:52

  - 0 +
• 
  I'm guessing this is why our builds are now failing with this exception?
  
  

  PSnape December 06, 2023 10:54

  - 0 +
• 
  This one is resolved for us.

  
  

  @PSnape Yours is a different issue.
  

  Stevie1 December 06, 2023 10:59

  - 0 +
• 
  Yes agreed, @PSnape, a separate issue for the invalid memory would be appropriate please.

  Peter_Laws December 06, 2023 11:03

  - 0 +

Add comment

Please sign in to leave a comment.