Circular dependencies error after upgrade
cdibbs opened this issue · comments
Following an upgrade to SNAPSHOT-20171002131949, we are unable to run dotnet publish. It throws the following error:
C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\CopyTargets\Microsoft.NET.Sdk.Publish.CopyFiles.targets(80,5): error MSB4006: There is a circular dependency in the target dependency graph involving target "Publish". [E:\BuildAgent\work\3f98e6a4b94cfd12\AppDev.IdentityServer4\AppDev.IdentityServer4.csproj]
We use TeamCity 2017.1.2 and dotnet 2.0.0.
As with my other issue, #85, this seems to be tied to the .rsp file, as these build steps used to work before the upgrade, and still do work without the .rsp (I can run dotnet publish on the build agent without error, but when I reference the .rsp, it fails).
I'd like to suggest providing a "keep it simple" option that turns off the .rsp to allow users to work around these .rsp-related issues. Maybe just a checkbox? Thanks!
@cdibbs try the new version, I've fixed issue with .rsp
rsp. is required for backward compatibility with MSBuild runner. It has a lot of TeamCity parameters
@cdibbs any updates?
@NikolayPianikov Thanks for reminding me about this. I was pulled onto other work for a bit. How does the version at https://plugins.jetbrains.com/plugin/9190--net-cli-support follow the ones listed, here? Is what's there, now, equivalent to 0.9.2? Thanks!
yes, but 0.9.2 does not contain latest fixes, try the latest version from here
Ok, we installed the latest, and that altered the output somewhat, but it still gives the same basic circular deps error. It now says build succeeded and then build failed in the same breath (the same run of the dotnet tool).
Again, without the .rsp file, the publish command works fine. Adding it back causes the error. Here's the full output of that build step: https://gist.github.com/cdibbs/22c7776b006e7b87605cfbc1ce2d3164
@cdibbs could you specify more detailed logging level? Is it possible to share some simple solution to reproduce?
I ended up taking a binary search approach to manually modifying the .rsp file left in BuildAgent/temp/buildTmp. I would delete half the lines in it, and rerun the command to see if it succeeded. If it failed, I would subdivide and repeat.
The error came from a system parameter that had accidentally been left in (we originally created this build configuration from an older version of this project). The parameter was:
/p:DeployOnBuild="true"
This solves the issue for us, since that parameter is redundant. I hope the binary search strategy is useful to anyone encountering similar issues.