Dotnet 包包括 nuget 包到 output nuget ZEFE90A8E604A7C840E8ZD03A

Question

So i'm encountering a very weird behavior with nuget packages.

let's say i have a package called Framework and this package is a dependency to Package A and Package B

Now i have a Client 1 that has as dependencies the Framework , Package A , Package B and it MUST be like this because for example a Client 2 might not need Package A but need the other 2 or a client that only needs the framework.

Now here's where things get weird. If for testing purposes I create a local version of the Framework for Client 1 to test out some changes, but Package A/B are still from the registry where they were published, it will complain that the older version of the framework is not found (which is the version Package A/B were built with) so i would like to k now if there is any way to literally bundle a nuget package with all of it's dependencies as a standalone package?

Here is a sample.csproj

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
    <WarningsAsErrors />
  </PropertyGroup>

  <ItemGroup>
    <Folder Include="Component\" />
    <Folder Include="Model\" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Package.A" Version="1.0.1-SNAPSHOT" />
    <PackageReference Include="Framework" Version="[5.*,)" />
  </ItemGroup>

</Project>

And my pack command is usually:

dotnet pack -p:PackageVersion=1.1.2-SNAPSHOT -o C:\Users\SomeUser\Desktop\Projects\NuGetPackages

Answer 1

if there is any way to literally bundle a nuget package with all of it's dependencies as a standalone package?

Not with the current tooling, but it is the highest upvoted issue on GitHub .

If it's something you really want, you could use PackagePath to include the dll in your package (for example <None Include="path\to\framework.dll" PackagePath="lib/<tfm>/" /> ). Alternatively, create a nuspec file and specify all the assemblies to include .

There are several issues with this, however. One is when the version of framework.dll that is bundled with Package.A is different to the version bundled with Package.B , which version will the app end up using?File names must be unique, so both can't exist at the same time. By keeping framework as a separate package which is a dependency of both other packages, it's clearer that only one is selected, and it's clear which version was selected. Another issue is if there's a bug in Framework, if it's a dependency, the app can simply reference Framework as a direct dependency, using a version that fixes the bug. If framework.dll is bundled inside the other packages, then not only does Framework need to be fixed, but then new versions of the other packages need to be published that include this new version. You're making servicing bug fixes more difficult when you bundle.

However, I don't believe any of this is going to solve your problem. Your description that "it will complain that the older version of the framework is not found" lacks details to understand what the exact error was, but I assume that your framework dll is strong name signed and it fails at runtime with a file not found error about the version the packages were compiled against. In this case you probably want to use binding redirects , although for SDK style projects I thought this should be done automatically when it detects multiple assemblies referencing different versions of the same assembly name.

If this answer doesn't help, I think we need more information about what the actual error you got was, and how exactly you "create a local version of the Framework for Client 1 to test out some changes" (did you add a ProjectReference to framework.csproj, or did you compile a framework.dll and add a reference to this dll in your test project, or something else?)