IncludeAssets=all advice causes problems with NuGet packages about cswin32 HOT 7 CLOSED

The missing dependencies seems like a valid report. Thanks for sharing.
I can't see what that has to do with the IncludeAssets metadata though. It seems more related to the PrivateAssets metadata which you also call out.
Am I missing something?

from cswin32.

I can't see what that has to do with the IncludeAssets metadata though.

The documentation in the README suggests setting IncludeAssets=all (by removing the auto-generated metadata). This suggestion can lead to broken NuGet packages. Something should probably be done about this suggestion to make it less problematic, either by amending it, or adding build targets to warn on this specific situation, or perhaps something else (I'm not really sure).

from cswin32.

I don't yet understand how removing IncludeAssets metadata breaks anything. The specific break you speak of in the description relates to missing references to System.Memory and System.Runtime.CompilerServices.Unsafe. Those don't propagate to your own consumers automatically when you set PrivateAssets=all. That's not the same thing as IncludeAssets=all.

from cswin32.

Yes, but without setting IncludeAssets=All, you cannot use those dependencies, so it does not matter that they don't flow. You don't get access to System.Memory so you can't introduce an assembly reference to it. The source generator would, of course, like to use these dependencies--that's why you suggest setting it in the first place. But it causes problems in some instances (like this one).

from cswin32.

Ah, OK I get it now. And at least in some cases, the source generator is smart enough to avoid emitting APIs that depend on these when they aren't referenced. Thank you for your patience in helping me understand.
I'm still not sure what to do about it. I'll have to ponder the trade-offs.

from cswin32.

I also ran into this issue.
I was using an assembly reference and Visual Studio/msbuild did not copy over System.Runtime.CompilerServices.Unsafe.dll to the output folder.
For example, Project1 has a NuGet package reference to CsWin32, and Project2 has an assembly reference to Project1.
I expected System.Runtime.CompilerServices.Unsafe.dll to be copied to Project2's output folder.

This is the error I was getting:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.Span`1.GetPinnableReference()
   at Windows.Win32.PInvoke....  in C:\Solution1\Project1\Microsoft.Windows.CsWin32\Microsoft.Windows.CsWin32.SourceGenerator\Windows.Win32.PInvoke.....dll.g.cs:line x
   at Project1.Class1.Method1(...) in C:\Solution1\Project1\Class1.cs:line x
   at Project2.Program.Main(...) in C:\Solution2\Project2\Program.cs:line x

=== Pre-bind state information ===
LOG: DisplayName = System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Solution2/Project2/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\Solution2\Project2\bin\Project2.exe.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Attempting download of new URL file:///C:/Solution2/Project2/bin/System.Runtime.CompilerServices.Unsafe.DLL.
...

As a work-around I had to add a reference to the System.Runtime.CompilerServices.Unsafe NuGet package in Project2.

Microsoft.Windows.CsWin32 v0.3.49-beta references System.Runtime.CompilerServices.Unsafe v6.0.0, so I also referenced that specific version.

I also had to add an assembly binding redirection in Project2.exe.config, or have Visual Studio/msbuild do it automatically by setting the AutoGenerateBindingRedirects property to true in Project2.csproj:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Thank you.

from cswin32.

I'd love to get you folks to validate the effectiveness of my fix in #1172.

from cswin32.