25

I have Visual Studio 2019 Community Edition

Steps to reproduce:

I load up VS and start a brand new C# .Net Standard Library project. I go to Nuget Pkg Manager and install ANY nuget package. I add a single line to Class1.cs to use a Type from the package.

For instance, if I install WatsonTCP nuget package, I change Class1.cs to look like this:

using System;
using WatsonTcp;

namespace NugetTest
{
    public class Class1
    {
        public Class1()
        {
            WatsonTcpClient client = new WatsonTcpClient("", 0);
        }
    }
}

I hit Rebuild Solution. I check the bin/Debug folder and none of the dlls for the nuget package are there. Same thing with bin/Release for a Release build.

I have poored through as many SO issues as I can. I've read the MSDN documentation on nuget.

I set Build and Run MSBuild settings to Detailed. In the build log, I see something like the following output for every single dll:

Primary reference "WatsonTcp, Version=2.0.7.0, Culture=neutral, PublicKeyToken=null".
Resolved file path is "C:\Users\James\.nuget\packages\watsontcp\2.0.7\lib\netstandard2.0\WatsonTcp.dll".
Reference found at search path location "{HintPathFromItem}".
This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".

I'm guessing this notice about CopyLocal is the reason nothing is being output in the build folder. But I'm not 100% sure.

SO mostly contains older questions that pertain to the pre-"package reference" era before .Net Core and .Net Standard. As a result, any time I search for issues pertaining to "CopyLocal", I get information on setting the CopyLocal property explicitly on a DLL Reference. I'm not finding anything helpful to fix my issue with automatic determination of CopyLocal by the Package Reference and RAR system.

Can anyone help?

JamesHoux
  • 2,999
  • 3
  • 32
  • 50

1 Answers1

61

Open your xx.csproj(In VS, double-click the project name in Solution explorer, or right-click project=>unload=>edit...) and add the CopyLocalLockFileAssemblies property into it, set its value to true and it will copy all your assemblies from nuget packages to output folder during build process.

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <!--Add this line-->
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

And if you have too many nuget packages in your project and you only want part of them, try using PrivateAssets="All" to prevent VS from copying the specified one to output folder. 

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <!--Add this line to copy everything.-->
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="log4net" Version="2.0.8" />
    <PackageReference Include="Newtonsoft.Json" Version="12.0.3-beta1" />
    <PackageReference Include="WatsonTcp" Version="2.0.7" PrivateAssets="All"/>
  </ItemGroup>

Eg: Using script above will copy log4net and NewTonSoft.Json but not WatsonTcp to output folder. More details refer to github/dotnet/sdk#2235.

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • Thanks! Your solution works! Also, I read the link you included. The discussion mentioned publishing instead of building. So then I thought "wow... ignorant me." I should use Publish workflow instead of Build workflow. So then I tried to Publish, and I got a completely new problem -- no files output except for .nupkg. Opened a new question about it here: https://stackoverflow.com/questions/58090705/publishing-a-console-app-in-visual-studio-produces-empty-ish-publish-folder-on – JamesHoux Sep 25 '19 at 03:26
  • Actually, all info in my answer is talking about build instead of the publish. And the PrivateAssets="All" is something which will affect your build behavior in VS. But if you right-click the project=>and press publish button, the output xx.nupkg is expected behavior. – LoLance Sep 25 '19 at 03:33
  • @JamesHoux You can create a new empty .net standard project, publish it and you will get a xx.nupkg, and it's by design cause most of the time, since both .net framework or .net core or uwp can reference .net standard, we suggest use .net standard projects to create nuget packages. But this seems to not related to your original issue, if your original issue is resolved, you could consider marking it as answer :-) – LoLance Sep 25 '19 at 03:36
  • Yes I'm going to mark it as answer. Thank you. :) I don't understand your comment about my publish issue though. I'm not trying to publish a Nuget package. I'm trying to simply publish a dll that I can copy to wherever I want. – JamesHoux Sep 25 '19 at 03:42
  • 1
    The behavior when click publish button in .net standard differs from that in .net core projects. If you want to copy the output dll to wherever you want, why not copy the xx.nupkg file, (rename the xx.nupkg to xx.zip and open it, in its lib folder, you can find your projectName.dll). And any project reference the package will actually reference your dll since your dll is packaged into the xx.nupkg. – LoLance Sep 25 '19 at 03:46
  • OK. I'm still confused. Is using Publish the wrong way to prepare a .Net Standard library for deployment to an in-house project? It seems ridiculous to have to open the .nupkg and extract the files. I asked about this here: https://stackoverflow.com/questions/58101078/is-there-a-way-to-publish-a-net-standard-library-without-producing-a-nupkg-in The first comment says that nupkg is for publishing to nuget, and the comment makes it sound like there should be a straight forward workflow for me to target output files into an ordinary folder. – JamesHoux Sep 25 '19 at 17:20
  • 1
    I would have thought an ordinary Build process is all I need (which is how I got to my original problem for the question above). But it makes no sense as to why I'd need to manually add a custom switch of "CopyLocalLockFileAssemblies" to the csproj folder. This weird switch is what helped me to think Build workflow is the wrong way to prepare for final deployment. It seems like neither Build nor Publish actually make sense. – JamesHoux Sep 25 '19 at 17:22
  • @JamesHoux Since it has too many comments here, I will try to reply in your new issue, or we can move the discussion to chat if convenient :) – LoLance Sep 26 '19 at 05:16
  • @LanceLi-MSFT I see you work at Microsoft. Any chance you can get this exposed via the VS UI?? Its really helpful for plugin and powershell module projects. – Tim Mar 26 '20 at 18:55
  • @LoLance Have always been confused about this - how would the code ever execute if the DLLs were *not* copied to the bin directory? How is this not default? – Emilio Oct 31 '21 at 14:26