The plugin does not take in account global.json files during the definition of the .net SDK version
NikolayPianikov opened this issue · comments
Steps to reproduce:
- install dotnet sdks: 2.0.3 and latest
- create a test project 'dotnet new xunit'
- add
global.jsonto the working directory (TeamCity working directory) like:
{
"sdk": { "version": "2.0.3" }
}- add
dotnet testbuild step - run build
Result: error The path '...\vstest15;.' specified in the 'TestAdapterPath' is invalid. Error: The custom test adapter search path provided was not found, provide a valid path and try again.
@NikolayPianikov thanks for raising this issue, I have some extra information about what we did and what worked for us.
We initially got around this issue by adding dotnet.cli.test.reporting=off to our build project (as suggested in #111).
This morning we tested adding the TeamCity.VSTest.TestAdapter package to our test project and removed the dotnet.cli.test.reporting parameter from our build project and it also worked (without losing the extra functionality when turning off dotnet.cli.test.reporting).
Cheers,
Henrik
@alfhenrik TeamCity.VSTest.TestAdapter is another one workaround, thanks for the mention. Anyway this issue was fixed and will be available as TeamCity 2018.1.1 soon (next week I hope) or you could install it manually from this place
Thanks @NikolayPianikov for the quick turnaround, looking forward to 2018.1.1 👍
In Plugin .NET CLI Support | 71923 with teamcity 2019.2.2 the runner ignores the global.json.
Step 5/7: Build & Publish (.NET CLI (dotnet))
16:33:23
dotnet publish
16:33:23
.NET SDK 3.1.201
My global json is:
{
"sdk": {
"version": "3.1.100"
}
}
@gimik17 Note that dotnet takes into account the json files associated with the working directory of the dotnet process and its parent directories. The default working directory in TeamCity is the checkout directory. Could you do the same actions from the command line and make sure TeamCity is doing something wrong?
That was the case. 👍