I am having the same issue in our build pipeline that uses msbuild. @jgbright Does the commit in your forked repo fix the issue?

It seems to break when run with dotnet build

This is interesting! I wonder if there is some versioning issue. @tzuge have you seen something like this crop up?

This is interesting! I wonder if there is some versioning issue. @tzuge have you seen something like this crop up?

No, I haven't hit this issue. We're building in github actions using the nx affected:build command with this plugin, so dotnet build. My understanding is that github actions runners have dotnet 6 SDK pre-installed.

I recall there is some weirdness on tool stacks in dotnet. Visual Studio might use its own thing, then msbuild cli is/was part of Windows SDK?, and dotnet cli is in dotnet SDK? I suspect it would be some version thing related to those various cli build tools.

Yeah, I imagine it is related to the versioning of one of those pieces.... Is there a way that we could check if the methods are defined before invoking them? I understand that it would get longer, but we could always tuck these variable declarations away in node_modules/@nx-dotnet/core/presets or similar and reference them in the generated files.

I think perhaps the right approach is to check dotnet cli tool versions in the init generator and fail with helpful message if not in the supported range. i.e. run dotnet --version, dotnet msbuild --version, etc. Not sure about if Visual Studio requires its own handling though, since the nx commands run on dotnet cli but VS might do its own thing for the csproj loading.

Keep in mind you can specify what version of the dotnet tool chain to use with a global.json file. I wonder if that’s why I see the problem and others do not.

Yeah, we can definitely define a supported version of the toolchain... I generally tend towards being more open with the .NET SDK version installed, and doing some mapping as required here and there (most notably, the format executor handles a lot of this). Its more work on our side of things, but I tend to find that in the .NET land dev's are not always super up to date on their tooling versions.

@jgbright and @remkoboschker Can yall run dotnet --version and dotnet msbuild --version? We verify against 6.0.3 and 7 in our nightly smoke tests, but newer versions should certainly be fine too

Sure.

➜ dotnet --version
6.0.402
 C:\Repos\MyProject :: main ≡                                                                     |  18.2.0 |  97  | 14:13:01
➜ dotnet msbuild --version
MSBuild version 17.3.2+561848881 for .NET
17.3.2.46306
 C:\Repos\MyProject :: main ≡                                                                     |  18.2.0 |  97  | 14:13:09
➜ Get-Content global.json
{
    "sdk": {
        "version": "6.0.401",
        "rollForward": "latestFeature"
    }
}
 C:\Repos\MyProject :: main ≡                                                                     |  18.2.0 |  97  | 14:13:19
➜

dotnet 6.0.402 works fine with [System.IO.Path]::GetRelativePath, but msbuild version '17.3.1.41501' does not

That's quite interesting.... I'll do some digging and see if I can narrow down why GetRelativePath isn't present in those versions. I'll see if I can't figure out either minimum defined versions or similar.

This one might be relevant: dotnet/sdk#1967

I get the impression that there might be a few scenarios in which msbuild cannot resolve the system assemblies leading to this error. I believe it would help to know:

1. Which tools work and which ones don't? dotnet, msbuild, VS project loading
2. Are there multiple msbuild installations in the environment.
3. How does dotnet and VS select a msbuild installation?

Just replace [System.IO.Path]::GetRelativePath with [MSBuild]::MakeRelative, problem solved!

Just replace [System.IO.Path]::GetRelativePath with [MSBuild]::MakeRelative, problem solved!

You sir just made my day... just stumbling on your reply when I needed it /salute

This works btw ;)

🎉 This issue has been resolved in version 1.16.1 🎉

The release is available on:

• v1.16.1
• GitHub release

Your semantic-release bot 📦🚀

If I had known you guys were so receptive to pull requests, I would have just submitted the change I made myself. Thanks for submitting it for me @pedrolamas.

There's a leftover issue on windows caught by our smoke tests, but its unrelated to this PR. Pushing a fix now.

@jgbright I try to be receptive to PRs in particular, as I don't have a ton of time to spend working on the plugin, unfortunately, and any contributions help immensely. In this particular case, I didn't ask for a PR at first as I prefer the System.IO.Path implementation, but I had a hard time tracking down what was causing it actually to break. There's a weird number of systems interacting here, and it's hard to pin a version causing the issue.

In any case, the MSBuild namespaced method appears to be working properly, so we will continue with it for now.

Thanks @jgbright, but being honest, I only now noticed you mentioned it in your original issue as a possible solution! 😁

This is a trick I've used some times in the past when I was still doing Windows Development (though I can't say I miss those days that much, tbh!)

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.