I'm running a ASP.NET Core app on the .NET 4.6.1 framework. I have 1 solution with multiple projects in it. All of the projects are class libraries that reference each other via PackageReferences in their .csproj (this way we can build, package and version them independently). However, I want to be able to test their integration with one another without needing to push them up to NuGet first - aka I want to use them as ProjectReferences in the solution, but PackageReferences when building them through my Jenkins build process in order to version the components separately.
When .NET Core was project.json based, this worked fine. I would set the version at the top of the project.json and if a project existed with that version in the solution it would reference it as a project, otherwise it would look for it on my NuGet feed.
The problem with using ProjectReferences is that all project's would get the same version when they are built and sent to NuGet.
Is there any way to do this in csproj? Look for a project reference if it exists, otherwise look at NuGet?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<VersionPrefix>1.3.0</VersionPrefix>
<TargetFramework>net461</TargetFramework>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<AssemblyName>MyProject1</AssemblyName>
<PackageId>MyProject1</PackageId>
<NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MyProject2" Version="1.4.0-*" />
<PackageReference Include="Microsoft.AspNetCore.Http" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="1.1.1" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Hosting.Abstractions" Version="1.1.1" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
Above is an example, I would like MyProject2 to be referenced by ProjectReference if 1.4.0 exists in the solution.
I recently was try to do the same thing and couldn't find the answer but figured out something that works for me. You can use the Exists condition in MSBuild for the csproj to include the project reference when its there and exclude the package reference if its there:
<Project Sdk="Microsoft.NET.Sdk">
...
<ItemGroup>
<PackageReference Condition="!Exists('[path-to-project].csproj')" Include="[package-id]" Version="[pacakage-version].*" />
</ItemGroup>
...
<ItemGroup>
<ProjectReference Condition="Exists('[path-to-project].csproj')" Include="[path-to-project].csproj" />
</ItemGroup>
...
</Project>
Related
In my VS 2022 solution I have two projects, a roslyn generator and a console app that I use to test the generator and other stuff.
Whenever I try to build the test app I get this warning:
CS8784: Generator 'Generator' failed to initialize. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'FileNotFoundException' with message 'Could not load file or assembly 'Microsoft.SqlServer.ConnectionInfo, Version=16.200.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.'
So it seems that I'm missing an assembly.
But actually Microsoft.SqlServer.ConnectionInfo.dll is present in my nuget package directory (under .nuget\packages\microsoft.sqlserver.sqlmanagementobjects\161.47021.0\lib\netstandard2.0, netcoreapp3.1 and net462) and has the right version for all three frameworks.
I also tried to reference assembly path in visual studio, and it didn't give a different result.
Whatever program is running the generator don't seem to be able to resolve it.
Moreover, my test app references the exact the exact same packages and run without any problem.
My guess is that running the generator manually (with my own entrypoint) would allow me to see where it tries to find the assemblies, but I have no idea how to do that with a generator.
Also one of the package gives me this warning for the generator but not the test app:
NU1701: Package 'Microsoft.SqlServer.Management.SmoMetadataProvider 161.47021.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
I would like to know how I can make my generator work, or at least, have some way to debug it to get more information on why it fails to load the assembly.
Here are the .csproj for the generator:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Nullable>enable</Nullable>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath>
<IsRoslynComponent>true</IsRoslynComponent>
<LangVersion>latest</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis" Version="4.2.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.2.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.SqlServer.Management.SmoMetadataProvider" Version="161.47021.0" />
<PackageReference Include="Microsoft.SqlServer.Management.SqlParser" Version="160.22506.0" />
</ItemGroup>
<ItemGroup>
<None Include="$(OutputPath)\$(AssemblyName).dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
</ItemGroup>
</Project>
and for the test console app:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.SqlServer.Management.SmoMetadataProvider" Version="161.47021.0" />
<PackageReference Include="Microsoft.SqlServer.Management.SqlParser" Version="160.22506.0" />
<PackageReference Include="System.Data.SqlClient" Version="4.8.3" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\sql_modeler.generator\sql_modeler.generator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
<ProjectReference Include="..\sql_modeler\sql_modeler.csproj" />
</ItemGroup>
</Project>
You can find the full source code at https://github.com/myblindy/GrimBuilding/tree/efcore (the efcore branch).
I understand that source generators can't automatically harvest dependencies from nuget packages and you have to use a clunky work-around to get it to work, and I have done so. This is my source generator project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>preview</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.0.0-1.final" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.2" PrivateAssets="all" />
<PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.*-*" GeneratePathProperty="true" PrivateAssets="all" />
<PackageReference Include="Microsoft.Data.Sqlite.Core" Version="6.*-*" GeneratePathProperty="true" PrivateAssets="all" />
<PackageReference Include="SQLitePCLRaw.lib.e_sqlite3" Version="2.*-*" GeneratePathProperty="true" PrivateAssets="all" />
<PackageReference Include="SQLitePCLRaw.provider.e_sqlite3" Version="2.*-*" GeneratePathProperty="true" PrivateAssets="all" />
</ItemGroup>
<PropertyGroup>
<GetTargetPathDependsOn>$(GetTargetPathDependsOn);GetDependencyTargetPaths</GetTargetPathDependsOn>
</PropertyGroup>
<Target Name="GetDependencyTargetPaths">
<ItemGroup>
<TargetPathWithTargetPlatformMoniker Include="$(PKGSQLitePCLRaw_bundle_e_sqlite3)\lib\netstandard2.0\SQLitePCLRaw.batteries_v2.dll" IncludeRuntimeDependency="false" />
<TargetPathWithTargetPlatformMoniker Include="$(PKGSQLitePCLRaw_provider_e_sqlite3)\lib\netstandard2.0\SQLitePCLRaw.provider.e_sqlite3.dll" IncludeRuntimeDependency="false" />
<TargetPathWithTargetPlatformMoniker Include="$(PKGSQLitePCLRaw_lib_e_sqlite3)\runtimes\win-x64\native\e_sqlite3.dll" IncludeRuntimeDependency="false" />
<TargetPathWithTargetPlatformMoniker Include="$(PKGMicrosoft_Data_Sqlite_Core)\lib\netstandard2.0\Microsoft.Data.Sqlite.dll" IncludeRuntimeDependency="false" />
</ItemGroup>
</Target>
</Project>
Since there also isn't any transitive support, I added every nested Microsoft.Data.Sqlite package one by one, generated their path property and referenced it using TargetPathWithTargetPlatformMoniker. It all works until I get to the native e_sqlite3.dll, if I use TargetPathWithTargetPlatformMoniker with it, it tries to reference it as a managed library, and it fails as expected:
4>CSC : warning CS8034: Unable to load Analyzer assembly C:\Users\meep.nuget\packages\sqlitepclraw.lib.e_sqlite3\2.0.5-pre20210521085756\runtimes\win-x64\native\e_sqlite3.dll : PE image doesn't contain managed metadata.
So given that the path is found, is there a different tag I can use to make the main project copy the e_sqlite3.dll file so the analyzer can use it?
Taken from .NET project SDK overview:
Build events
In SDK-style projects, use an MSBuild target named PreBuild or PostBuild and set the BeforeTargets property for PreBuild or the AfterTargets property for PostBuild.
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
<Exec Command=""$(ProjectDir)PreBuildEvent.bat" "$(ProjectDir)..\" "$(ProjectDir)" "$(TargetDir)"" />
</Target>
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="echo Output written to $(TargetDir)" />
</Target>
Maybe you can move the file manually using one of these directives?
There's also this:
<Content Include="$(OutputPath)\*.dll;$(OutputPath)\*.json">
<Pack>true</Pack>
<PackagePath>build\</PackagePath>
</Content>
Could you move the file like that?
I have a .NET Standard 2.0 project that is being packed into a NuGet package upon build. (Using the .csproj approach to generate a package on build) This project contains a file ApiClientSettings.json, which I want to copy to the output directory of the consuming project.
I have the following in my .csproj:
<ItemGroup>
<Content Include="ApiClientSettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<PackageCopyToOutput>true</PackageCopyToOutput>
</Content>
</ItemGroup>
According to MS documentation, the PackageCopyToOutput attribute should do exactly what I want to do, but it does not seem to work when I install the package into a .NET Framework project. (Works perfectly for .NET Core project)
Am I missing anything else?
Here is my entire .csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<IsPackable>true</IsPackable>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
<AllowedOutputExtensionsInPackageBuildOutputFolder>
$(AllowedOutputExtensionsInPackageBuildOutputFolder);.json
</AllowedOutputExtensionsInPackageBuildOutputFolder>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<IncludeContentInPack>true</IncludeContentInPack>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<OutputPath></OutputPath>
</PropertyGroup>
<ItemGroup>
<Content Include="ApiClientSettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<PackageCopyToOutput>true</PackageCopyToOutput>
</Content>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.7" />
<PackageReference Include="Microsoft.Extensions.Configuration" Version="3.1.5" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="3.1.5" />
<PackageReference Include="Microsoft.Extensions.Http" Version="3.1.5" />
<PackageReference Include="Newtonsoft.Json" Version="12.0.3" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\DbModelLibrary\DbModelLibrary.csproj">
<ReferenceOutputAssembly>true</ReferenceOutputAssembly>
<IncludeAssets>DbModelLibrary.dll</IncludeAssets>
</ProjectReference>
</ItemGroup>
<Target DependsOnTargets="ResolveReferences" Name="CopyProjectReferencesToPackage">
<ItemGroup>
<BuildOutputInPackage Include="#(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))" />
</ItemGroup>
</Target>
</Project>
Here is my generated .nuspec file aswell:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>Iso17025ApiClient</id>
<version>1.0.0</version>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Microsoft.AspNet.WebApi.Client" version="5.2.7" exclude="Build,Analyzers" />
<dependency id="Microsoft.Extensions.Configuration" version="3.1.5" exclude="Build,Analyzers" />
<dependency id="Microsoft.Extensions.Configuration.Json" version="3.1.5" exclude="Build,Analyzers" />
<dependency id="Microsoft.Extensions.Http" version="3.1.5" exclude="Build,Analyzers" />
<dependency id="Newtonsoft.Json" version="12.0.3" exclude="Build,Analyzers" />
</group>
</dependencies>
<contentFiles>
<files include="any/netstandard2.0/appsettings.json" buildAction="Content" copyToOutput="true" />
</contentFiles>
</metadata>
</package>
I am adding the file structure of the consuming .NET Framework apps:
When the NuGet package reference is used, the file gets copied to the output directory, from the global package directory, but does not get added to the solution.
If the packages.config is used, the file gets copied to the solution but does not get marked as "Copy to Output" even though it is specified to do so in the NuGet package.
This probably has to do with the changes between pacakges.config and PackageReference NuGet package management? The difference between contentFiles and content probably.
What still confuses me, is that the .NET Core apps use PackageReference and the behaviour is different as with the .NET Framework apps.
In the .NET Core apps the appsettings.json is added to the solution AND marked as "Copy to Output".
I would like the users to have roughly the same experience with the package no matter which target framework they are using. (I do not want them to manually add an appsettings.json JUST because they are using .NET Framework. Is this avoidable in some way?
I have tried this in plain projects with these lines from your sample and it works.
<ItemGroup>
<Content Include="ApiClientSettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<PackageCopyToOutput>true</PackageCopyToOutput>
<PackagePath>contentFiles\any\any\;content</PackagePath>
</Content>
</ItemGroup>
However, there is something wrong with your generated NuSpec. This line in the contentFiles tag is wrong.
<files include="any/netstandard2.0/ApiClientSettings.json" buildAction="Content" copyToOutput="Always" />
According to your project file, instead of netstandard2.0 it should be any and the attribute for copyToOutput allows for true or false, but not Always. The files tag should look like this.
<files include="any/any/ApiClientSettings.json" buildAction="Content" copyToOutput="true" />
Maybe there are leftovers from testing your package and your caches are corrupted, because your NuSpec does not match the given project file. In Visual Studio you can clear the caches with Tools > Options > NuGet Package Manager > General > Clear all caches or delete your global .nuget folder contents.
Just for you to compare, this is the library project.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<ItemGroup>
<None Remove="ApiClientSettings.json" />
</ItemGroup>
<ItemGroup>
<Content Include="ApiClientSettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<PackageCopyToOutput>true</PackageCopyToOutput>
<PackagePath>contentFiles\any\any\;content</PackagePath>
</Content>
</ItemGroup>
</Project>
This is the PackageReference in both .NET Framework and .NET Core projects.
<ItemGroup>
<PackageReference Include="ClassLibrary" Version="1.0.0" />
</ItemGroup>
The behavior you recognize between PackageReference and packages.config is because the latter does not support contentFiles. You will have to resort to using the content folder and a custom MS Build .targets file, like this.
I would like the users to have roughly the same experience with the package no matter which target framework they are using.
NuGet packages behave very different not only in terms of PackageReference and packages.config but also whether you use the old-style project format or the new SDK-style project format in your libraries and applications. Consequently, it is hard to provide the same experience in all cases. I recommend you to use SDK-style projects with PackageReference to gain access to the latest features.
I'm making a NuGet package and my csproj looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup Label="Globals">
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>
<PropertyGroup>
<TargetFrameworks>netstandard2.0;netstandard1.6;net461;net47</TargetFrameworks>
...
<PackageId>Package2</PackageId>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Package1\Package1.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)'=='net461' OR '$(TargetFramework)'=='net47'">
<Reference Include="System.Net.Http" />
</ItemGroup>
</Project>
The project it's referencing looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup Label="Globals">
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>
<PropertyGroup>
<TargetFrameworks>netstandard2.0;netstandard1.6;net461;net47</TargetFrameworks>
<PackageId>Package1</PackageId>
...
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)'=='Debug'">
<NoWarn>1701;1702; CS1591</NoWarn>
</PropertyGroup>
<ItemGroup Condition="'$(TargetFramework)'=='netstandard1.6' OR '$(TargetFramework)'=='net461'">
<PackageReference Include="System.ValueTuple" Version="4.5.0" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)'=='net461' OR '$(TargetFramework)'=='net47'">
<Reference Include="System.Net.Http" />
</ItemGroup>
</Project>
And inside the Package2 project it has the following line:
webRequestHandler.ClientCertificates.Add(certificate);
But it isn't building in net461 or net47, saying:
'HttpClientHandler' does not contain a definition for
'ClientCertificates' and no accessible extension method
'ClientCertificates' accepting a first argument of type
'HttpClientHandler' could be found (are you missing a using
directive or an assembly reference?)
Package2(net461),
Package2(net47)
But the only thing I've changed is removed this from the csproj for package2:
<ItemGroup Condition="'$(TargetFramework)'=='netstandard2.0'">
<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="2.0.0" />
</ItemGroup>
<ItemGroup Condition="'$(TargetFramework)'=='netstandard1.6' OR '$(TargetFramework)'=='net461' OR '$(TargetFramework)'=='net47'">
<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="1.1.2" />
</ItemGroup>
Can anyone help me understand how to fix it? I don't really want to bring in that whole NuGet package just to fix this one dependency I think I'm just missing an assembly but as far as I know it should be in System.Net.Http which I should already be referencing (and so should the other project it's already dependent on).
Looks like this property is available from version 4.7.1:
https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.clientcertificates?view=netframework-4.7.1
Note that if you select an older .NET version, you'll see a message like this:
The requested page is not available for .NET Framework 4.7.
For me the solution was to download the newest version of "System.Net.Http".
You can find it through the NuGet package manager.
At the time of writing v4.3.4 is the newest version and it contains the ClientCertificates methode.
I've swapped out the assembly reference for the NuGet package:
<ItemGroup Condition="'$(TargetFramework)'=='net47' OR '$(TargetFramework)'=='net461'">
<PackageReference Include="System.Net.Http" Version="4.3.4" />
</ItemGroup>
pretty sure this is the wrong thing to do™ as the assembly reference in .NET Framework should be sufficient and I'm probably going to suffer many conflicting reference issues anywhere I install my package, but this is the best I can come up with right now.
I'm on Ubuntu and I have two .NET Core 2.0 projects (Project Oranges.csproj and Apples.csproj). Oranges only contains references to NuGet packages, while Apples contains a reference to Oranges.
Running dotnet build -f netcoreapp2.0 Oranges.csproj succeeds! Oranges.dll now exists at /Oranges/bin/Debug/netcoreapp2.0/Oranges.dll.
Running dotnet build -f netcoreapp2.0 Apples.csproj fails with: error CS0009: Metadata file '/Oranges/bin/Debug/netcoreapp2.0/Oranges.dll' could not be opened -- PE image doesn't contain managed metadata
How can I go about referencing Oranges, which builds without issue, in Apples without issue?
Oranges.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<TargetFrameworks>netcoreapp2.0;net451;</TargetFrameworks>
<RootNamespace>Oranges</RootNamespace>
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>..\..\GeneratedKey.snk</AssemblyOriginatorKeyFile>
<DelaySign>false</DelaySign>
</PropertyGroup>
<PropertyGroup Condition="'$(TargetFramework)' == 'netcore2.0'">
<DefineConstants>NETCORE2_0</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition="'$(TargetFramework)' == 'net451'">
<DefineConstants>NET4_5_1</DefineConstants>
</PropertyGroup>
<ItemGroup>
<None Remove="packages.config" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
<PackageReference Include="System.Collections.Immutable" Version="1.4.0" />
</ItemGroup>
</Project>
Apples.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<TargetFrameworks>netcoreapp2.0;net451;</TargetFrameworks>
<RootNamespace>Apples</RootNamespace>
<SignAssembly>true</SignAssembly>
<DelaySign>false</DelaySign>
<AssemblyOriginatorKeyFile>..\..\GeneratedKey.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
<ItemGroup>
<None Remove="packages.config" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="CommandLineParser" Version="2.1.1-beta" />
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
<PackageReference Include="System.Collections.Immutable" Version="1.4.0" />
<PackageReference Include="System.Composition" Version="1.1.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Oranges\Oranges.csproj" />
</ItemGroup>
</Project>
After deleting the bin and obj folders from the project directory and rebuilding, a different error was being displayed.
CSC : error CS7027: Error signing output with public key from file 'GeneratedKey.snk' -- Assembly signing not supported. [.../Oranges/Oranges.csproj]
After some research I stumbled across a solution.
Assembly Signing Not Supported
Adding the line below to the .csproj file for each assembly that required signing resolved the issue.
<PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign>
For now it seems like if you need to sign netcore assemblies, it should be done on Windows.