[BUG] Visual Studio cannot open projects due to "Invalid static method invocation syntax" errors

[jgbright]

Describe the bug
I get errors when I try to open a dotnet project with Visual Studio 2022 community edition that uses the Directory.Build.props and Directory.Build.props files generated by nx-dotnet.

To Reproduce
Steps to reproduce the behavior:

1. Generate a nx-dotnet app with a sln.
2. Open the sln in Visual Studio 2022 community edition.
3. Observe that the project(s) are not actually loaded.
4. Right click on the project that failed to load and click on "Reload Project"
5. Observe error in popup dialog and in build output window.

---------------------------
Microsoft Visual Studio
---------------------------
Invalid static method invocation syntax: "[System.IO.Path]::GetRelativePath($(RepoRoot), $(MSBuildProjectDirectory))". Method 'System.IO.Path.GetRelativePath' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)). Check that all parameters are defined, are of the correct type, and are specified in the right order.  C:\Repos\MyProject\Directory.Build.props
---------------------------
OK   
---------------------------

Environment:

• OS: Windows 11
• IDE: Visual Studio 2022 community edition

Possible solution

I found the relevant documentation and it says any function in the System.IO.Path class should be invokable from these "property functions." So, it should work. It doesn't work on my box. There is another option that does work on my box and that's [MSBuild]::MakeRelative, which looks to be a drop-in replacement for [System.IO.Path]::GetRelativePath in this context.

This is the change I've made on my projects. I'm happy to submit a pull request if that helps.

[remkoboschker]

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

[remkoboschker]

It seems to break when run with dotnet build

[AgentEnder]

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

[tzuge]

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.

[AgentEnder]

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.

[tzuge]

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.

[jgbright]

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.

[AgentEnder]

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

[jgbright]

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
➜

[remkoboschker]

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

[AgentEnder]

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.

[tzuge]

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?

[pedrolamas]

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

[EelcoLos]

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 ;)

[github-actions]

🎉 This issue has been resolved in version 1.16.1 🎉

The release is available on:

• v1.16.1
• GitHub release

Your semantic-release bot 📦🚀

[jgbright]

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.

[AgentEnder]

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.

[pedrolamas]

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!)

[github-actions]

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.