dotnet custom does not execute in the context of project directories

[roryprimrose]

• Server - VSTS
• Build https://watchium.visualstudio.com/Watchium/_build/index?buildId=1537&_a=summary
• Agent - Private: Windows 10, agent version 2.120.2

Issue Description

I'm using 2.* beta of the dotnet build task to run a custom dotnet CLI. In this scenario, I'm using setversion from https://github.com/TAGC/dotnet-setversion

I have added the following to one of my projects.

  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-setversion" Version="1.0.3-issue-5-0008" />
  </ItemGroup>

My build does a dotnet restore, then a dotnet custom. For example:

The call to the custom task fails because the task cannot be found. If I use the commandline but execute with the current directory set to the project folder, the custom CLI will be resolved and will execute correctly.

Either there is an issue with the setversion package, or (presumably) the build task needs to set the current directory to each proj found in the glob before executing the custom CLI. I'm not sure which is the issue here.

Error logs

2018-01-18T12:21:05.6098334Z ##[section]Starting: Set Version
2018-01-18T12:21:05.6103344Z ==============================================================================
2018-01-18T12:21:05.6103344Z Task         : .NET Core
2018-01-18T12:21:05.6103344Z Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command. For package commands, supports NuGet.org and authenticated feeds like Package Management and MyGet.
2018-01-18T12:21:05.6103344Z Version      : 2.1.9
2018-01-18T12:21:05.6103344Z Author       : Microsoft Corporation
2018-01-18T12:21:05.6103344Z Help         : [More Information](https://go.microsoft.com/fwlink/?linkid=832194)
2018-01-18T12:21:05.6103344Z ==============================================================================
2018-01-18T12:21:06.3537728Z [command]"C:\Program Files\dotnet\dotnet.exe" setversion C:\B\_work\4\s\TechMentorFunctions.UnitTests\TechMentorFunctions.UnitTests.csproj 4.5.6 --vsts
2018-01-18T12:21:06.4779186Z No executable found matching command "dotnet-setversion"
2018-01-18T12:21:06.4969413Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2018-01-18T12:21:06.4969413Z [command]"C:\Program Files\dotnet\dotnet.exe" setversion C:\B\_work\4\s\TechMentorFunctions\TechMentorFunctions.csproj 4.5.6 --vsts
2018-01-18T12:21:06.6015735Z No executable found matching command "dotnet-setversion"
2018-01-18T12:21:06.6115850Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2018-01-18T12:21:06.6140880Z ##[error]Dotnet command failed with non-zero exit code on the following projects : C:\B\_work\4\s\TechMentorFunctions.UnitTests\TechMentorFunctions.UnitTests.csproj,C:\B\_work\4\s\TechMentorFunctions\TechMentorFunctions.csproj
2018-01-18T12:21:06.6235993Z ##[section]Finishing: Set Version

[aldoms]

There's no expectation for the dotnet task to cd into each proj directory found.

According to their README, for dotnet-setversion to work, dotnet should be invoked from the directory the .csproj is on. I think dotnet-setversion should be updated to use the parameters dotnet is called with (which our custom task provides) so that it can do the directory change on its own. I would contact the setversion owner and ask them if they could make the change or take a PR for it.

[roryprimrose]

Hi @aldoms. I have already raised that as an issue with setversion in order to support the way the VSTS build task invokes the custom CLI. We are now at the point of testing that updated CLI and this is where we are hitting the issue.

My understanding of the current state is:

• The CLI package is referenced via the DotNetCliToolReference element in a csproj
• dotnet cannot find the CLI when executing the dotnet custom build task
• dotnet can manually find the package when I execute it in the project path via my user profile

Best I can tell, the issue here is either

• I'm referencing the custom CLI incorrectly and it is not being restored on the build server
• The restore is working but it is in a location that dotnet.exe cannot find it

Can you please confirm that the correct way of referencing the custom dotnet CLI is via the csproj example above? Is there anything else required in the solution to restore the package?

[roryprimrose]

Ok, so reading https://docs.microsoft.com/en-us/dotnet/core/tools/extensibility#path-based-extensibility it seems like this setversion CLI is a project specific one. That would explain why the custom command can only be run in the context of the specific project.

So my scenario falls in a gap here. The setversion CLI is developed to be a project specific CLI. The dotnet VSTS build step is designed to execute globally installed CLI packages.

[aldoms]

You are correct, after a more thorough reading of the docs the project based tools need to run in the context of the project for dotnet to find the binaries needed for the command. You are correctly specifying the dotnet-setversion reference in your project, we just need to run dotnet in the correct folder.

There's a new "workingDirectory" input that will be added to the dotnet task in the advanced section, which will be deployed sometime in the next couple of weeks. Once that goes live, please try it out and see if it satisfies your scenario. On our end we will determine whether to add the change directory capability to the task, or if it's something dotnet should handle itself.

[sachinma]

@roryprimrose this feature should be available to you now. Let me know if this resolves your issue.

[roryprimrose]

Sorry, I missed these comment notifications.

The addition of the workingDirectory parameter will now support using the dotnet task with project based CLI because the CWD can be set. Thank you for making this change.

I think there is still a usability issue here where the build task cannot be used to execute project based CLI resolved via a glob. To argue the other side, I'm not sure the build task should do this because doing so would require the glob matched projects to all have the project based CLI configured for it to work otherwise builds would fail on projects that match the glob but don't have the CLI package.

This is a good change however does not solve my issue. The primary blocker is that I can't install the setversion CLI as a global package (assume a hosted build agent for example) and duplicating dotnet custom tasks for each csproj in a solution prevents using a glob and therefore is an administrative nightmare.

I don't think there is actually a good solution here. I've written a powershell task to set the version against all projects as a broad action on my build workflow which covers my specific need here.

[sachinma]

Thanks @roryprimrose for confirmation and also updating the thread with the work-around in case someone else has this issue. I am closing this ticket right now given we are not planning update the working folder per regex pattern match.

[alexmg]

It would be very useful if the working directory could be set based on the glob match.

I'm trying to run dotnet xunit on a number of unit test projects using a single .NET Core task. The unit test projects all follow a naming convention and I'm confident that the dotnet-xunit CLI tool will be installed for all glob matches. If there was a case where the tool wasn't found I would actually want the build to fail.

As things stand I have to either create a separate task for every new unit test project or use a shell script instead. Creating a new task would not be maintainable and would require VSTS configuration to be changed just to run unit tests for a new project. Creating a shell script to achieve this defeats the point of using VSTS with its easy to use tasks.

You could provide an option for setting the working directory per glob match. When that is enabled the specific working directory option could be disabled.

Right now, it looks like I'll be writing a script to solve my problem, something I thought that for common cases VSTS was supposed to help me avoid.

[sachinma]

@alexmg I am opening the issue for now. Adding @azooinmyluggage to provide the feedback on this request

[alexmg]

Thanks @sachinma for taking this into consideration. I started out using dotnet test but hit a roadblock due to a bug impacting the xunit test adapter. When switching to dotnet-xunit I realised the .NET Core CLI tool requirement for execution in the project folder didn't combine well with the convenience of globbing. I have created a bash shell script to perform the globbing and dotnet xunit calls for now but would much prefer to return to native VSO. 😄

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days