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)

Most upvoted comments

What’s the priority of this?

For consistency, if dotnet run will automatically kick off a dotnet build equivalent, then it ought to support passing the parameters dotnet build can 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):

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AssemblyName>Example</AssemblyName>
    <OutputType>Exe</OutputType>
    <PackageId>Example</PackageId>
    <PackageTargetFallback>$(PackageTargetFallback);dnxcore50</PackageTargetFallback>
    <RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="$(PathToDep)/MyDependency.csproj" />
  </ItemGroup>

</Project>

This builds fine with dotnet build /p:PathToDep=../../my-dep-folder and running the build binary with dotnet bin/Debug/Example.dll also works fine, but there is no way to run this with dotnet run without modifying the csproj. When dotnet run is invoked without the parameter I get a bunch of missing reference errors and The build failed. Please fix the build errors and run again.

Also, regarding confusing argument passing there is already precedence for this because dotnet run accepts configuration and framework options (i.e. Debug vs Release). When it is necessary to disambiguate between options passed to dotnet run vs 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 run is more stateless and simple.

Looks like the dotnet run --property option 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 dotnet and 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 arg2 will pass -p:UseSharedCompilation=false as an argument to the application instead of just arg1 arg2. I guess this is because MSBuild properties are not parsed correctly?!

I really don’t understand either why this is closed. dotnet run has an explicit --no-build argument 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

dotnet run /p:LangVersion=latest

to build and run:

using System;
using System.Net;
using System.Threading.Tasks;
class Program
{
    static async Task Main(string[] args)
    {
        using(var client = new System.Net.Http.HttpClient())
        {
            Console.WriteLine(await client.GetStringAsync("https://github.com"));
        }
    }
}

with .NET Core 2.1.

Actual

dotnet run /p:LangVersion=latest

does not propagate LangVersion=latest build argument to compiler, and hence fails with:

Program.cs(8,18): error CS8107: Feature ‘async main’ is not available in C# 7.0. Please use language version 7.1 or greater.

Workaround

dotnet build /p:LangVersion=latest
dotnet run --no-build

Seem reasonable to allow passing -p://p: style parameters for msbuild, or even other msbuild parameters if the arguments are properly separated:

$ dotnet run -p:SomeProp=Val -nowarn:MSB1234 -warnaserror -- --some-program-arg