Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet pack does not produce package on net core 2.0.0 web project #7539

Closed
marcusien opened this issue Aug 28, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@marcusien
Copy link

commented Aug 28, 2017

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: cdcd192

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

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 28, 2017

@marcusien: @dasMulli is correct. This is by design and implemented by aspnet/websdk#165

cc @davidfowl @mlorbetske @davidfowl

@nguerrera nguerrera closed this Aug 28, 2017

@dasMulli

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2017

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

This comment has been minimized.

Copy link
Author

commented Aug 29, 2017

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

This comment has been minimized.

Copy link
Author

commented Aug 29, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 29, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2017

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

This comment has been minimized.

Copy link
Author

commented Aug 29, 2017

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

This comment has been minimized.

Copy link

commented Sep 22, 2017

@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

@DAllanCarr

This comment has been minimized.

Copy link

commented Nov 23, 2017

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

@Raithybabes

This comment has been minimized.

Copy link

commented Jan 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2018

@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

This comment has been minimized.

Copy link

commented Jan 11, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2018

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

This comment has been minimized.

Copy link

commented Jan 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.