-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native assets are not copied to bin for net472 app if any referenced package uses netstandard2.0 #3031
Comments
@peterhuene can you take a look? |
With the provided project file: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net472</TargetFramework>
<LangVersion>latest</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="2.6.1" />
<PackageReference Include="Microsoft.DiaSymReader.Converter" Version="1.1.0-beta1-62318-01" />
<PackageReference Include="NuGet.PackageManagement" Version="4.5.0" />
<PackageReference Include="ShellProgressBar" Version="4.0.0" />
<PackageReference Include="System.Reflection.Metadata" Version="1.5.0" />
</ItemGroup>
</Project> I get When setting |
@jnm2 I'm going to close this issue as by design. With the .NET Core SDK when targeting .NET Framework TFMs, you need to specify Please reopen if you disagree with my assessment. Thank you! |
I tried this with both |
I also used the property in the project file; shouldn't make a difference in this case. The .NET Core SDK I was using to repro was 2.1.504 (I tried to match the version I think you're using). |
@peterhuene Thanks for looking at this. I should have mentioned up from that I tried <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net472</TargetFramework>
<LangVersion>latest</LangVersion>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="2.10.0" />
<PackageReference Include="Microsoft.DiaSymReader.Converter" Version="1.1.0-beta1-63314-01" />
<PackageReference Include="NuGet.PackageManagement" Version="4.9.4" />
<PackageReference Include="ShellProgressBar" Version="4.2.0" />
<PackageReference Include="System.Reflection.Metadata" Version="1.6.0" />
</ItemGroup>
</Project>
By "with the .NET Core SDK," do you mean the SDK-style csproj? I'm building from within Visual Studio (2019 RC.1 SVC1), not the command line. One more thing. Why is it by design to copy the native DLL when no platform target is specified unless there is a package reference with a netstandard2.0 target? It doesn't feel right to have the discrepancy. |
@peterhuene Ah, the number 2.1.504 came up when I used http://msbuildlog.com to try to get at the source of the problem. It appears to behave exactly the same as when building within VS2019 RC.1 SVC1. |
Mind if I reopen since |
Sure, I'll try to reproduce inside of Visual Studio then. |
Are you able to reproduce from the command line with |
I hadn't tried before but yes, actually. |
|
I see I had been running VS2017's MSBuild.exe from MSBuild Structured Log Viewer. Maybe that explains the 2.1.504. |
I'm also unable to reproduce with that project (with What's the contents of your |
Does it matter that I have this nuget.config? <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="MyGet (symreader)" value="https://dotnet.myget.org/F/symreader/api/v3/index.json" />
<add key="MyGet (symreader-native)" value="https://dotnet.myget.org/F/symreader-native/api/v3/index.json" />
<add key="MyGet (symreader-converter)" value="https://dotnet.myget.org/F/symreader-converter/api/v3/index.json" />
</packageSources>
</configuration> |
The If you don't mind, could you email me a binlog when building this project at pehuene@microsoft.com? Before you do so, though, please read this document regarding sharing binlogs. Specifically, the fact that your environment variables and local file paths will be recorded in the log. If either contain sensitive information, please don't share the binlog with me. |
Sorry, I didn't realize that the project provided was the "working" one. If I reference Now that I'm able to reproduce, I'll look into it. No need for the binlog. Thanks! |
Oh, no! I'm sorry! Thanks! I had the repro down to a single file: repro.csproj<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.DiaSymReader.Converter" Version="1.1.0-beta1-63314-01" />
<PackageReference Include="ShellProgressBar" Version="4.2.0" />
</ItemGroup>
</Project> |
So the native asset is disappearing from the restore graph for some reason. When "Microsoft.DiaSymReader.Native/1.7.0": {
"type": "package",
"native": {
"runtimes/win-x64/native/Microsoft.DiaSymReader.Native.x64.dll": {}
},
"build": {
"build/_._": {}
}
}, When we reference "Microsoft.DiaSymReader.Native/1.7.0": {
"type": "package",
"build": {
"build/Microsoft.DiaSymReader.Native.props": {}
}
},
Oddly,
Creating an empty I see dotnet/roslyn#26160 that appears to be related. What I don't understand, though, is how migrating one package reference from @nguerrera @dsplaisted any ideas? |
@peterhuene I looked at some of the packages involved, and my guess is that because ShellProgressBar has a package dependency on the NETStandard.Library package for its .NET Standard 1.3 version, the "platforms" package with the RID graph (Microsoft.NETCore.Platforms) is being brought in. The .NET Standard 2.0 version of ShellProgressBar doesn't have the NETStandard.Library package dependency anymore (because we decided it shouldn't be represented that way), which also means it isn't getting the platforms package in the graph, which means it has no RID graph to understand the RIDs. The workaround is probably to add an explicit PackageReference to the Microsoft.NETCore.Platforms platforms. |
Ah, that makes sense. Thanks for clearing that up. That can be terribly confusing for users that just bump package versions and assets disappear like that. @jnm2 adding a package reference to |
@jnm2 if this is a suitable workaround for you, please let me know and we can resolve this issue. |
@peterhuene This workaround is fine. If this a problem in the ShellProgressBar package, what is the best link I can give the author to explain the problem and how to fix it? (Or is this a point-in-time design problem with the SDK?) |
@jnm2 it's not a problem with the To restore native assets, NuGet needs a RID graph. This is what tells NuGet that RID When you target a However, when you referenced a Does that make sense? Adding an explicit reference should solve the problem and is a necessary step when building an application with a I'm going to close this issue by design for now. Thank you for your assistance in helping us to identify the issue. |
@peterhuene Thanks, that helps. The fix is not very discoverable and the package reference I'm adding isn't very self-explanatory, but I might remember next time. Is there hope for this to just work in the future? |
I totally agree that the fix is not discoverable. @livarcocc @nguerrera @dsplaisted @KathleenDollard any thoughts on how we could improve upon this experience for our users? Is there documentation surrounding building |
Perhaps NuGet could warn that native assets were found in a package but the RID graph was not resolved? |
@peterhuene For .NET Core 3.0, we're bundling the RID graph with the SDK. We hope to be able to pass that graph to NuGet, which would mean the platforms package wouldn't need to be in the package dependency graph anymore. |
And that's regardless of TFM, right? Sounds like a solution to me. Thanks! |
….2 (dotnet#3031) - Microsoft.DotNet.Cli.Runtime - 3.1.100-preview1.19502.2
Remove packages.config as per dotnet/sdk#3031 (RID now available)
Full description is here: dotnet/symreader-converter#151
I suspect this is an SDK bug in
C:\Program Files\dotnet\sdk\2.1.504\Sdks\Microsoft.NET.Sdk\tools\net46\Microsoft.NET.Build.Tasks.dll
; see dotnet/symreader-converter#151 (comment).My workaround for now is to add this to the csproj, but it's obviously brittle:
The text was updated successfully, but these errors were encountered: