dotnet restore/publish step failure
dtretyakov opened this issue · comments
Originally from https://plugins.jetbrains.com/plugin/9190--net-core-support by @dobryak.
Whenever I try to use this plugin - it fails due to the file with rsp extension attached to command. For example:
[12:12:06][Step 3/4] Starting: "C:\Program Files\dotnet\dotnet.exe" restore --verbosity Diagnostic @C:\\t\\1\\buildTmp\\81a257c2f7fa4275a9f660012a89b9da.rsp [12:12:06][Step 3/4] in directory: C:\w\1\7686684696a3c6f9 [12:12:06][Step 3/4] error: @C:\\t\\1\\buildTmp\\81a257c2f7fa4275a9f660012a89b9da.rsp
If I run the same command on server in console - it also fails. If I remove RSP file - restore command goes well.
Same goes with publish:
[Step 5/5] Starting: "C:\Program Files\dotnet\dotnet.exe" publish C:\\w\\1\\7686684696a3c6f9\\src\\project\\project.json --configuration Release --output C:\\t\\1\\buildTmp\\project\\ @C:\\t\\1\\buildTmp\\0097828f9fab406b89f0b5d8c2a0ce6a.rsp [12:24:30][Step 5/5] in directory: C:\w\1\7686684696a3c6f9 [12:24:31][Step 5/5] Specify --help for a list of available options and commands. [12:24:31][Step 5/5] Unrecognized command or argument '@C:\\t\\1\\buildTmp\\0097828f9fab406b89f0b5d8c2a0ce6a.rsp' [12:24:31][Step 5/5] Process exited with code 1 [12:24:31][Step 5/5] Step Publish (.NET) failed
What is this rsp file, what it does and how to remove it?
which version of dotnet/SDK you are using?
1.0.0-preview2-003131
@akuryan prerelease versions are not supported
could you update your dotnet CLI/SDK?
Aha, clear. I will try to do this :), but not sure when it will be done. BTW, can this be mentioned at readme.md at root of repository? Or maybe I missed this somewhere :(
@akuryan I am going to update readme
@akuryan could you close this ticket if updating solved your issue?
It was created by @dtretyakov - I could not close it. But, updating solves an issue, so this one can be closed
I'm getting this error with the plugin using .Net Core 2.0.0. Should I file a new issue?
@cubanx, could you please share the teamcity .NET CLI plugin version and generated command line from the build log like in the first comment: Starting: "C:\Program Files\dotnet\dotnet.exe" ... ?
It's not just with restore/publish, it seems to be a lot of the commands. Here's the requested info with just a build:
[Step 1/3] Starting: "C:\Program Files\dotnet\dotnet.exe" build D:\\BuildAgent\\work\\fdddf0abe2803dc0\\CineNet.OneService\\CineNet.OneService.csproj --configuration Release @D:\\BuildAgent\\temp\\buildTmp\\afd15476265048da933bc45a096cd85b.rsp
[20:13:39][Step 1/3] in directory: D:\BuildAgent\work\fdddf0abe2803dc0
[20:13:40][Step 1/3] MSBUILD : error MSB1006: Property is not valid.
[20:13:40][Step 1/3] Switch: Pack
[20:13:40][Step 1/3]
[20:13:40][Step 1/3] For switch syntax, type "MSBuild /help"```
Let me know if you need more
Plugin Version:
.NET CLI SupportProvides build facilities for .NET projects | SNAPSHOT-20171004132154
Also, it works with this Command Line step:
dotnet.exe build %solution_name%\%solution_name%.csproj -c Release
it seem to be fixed here #85, just update your plugin
@cubanx any updates?
I'm getting this error with the plugin using .Net Core 2.1.0. Any suggestion?
@1015450578, could you please provide a corresponding build log with a command line and error message?
I've updated sdk version (on a local machine where "dotnet test" runs) to a 3.1 and that still happens
[dotnet test] Starting: C:\Program Files\dotnet\dotnet.exe test .\MySln.sln --filter "Category!=SchemaTests" --configuration Release --no-build --no-restore -- xunit.parallelizeAssembly=true -- xunit.parallelizeTestCollections=true -- xunit.maxParallelThreads=-1 @d:\buildAgent1\temp\agentTmp\1.rsp
[16:25:27] [dotnet test] in directory: D:\buildAgent1\work\e49451ace4a6eb8d
[16:25:27] [dotnet test]
[16:25:27] [dotnet test] Welcome to .NET Core 3.1!
SDK Version: 3.1.201
Error is
[dotnet test] One or more runsettings provided contain invalid token
When I run that command locally or on a build machine without "@d:\buildAgent1\temp\agentTmp\1.rsp" - all will be ok.
When I run exactly same command on a build machine- it just opens .rsp file.
@orihomie what version of TeamCity are you using?
2019.2.1
And I didnt found any mention in both release notes of 2.1 and 2.2 version about this, is that solved?
This .rsp generation somehow breaks msbuild switch reading because if I use no switch-parameter passing - all works fine even with that @*.rsp file at the end of command, like this:
[dotnet test] Starting: C:\Program Files\dotnet\dotnet.exe test .\MySln.sln --filter "Category!=SchemaTests" --configuration Release --no-build --no-restore @d:\buildAgent1\temp\agentTmp\1.rsp
Looks like this issue was fixed. Is it possible to upgrade TeamCity to 2019.2.2?
Looks like this issue was fixed. Is it possible to upgrade TeamCity to 2019.2.2?
Sry, how did you figured that out?
We'll try to upgrade latter today and then check how that works.
We just moved custom arguments to the end of list of arguments. Please let me know results
Did you mean this?
-- xunit.parallelizeAssembly=true -- xunit.parallelizeTestCollections=true -- xunit.maxParallelThreads=-1
Actually yes, all custom args
No, that wont work in 2.1 version, because it will add @*.rsp after command.
I'll try with 2.2 version later and will let you know about results.
I just checked
TC 2019.2.2
.NET SDK 2.1.802
Can you show the end of 3d string? Isnt there .rsp file?
.NET SDK 2.1.802 C:\Program Files\dotnet\dotnet.exe test xunittests.csproj "@C:\Projects\TeamCity\teamcity\.idea_artifacts\agent deployment debug\temp\agentTmp\1.rsp" -- xunit.parallelizeAssembly=true -- xunit.parallelizeTestCollections=true -- xunit.maxParallelThreads=-1
No specific option enabled? Adding .rsp file disabled by default in new version of teamcity?
There are no any tricky parameters. No, we cannot avoid using .rsp. We moved custom arguments to the end of list of arguments, after all arguments (and after .rsp). The .rsp file - just a text file with the same arguments. The length of command line has a limitation. To meet this limitation we should use .rsp. Your build fails because of the additional xunit arguments (after --) was placed before the dotnet test command arguments (in your version of .NET plugin )
Yep, that worked