dotnet / dotnet/msbuild

Referencing MSBuildExtensionPath property in another property does not allow fallback

Open
#1,735 3 comments 1 reaction 0 assignees View on GitHub
triaged
Dominant language
C#
Stars
5.5k
Forks
1.5k
Avg merge
1d 13h
Merged PRs (30d)
133

Description

**Repo**

Consider the following msbuild file:

```xml

```

When you attempt to build this project, you get the following error:

> ```C:\temp\foo.proj(2,10): error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\foo" was not found . Also, tried to find "foo" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\MSBuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths. ```

Which clearly states that it attempted to import the project and attempted to fallback to the `C:\Program Files (x86)\MSBuild` path after trying the local DevEnv path.

Now consider this slightly modified project file:

```xml


$(MSBuildExtensionsPath)

```

When this project is ran, the value of `MyExtensionPath` is immediately set to the default `MSBuildExtensionsPath` and you get the following error at build time:

>```C:\temp\foo.proj(5,2): error MSB4019: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\foo" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.```

As you can see, in this case msbuild only attempted to import from the local DevEnv path and no fallback was attempted.

**Expected**

Unsure. In the ideal case, when processing `Imports` (and maybe other tags?), you could walk up the Variable definitions and see if `MSBuildExtensionsPath` was used as part of the definition and use the same fallback logic as when it is directly referenced.

I suspect that this might be difficult, perhaps the error message could be expanded to reference the case that one might be using `MSBuildExtensionsPath` through an intermediary property.

At minimum, this should be documented in case a user trips over it.

**NB**

The current source for the Evaluator explicitly references this situation as unsupported:

```
// The value of the MSBuildExtensionsPath* property, will always be "visible" with it's default value, example, when read or
// referenced anywhere else. This is a very limited support, so, it doesn't come in to effect if the explicit reference to
// the $(MSBuildExtensionsPath) property is not present in the Project attribute of the Import element. So, the following is
// not supported:
//
// $(MSBuildExtensionsPath)\foo\extn.proj
//
```

ref [here](https://github.com/Microsoft/msbuild/blob/e5bc7994348dba88d1f6fe2ebd6aa354355f0063/src/Build/Evaluation/Evaluator.cs#L2233)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.