Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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]


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:closed
  • Created 5 years ago
  • Comments:10 (5 by maintainers)

github_iconTop GitHub Comments

dnbr2002commented, Sep 21, 2018

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.

dnbr2002commented, Sep 20, 2018

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

dotnet pack (.NET 5) creates extra folder for files with no ...
dotnet pack creates extra folder for files with no extension when packing staticwebassets. Example: if there is a file in wwwroot/myfolder/ ...
Read more >
dotnet pack command - .NET CLI
The dotnet pack command creates NuGet packages for your . ... The sources files are included in the src folder within the symbols...
Read more >
Be careful with .NET Core Folder Structure - Simple Talk
Simple: Everything in the folder is part of the project. All the files in the folder will be compiled as part of the...
Read more >
.NET SDK Support
The dotnet build command builds the project and its dependencies into a set of binaries. The binaries include the project's code in Intermediate...
Read more >
Include both Nuget Package References *and* project ...
One issue I have been encountering is that the command was either referencing the required nuget packages, or the project reference DLLs, never ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found