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

Include IsPackable property #150

Closed
henkmollema opened this Issue Mar 14, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@henkmollema

henkmollema commented Mar 14, 2017

It is very convient to call dotnet pack on the solution to create packages from all the projects. However, by default it will, obviously, pack all the projects. This is controllable via the IsPackable property. E.g. <IsPackable>false</IsPackable>.

Is it possible to include this property in the Web SDK to prevent creating packages of web projects by default?

@vijayrkn

This comment has been minimized.

Show comment
Hide comment
@vijayrkn

vijayrkn Mar 25, 2017

Contributor

Fixed: #165

Contributor

vijayrkn commented Mar 25, 2017

Fixed: #165

@vijayrkn vijayrkn closed this Mar 25, 2017

@henkmollema

This comment has been minimized.

Show comment
Hide comment
@henkmollema

henkmollema commented Mar 25, 2017

Thanks @vijayrkn!

@gulbanana

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Apr 4, 2017

Could IsPackable be set to false only when OutputType is not Library? I'm packing some websdk projects at the moment.

gulbanana commented Apr 4, 2017

Could IsPackable be set to false only when OutputType is not Library? I'm packing some websdk projects at the moment.

@smartcaveman

This comment has been minimized.

Show comment
Hide comment
@smartcaveman

smartcaveman Jul 10, 2017

@vijayrkn @davidfowl

I had assumed that this behavior was intended exclusively to limit distribution of the NET Core 2 preview-dependent packages. If this behavior is actually meant to be permanent, I have both some feedback and a question.

Feedback
This behavior appears confusing to VS 2017 Preview users. Underneath the //Properties/Package tab, the first checkbox is labeled "Generate NuGet packages on build". The user will assume that this will result in NuGet package being generated upon building the project. In fact, this will only set the GeneratePackageOnBuild property, but web projects will still fail to pack. There will be no error message indicating what caused the pack failure or even acknowledging that a failure occurred. The *.nupkg will simply be mysteriously absent from the output. This can be a frustrating user experience and it will be very non-obvious for users unfamiliar with MSBuild to troubleshoot.

Question
The fact that it made sense to the ASP.NET team to disable packaging NuGets for web projects makes me think that there may be a better solution than NuGet packages for my scenario. I am attempting to use NuGet packages to distribute some composable, application-independent ViewComponents with embedded Razor views and content resources. Each package has a Program.cs with a 1-line Main() method that runs a server to test/demo the ViewComponent in an independent context. I created each of these projects in VS2017 Preview as a .NET Core 2.0 Web Application. Am I overlooking a better way to accomplish this sort of thing with the available ecosystem?

smartcaveman commented Jul 10, 2017

@vijayrkn @davidfowl

I had assumed that this behavior was intended exclusively to limit distribution of the NET Core 2 preview-dependent packages. If this behavior is actually meant to be permanent, I have both some feedback and a question.

Feedback
This behavior appears confusing to VS 2017 Preview users. Underneath the //Properties/Package tab, the first checkbox is labeled "Generate NuGet packages on build". The user will assume that this will result in NuGet package being generated upon building the project. In fact, this will only set the GeneratePackageOnBuild property, but web projects will still fail to pack. There will be no error message indicating what caused the pack failure or even acknowledging that a failure occurred. The *.nupkg will simply be mysteriously absent from the output. This can be a frustrating user experience and it will be very non-obvious for users unfamiliar with MSBuild to troubleshoot.

Question
The fact that it made sense to the ASP.NET team to disable packaging NuGets for web projects makes me think that there may be a better solution than NuGet packages for my scenario. I am attempting to use NuGet packages to distribute some composable, application-independent ViewComponents with embedded Razor views and content resources. Each package has a Program.cs with a 1-line Main() method that runs a server to test/demo the ViewComponent in an independent context. I created each of these projects in VS2017 Preview as a .NET Core 2.0 Web Application. Am I overlooking a better way to accomplish this sort of thing with the available ecosystem?

@vijayrkn

This comment has been minimized.

Show comment
Hide comment
@vijayrkn

vijayrkn Jul 10, 2017

Contributor

you can always set the property to true in your csproj and you should be able to create a nupkg for the app.

<IsPackable>true</IsPackable>

It is just the default that is set to false to cover scenarios mentioned here #150 (comment)

Contributor

vijayrkn commented Jul 10, 2017

you can always set the property to true in your csproj and you should be able to create a nupkg for the app.

<IsPackable>true</IsPackable>

It is just the default that is set to false to cover scenarios mentioned here #150 (comment)

@smartcaveman

This comment has been minimized.

Show comment
Hide comment
@smartcaveman

smartcaveman Jul 10, 2017

@vijayrkn Yes, I am the same person who posted the solution over at dotnet/cli#6904 . My feedback was motivated by how long it took to figure that out.

smartcaveman commented Jul 10, 2017

@vijayrkn Yes, I am the same person who posted the solution over at dotnet/cli#6904 . My feedback was motivated by how long it took to figure that out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment