Sdk: dotnet pack for source files does not keep file structure together - .net core

[dnbr2002]

Steps to reproduce

dotnet pack sa_netcore20_webapi --no-build --include-source --output bin/Debug

Expected behavior

an nupkg containing a folder structure like this

--sa_netcore20_webapi
----bin
------Debug
----Controllers
------ValuesController.cs
----Properties
------launchSettings.json
----appsettings.Development.json
----appsettings.json
----Program.cs
----sa_netcore20_webapi.csproj
----Startup.cs

Actual behavior

Actual Folder structure in nupkg

--sa_netcore20_webapi.1.0.0.symbols
----_rels
------.rels.xml
----content
------Properties
--------launchSettings.json
------appsettings.Development.json
------appsettings.json
----contentFiles
------any
--------netcoreapp2.1
----------Properties
------------launchSettings.json
----------appsettings.Development.json
----------appsettings.json
----lib
------netcoreapp2.1
--------sa_netcore20_webapi.dll
--------sa_netcore20_webapi.pdb
--------sa_netcore20_webapi.runtimeconfig.json
----package
------services
--------metadata
----------core-properties
------------fjkdljfdafjkBIGUGLYafksafjksa.psmdcp
----src
------sa_netcore20_webapi
--------Controllers
----------ValuesController.cs
--------Program.cs
--------sa_netcore20_webapi.csproj
--------Startup.cs

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
Version: 2.1.400
Commit: 8642e60a0f

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:Program Files\dotnet\sdk\2.1.400\

Host (useful for support):
Version: 2.1.2
Commit: 811c3ce6c0

.NET Core SDKs installed:
2.1.201 [C:Program Files\dotnet\sdk]
2.1.302 [C:Program Files\dotnet\sdk]
2.1.400 [C:Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.7 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:Program Files\dotnet\shared\Microsoft.NETCore.App]

Description

So basically for some reason the pack command has pulled apart properties and app settings and, put that in the content dir's and then put the rest of the source files in the src dir? The reason im asking is because I basically just want to open this back up and run a build from this source in a pipeline. And now it appears I have to stitch the parts back together if I use the dotnet pack command to begin with. Is there something Im missing? How can I de-pack these src files in a linux environment without having to get to hacky? Also we don't want to use the Nuget Cli because it relies on Mono and we are trying to stay native linux in our dev ops env so dotnet core commands only if thats even a solution??

I've posted on SO but no response and I realize maybe it's not bug but it certainly seems pretty inconvenient to split things up this way and would love to know why or if there is way of keeping things together in the src.

[peterhuene]

@nkolev92 is this something the NuGet client team should answer? Is the expectation that the src directory in the package contains only source code files or something that is representative of the complete source that went into building the package?

[nkolev92]

I think this is a thing NuGet can answer.
@rohit21agrawal should have better context.

Related issue https://github.com/NuGet/Home/issues/4719

[rohit21agrawal]

all Pack target does here is get the list of content items from msbuild and puts them in the content and contentFiles folder in nupkg, and takes Compile items from msbuild and puts them in the src directory preserving folder structure as much as possible.

it doesn't have its own logic to decide what goes where.

[dnbr2002]

I appreciate the feedback on this, I really do, so thank you. What Im still not understanding is why would you separate the content items from the compile items? If I run dotnet publish against the extracted nupkg that I packed with the dotnet cli

dotnet publish src\sa_netcore20_webapi\sa_netcore20_webapi.csproj --framework netcoreapp2.1 -o build1

I still do not get the necessary content items published to the build1 folder.

Im missing the appsettings.Development.json and the appsettings.json.

On the other hand, if I run it against the original source on my machine where the files have not been split up from the dotnet pack --no-build --include-source command.

Src like this:

--sa_netcore20_webapi
----bin
------Debug
----Controllers
------ValuesController.cs
----Properties
------launchSettings.json
----appsettings.Development.json
----appsettings.json
----Program.cs
----sa_netcore20_webapi.csproj
----Startup.cs

My build1 folder includes appsettings.Development.json and appsettings.json which are files I need when I publish. So why split the content files and compile files into different folders if the dotnet publish doesn't handle this split getting everything back together as it belongs for deploying?

[dnbr2002]

Are we not supposed to use dotnet pack to pack src? Typically you would extract the packed source in an pipeline from repository server or from the deployment server and then pass that src into the container so you can build the application in the container. I see no way to natively do that using dotnet pack and nupkg with a web application. So instead I need to potentially tar the Src file location and make that my packaged source and curl that to repo server and extract that file from the deployment server to get a proper set of src into the container. Nothing native about that process though.

[dnbr2002]

I would like to hear someones thoughts on this from MS if at all possible. Thank you.

[livarcocc]

I am not sure NuGet is the best way to distribute your whole project to be built by CI. The way we do it ourselves is through source control for instance.

We have some nupkgs that distribute code, but that code is usually added to an already existing project and build as part of that project, rather than the whole thing being distributed through nupkgs.

[dnbr2002]

Thanks for the response @livarcocc . Yes we use nupkg for class libraries and have no problem storing those for reuse in private nugget feed. That works well as an artifact type in those cases. But for Web Applications we will need to do something 'less' native for dotnet to run in our pipe. Npm has it's native pack and publish, for Python we are using Twine and of course theres Maven with Java. I guess we'll have to tar dotnet core src folder on the build server, then deploy to our Nexus (our internal artifact repo server in pipeline) using a basic curl command. I just wanted to make sure we weren't moving away from something more native to dotnet core.

[dnbr2002]

Creating a packable source files artifact with the dotnet cl that can be extracted and placed in a container so it can restored and published i seems like that should be considered for future release. That is common practice in OpenShift PaaS env's.

[livarcocc]

I am going to close this issue for now and this is not something that we have plans to do.