Paket icon indicating copy to clipboard operation
Paket copied to clipboard

dotnet publish in .Net 5 results in missing dll's

Open michalsteyn opened this issue 3 years ago • 6 comments

Description

This issue is similar to https://github.com/fsprojects/Paket/issues/2887. When publishing an Asp.Net App using: dotnet publish -r win-x64 -c Debug the publish folder lacks some of the dependent package dll's.

Repro steps

I created a repo where someone can compare nuget vs paket behaviour (https://github.com/michalsteyn/paket-publish-issue)

NOTE: The repo contains two branches:

  • master: To showcase a working example using NuGet,
  • Paket: To showcase the Paket version resulting in missing dependencies.
  1. Clone the repo above
  2. call dotnet publish -r win-x64 -c Debug
  3. Compare src\bin\Debug\net50\win-x64 vs src\bin\Debug\net50\win-x64\publish.

The normal build artifacts can be found in the first folder mentioned above. The only dependency included in this project is Autofac. The DLL can be clearly seen in the build folder. This is missing in the publish folder.

Running the executable in the publish folder results in an obvious:

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Autofac, Version=6.1.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da'. The system cannot find the file specified.
File name: 'Autofac, Version=6.1.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da'
   at PaketPublish.Program.Main(String[] args)

This was tested on the following environment:

  • OS: Windows 10,
  • .Net SDK: 5.0.201
  • Paket: 6.0.0-beta8

Expected behavior

That all NuGet Dependencies should be included in the publish folder.

Actual behavior

None of the NuGet Dependencies are properly copied to the publish folder.

Known workarounds

None to my knowledge.

michalsteyn avatar Mar 29 '21 18:03 michalsteyn

Any progress on that?

I encountered the same problem with a Blazor WebAssembly project which I sadly can't publish without a fix.

Cheers

krauthaufen avatar Nov 30 '21 15:11 krauthaufen

Found a "workaround" via setting <PackAsTool>true</PackAsTool> which works for me (since it causes paket's <PackageReference>s to have <Publish>true</Publish>)

Maybe someone with a little more MSBuild experience could come up with a "real" solution based on that. Cheers

krauthaufen avatar Nov 30 '21 17:11 krauthaufen

@krauthaufen I'm curious if you came up with any solution other than <PackAsTool>true</PackAsTool> under the main PropertyGroup of your .fsproj. I'm currently facing the same issue with a Blazor WebAssembly project, and the PackAsTool solution doesn't seem to help.

If possible, a full .fsproj may be useful, if you still have it. I've tried publishing both as a library and as an exe (thinking maybe PackAsTool would only take effect in Exe?), to no avail.

StachuDotNet avatar May 11 '22 21:05 StachuDotNet

An example of this I found: https://github.com/michalsteyn/paket-publish-issue Adding <PackAsTool>true</PackAsTool> to the PaketPublish.csproj works in that case, fwiw.

StachuDotNet avatar May 11 '22 21:05 StachuDotNet

I think it's about this line here: https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/embedded/Paket.Restore.targets#L249

krauthaufen avatar May 12 '22 05:05 krauthaufen

Was there a solution for this?Am facing the same issue with many dlls missing when i publish. my set up is as follows

storage: none strategy: min lowest_matching: true copy_local:true specific_version : false framework:netstandard2.0,net6.0,net6.0-windows

Am i missing some thing.

muwanguzij avatar Apr 03 '24 11:04 muwanguzij