dotnet pack does not support arbitrary configurations
See original GitHub issuePJ allowed passing in arbitrary configurations, and would output to the appropriate bin/{Configuration} subdirectory. CSProj fails with:
error : The OutputPath property is not set for project 'TestLibraryWithConfiguration.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Test' Platform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
@nguerrera how do we enable custom configurations?
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
allow dotnet pack to pack nuspec file without needing a ...
Inputs: nuspec files NB: I am not packing a csproj, just files. In <= 4.0.0-rc2, this was available as dotnet nuget pack (nuspec)...
Read more >dotnet pack creates package that is not compatible with . ...
I am creating a NuGet package which contains a .Net Standard DLL and a config file. This project is supposed to support both...
Read more >'dotnet pack' uses Release configuration - .NET
Learn about a breaking change in the .NET 8 SDK where 'dotnet pack' uses the 'Release' configuration by default.
Read more >NuGet Package Dependency Resolution
This error occurs when one or more of the packages referenced in your project do not indicate that they support the project's target...
Read more >Announcing built-in container support for the .NET SDK
The .NET 7 SDK can easily build containers from your existing applications through new container image building support.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The biggest challenge here is deciding on the settings applied to such a configuration. We can go ahead and let the build proceed to an arbitrary directory. This trades off any enforcement against misspelling of configurations. So I say ‘releease’ or ‘deebug’, and get something rather arbitrary instead of an error.
We’ve talked about this lenient approach and it’s the cheapest way to unblock adding a new configuration in VS, which is currently broken, but just letting things proceed wouldn’t actually give the right behavior. In VS, when you create a new configuration, you say from which other configuration you want settings to inherit. If we just set the output path and nothing else, you wouldn’t inherit appropriately.
So we have to decide two things:
In short, this isn’t as simple as “just always set the output path”. There are consequences.
Created a copy of this in the SDK: https://github.com/dotnet/sdk/issues/328