24

I am building a modular .NET core application that can load extensions at runtime using MEF. I have 2 projects, one is a library that I want to be able to load at runtime, then I have my main application that will do the loading.

My library project has some Nuget dependencies. In order to load my library at runtime, I need those Nuget dependencies to be available next to the library at runtime, but building using VS2017 does not include these Nuget DLLs as part of the output.

How do I get Nuget DLLs included when I build my library?

Edit: I have tried dotnet publish and dotnet pack, but both of those make me a nupkg file only containing my DLL and not the nuget DLLs I need with it. Also, I can't load a nupkg file at runtime very easily, which is why I'd like to just get the resulting assemblies themselves on their own.

For what it's worth, this is what my csproj looks like:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AssemblyName>JSON.plugin</AssemblyName>
    <IncludeBuiltProjectOutputGroup>true</IncludeBuiltProjectOutputGroup>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Composition" Version="1.0.31" />
    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\..\BDDGen.Types\BDDGen.Types.csproj" />
  </ItemGroup>

</Project>
ldam
  • 4,412
  • 6
  • 45
  • 76
  • 2
    The command-line way is to to do a `dotnet publish`, not a `dotnet build`. Not sure if VS has a way to do that (surely, it must). – omajid Aug 02 '17 at 14:56
  • `dotnet publish` builds me a .nupkg file that only has my library DLL in it, nothing else. – ldam Aug 02 '17 at 14:57
  • Are you trying to embed your references in your DLL? Maybe check out [`Costura.Fody`](https://github.com/Fody/Costura). – Scott Aug 02 '17 at 14:57
  • No, but that may be an option. I just want my DLL and the Nuget DLLs it depends on next to it. – ldam Aug 02 '17 at 14:58
  • Why the downvote? – ldam Aug 02 '17 at 15:00
  • @Logan are you looking under the `publish` directory? What are its contents after running a `dotnet publish`? – omajid Aug 02 '17 at 15:29
  • 1
    @omajid I wasn't getting a `publish` directory anywhere previously, but it seems after running `dotnet clean` and then a `dotnet publish` I have all my deps in the `publish` folder like I wanted. Thank you. :) – ldam Aug 02 '17 at 16:08

1 Answers1

59

In order to make the build process copy all referenced dll files from NuGet packages from the cache folder into the build output, set this property inside a <PropertyGroup>:

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • 1
    This works for nuget packages dependencies. What if I have a solution with multiple projects and I also need to include on the solution's main project, other projects' output DLLs? What I'm still missing now, even using your suggestion, are the DLLs of my two prjects that I dynamically load from the main project that doesn't directly depend on them. – Cheshire Cat Jan 08 '19 at 08:11
  • If it doesn't depend on them, then they won't be copied to the output.. if you want that you'll need to add a project reference – Martin Ullrich Jan 09 '19 at 11:46
  • 1
    I don't want to add a project reference since there's no "direct dependance" between the projects. Anyway I found another possible approach. I can use a Post-build event set on the dependency projects. I added a little `xcopy` script to copy the output DLLs of projects to the `bin` folder of the main project after every build. – Cheshire Cat Jan 09 '19 at 14:17
  • Just what I needed on a .Net 2.0 standard project. – PTBW Jul 24 '20 at 10:35
  • @CheshireCat, can you share the code you mentioned above, thanks – S.Minchev Aug 17 '20 at 11:34
  • 1
    What file would i need to edit to do that? – Lars Dormans Dec 22 '20 at 12:50
  • 1
    The project's .csrpoj file – Martin Ullrich Dec 22 '20 at 12:55
  • Thanks for this - the solution was surprisingly difficult to find. It's a pity that this isn't an setting in the Visual Studio Project Properties. It must be a common requirement, and it really shouldn't be so opaque... – Tullochgorum Jan 28 '23 at 11:04