sdk: Can't pass msbuild params in `dotnet run`
Steps to reproduce
I can’t pass msbuild params from dotnet run command. I can use
dotnet restore /p:PARAM=1 solution.sln
dotnet build /p:PARAM=1 solution.sln
but can’t write dotnet run /p:PARAM=1 soluition.sln because these params are not passed to msbuild.
Expected behavior
msbuild params are passed to msbuild.
Actual behavior
msbuild params are not passed to msbuild.
Environment data
dotnet --info output:
.NET Command Line Tools (2.0.0-preview1-005977)
Product Information: Version: 2.0.0-preview1-005977 Commit SHA-1 hash: 414cab8a0b
Runtime Environment: OS Name: ubuntu OS Version: 16.04 OS Platform: Linux RID: ubuntu.16.04-x64 Base Path: /usr/share/dotnet/sdk/2.0.0-preview1-005977/
Microsoft .NET Core Shared Framework Host
Version : 2.0.0-preview1-002111-00 Build : 1ff021936263d492539399688f46fd3827169983
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 19
- Comments: 17 (2 by maintainers)
What’s the priority of this?
For consistency, if
dotnet runwill automatically kick off adotnet buildequivalent, then it ought to support passing the parametersdotnet buildcan accept.I don’t think it’s entirely accurate to say that “dotnet run don’t have build involved other than to ensure the project is built already.” Lets say you had a msbuild project parameter that was necessary for a build to complete successfully, for example a relative path to a referenced project (probably not a best practice, but just a contrived example):
This builds fine with
dotnet build /p:PathToDep=../../my-dep-folderand running the build binary withdotnet bin/Debug/Example.dllalso works fine, but there is no way to run this withdotnet runwithout modifying the csproj. Whendotnet runis invoked without the parameter I get a bunch of missing reference errors andThe build failed. Please fix the build errors and run again.Also, regarding confusing argument passing there is already precedence for this because
dotnet runaccepts configuration and framework options (i.e. Debug vs Release). When it is necessary to disambiguate between options passed todotnet runvs options passed to the project being run the double hyphen is used (from the dotnet run usage:dotnet run [options] [[--] <additional arguments>...]]), for example:dotnet run -c Release -- -c "look my command takes dash c too"I think this issue should be reopened.
Environment Variables is not a preferred way in building in csproj. passing property on
dotnet runis more stateless and simple.Looks like the
dotnet run--propertyoption might resolve this once .NET 6 lands.If you just need to set a property, another workaround is to set an environment variable and msbuild will pick it up as a property. https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-properties?view=vs-2017#environment-properties
@wli3 I don’t understand what you mean by ambiguity? The docs are very clear about the separation of arguments for
dotnetand the executed application:dotnet run [dotnet arguments] [-- application arguments]Besides that, it actually looks like the current implementation contains a bug. Something like
dotnet run -p:UseSharedCompilation=false --project ../app.csproj -- arg1 arg2will pass-p:UseSharedCompilation=falseas an argument to the application instead of justarg1 arg2. I guess this is because MSBuild properties are not parsed correctly?!I really don’t understand either why this is closed.
dotnet runhas an explicit--no-buildargument to skip the build, so it definitely does the build and should propagate user build arguments to the build step.@livarcocc, could this be reopened?
Expected
to build and run:
with .NET Core 2.1.
Actual
does not propagate
LangVersion=latestbuild argument to compiler, and hence fails with:Workaround
Seem reasonable to allow passing
-p://p:style parameters for msbuild, or even other msbuild parameters if the arguments are properly separated: