search

leonardochaia / dotnet-affected

.NET tool for determining which projects are affected by a set of changes. Useful for large projects or monorepos.
MIT License
213 stars 17 forks source link

Internal MSBuild Error: ../my-solution.sln unexpectedly not a rooted path #90

Closed vdurante closed 10 months ago

vdurante commented 10 months ago

Did anyone face similar issue? I recently upgraded from 3.1.1 to 3.2.0

Running the following command

dotnet dotnet-affected -v --format text traversal --solution-path ../my-solution.sln --output-dir ../ --from origin/feat-upgrade --to origin/develop

I now get the following error

Unhandled exception: Microsoft.Build.Framework.InternalErrorException: MSB0001: Internal MSBuild Error: ../awork-backend.sln unexpectedly not a rooted path

Any ideas or suggestions?

leonardochaia commented 10 months ago

Hi @vdurante , I think you figure it out yourself, however, wanna share what happened for the next person to stumble on this error? At a glance I don't really know how you fixed it :+1:

Thanks and thanks for using the tool, hope it works for you :+1:

vdurante commented 9 months ago

@leonardochaia hey! I can definitely explain what happened and what I did to fix, but it had nothing to do with dotnet-affected.

The solution path has to be an absolute path, not a relative one. That's why it is failing. MSBuild expects absolute paths.

In my specific case, I was using dotnet-affected inside a Nuke pipeline. When I updated Nuke and dotnet-affected, I noticed my code for getting affected projects started failing, so I thought it was caused by a change in dotnet-affected. I later found out it was actually a change in how Nuke handles arguments that are passed to cli tools, which made dotnet-affected get the path argument encoded in a way that made MSBuild treat it as a relative path.

I changed the way the path argument was built and the dotnet-affected CLI worked perfectly.