dotnet pack for source files does not keep file structure together - .net core
See original GitHub issueSteps 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.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (5 by maintainers)
Top GitHub Comments
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.
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.