Sdk: dotnet pack does not produce package on net core 2.0.0 web project

[marcusien]

Steps to reproduce

Install net core 2.0.0 sdk
Create a basic Web project with net461 target framework and referencing AspNetCore 2.0.0
Execute the dotnet pack myproject.csproj

Expected behavior

A nupkg is generated

Actual behavior

nothing is produced.
Before I migrate to 2.0.0, packages were normally produced locally and with TFS builds

Environment data

dotnet --info output:
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9

Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

[dasMulli]

Web projects are now marked as not packable by default. You can change that by adding the following property to the csproj:

  <PropertyGroup>
    <IsPackable>true</IsPackable>
  </PropertyGroup>

[nguerrera]

@marcusien: @dasMulli is correct. This is by design and implemented by https://github.com/aspnet/websdk/pull/165

cc @davidfowl @mlorbetske @davidfowl

[dasMulli]

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..
I believe someone else wanted to use packing for Octopus deployment (who ship their own cli to do it correctly).

[marcusien]

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

[marcusien]

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.
At least create an information message to let the developer know that nothing gonna happen

[nguerrera]

I completely agree that pack shouldn't silently do nothing when IsPackable=false. I suggest logging an issue on https://github.com/nuget/home. cc @rohit21agrawal

[dasMulli]

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.
If it is a classic .net framework application (target framework net*, used via packages.config), they would be added to the project's directory..

[marcusien]

I only work with full framework. Maybe i didnt have troubles that appear with netcoreapp i dont know.

In my case i include content files in the output. But the package is generated but dotnet pack command.

Dont know if i answered all your questions

[mmillican]

@dasMulli can you elaborate on this?

the source project may need to be modified to create a working package

I am trying to create a similar project, to share common views between projects. This would be targeting .net core 2.0

[dcarr42]

The published output needs to be packed easily and currently this is not the case from VS.

[Raithybabes]

@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! 🙈

[dasMulli]

@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.
If you create a class library for .NET Standard 2.0 or .NET Core 2.0, this should work fine as project or package references and it supports packing by default.

[Raithybabes]

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.

Thank you

[dasMulli]

Wouldn't that lead to a cyclic reference? A depending on B (impl.) which depends on A again?
I'd suggest creating a separate project just containing the interfaces, e.g. a My.Abstrations project/package.

[Raithybabes]

@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.

[mcm-ham]

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..

@dasMulli I would like to package my Razor Class Lib as a nuget package and had to add IsPackable before it worked.

I completely agree that pack shouldn't silently do nothing when IsPackable=false. I suggest logging an issue on https://github.com/nuget/home

Did that issue get filed?

[douglasg14b]

This also seems to apply to projects that Visual Studio thinks are test projects. Even if there are no tests (ie. a supporting library that has xunit as a dependency).

The pack command really shouldn't be failing silently here...

[dasMulli]

For test project, there was an explanation at https://github.com/NuGet/NuGet.Client/pull/1170#issuecomment-279033654
Also helped protecting against https://github.com/xunit/xunit/issues/1170

I'm surprised about razor class libs though, that seems to make sense - sharing view code across web projects.. maybe @vijayrkn has some insight on the web / razor SDKs behaviour for packing