Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
dotnet pack does not produce package on net core 2.0.0 web project #7539
Steps to reproduce
Install net core 2.0.0 sdk
A nupkg is generated
nothing is produced.
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
I believe there are duplicates around.. @marcusien I'd be interested to know what you would use the package for. because a web project (without modifications) isn't really usable as package since the content would not be packed correctly and for deployment it would need publishing again from a host project..
If this is just a "by default" setting it's okay. I'm not at work today and tomorrow, I'll try with true on thursday
For the explanation, we have a "core" project (=common project) which is the base of our application. Each project (business meaning) have to implement this "core" project to have a base and some wanted/common behaviors. When we're coding, it's nice to be able to launch the "core" website". But at the end we want to make an assembly with this project and pack it so the developer can have this continuously updated assembly as a package.
I think we're not the only ones to make this kind of project. That's why packing a web project does not seem to be so weird
About the packed content, we don't have so much problem, and the behavior is the same no matter if the packed project is a web project or a basic assembly, content is added as a link and can be override by putting a real file at the same path
I'd tried your solution and it works now. rocks :)
But I still don't know why putting this behavior by default cause it's absolutely impossible to know why a package is not created by calling dotnet pack on a web project while the same command on an assembly project does produce a package. There''s nothing on the output of the command which indicates that it's normal that nothing is produced.
Do you include content files (js, cshtml etc.) in the output? when consuming this from a .net core project, the source project may need to be modified to create a working package.
referenced this issue
Sep 20, 2017
@dasMulli Hi, in answer to your question about what the packaged web project would be used for...
Firstly, am I right that .NET Core requires that project A needs to be a NuGet package to be referenced from project B?
Scenario: A is a web project with public interfaces and a plugin mechanism (e.g. via IoC container). B is a plugin which implements A interfaces. B needs to reference A. Therefore A must be packaged. B will later be dynamically loaded into A, but not via formal reference/dependency. Therefore A does not need to reference B.
Please correct me if I am wrong about this requiring A to be packaged as NuGet. If Core v2 allows reference to DLL rather than NuGet package then I don't know how to do it!
@Raithybabes the question is rather if B would need to be an ASP.NET Core project using the web sdk tooling or can be a class library.
Thanks @dasMulli but I don't quite follow your reply as an answer to my scenario.
My ASP.NET Core 2.0 project "A" (dotnet new webapi) allows some plugging-in of its public interfaces via Autofac file-based configuration.
My .NET Core 2.0 class library project "B" provides an implementation for A interfaces and will dynamically be plugged-in to A. It needs reference to A. I was under the impression that this required A to be NuGet packaged.
My scenario has the class library referencing the web api, which doesn't seem to be reflected in your answer. However, I did fail to consider using a project reference, which would negate the need to pack A, and is probably the solution I should be pursuing.
@dasMulli it might lead to a cyclic reference - I haven't got that far yet! I thought it'd be okay as A will only see B at runtime, and B will see the A that it is plugged into (not a different A, being a dependency that it carries round with it). Was I being naive?
Your suggestion of breaking A into multiple projects is better practice anyway, and should avoid any issues.
This is now straying off-topic. I was originally struggling to package my webapi as NuGet and that has already been answered (IsPackable), plus you've reminded me I don't need to do it anyway (proj ref), and then advised me to refactor my dependency chain. Some/all of which will definitely mean I am no longer needing to pack A.
Thanks for your assist. If I discover that my naive arrangement does work then I'll post again for completeness.