New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Referencing MSBuildExtensionPath property in another property does not allow fallback #1735

Open
mletterle opened this Issue Feb 22, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@mletterle
Contributor

mletterle commented Feb 22, 2017

Repo

Consider the following msbuild file:

<Project>
 <Import Project="$(MSBuildExtensionsPath)\foo" />
</Project>

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 <Import> 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:

<Project>
   <PropertyGroup>
      <MyExtensionPath>$(MSBuildExtensionsPath)</MyExtensionPath>
   </PropertyGroup>
   <Import Project="$(MyExtensionPath)\foo" />
</Project>

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 <Import> 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:
//
//      <PropertyGroup><ProjectPathForImport>$(MSBuildExtensionsPath)\foo\extn.proj</ProjectPathForImport></PropertyGroup>
//      <Import Project='$(ProjectPathForImport)' />

ref here

@drolevar

This comment has been minimized.

Show comment
Hide comment
@drolevar

drolevar Mar 16, 2017

+1
I'm also having this issue when building Dotfuscator projects. They also rely on the same mechanism.

drolevar commented Mar 16, 2017

+1
I'm also having this issue when building Dotfuscator projects. They also rely on the same mechanism.

@truist

This comment has been minimized.

Show comment
Hide comment
@truist

truist Mar 16, 2017

@drolevar FYI PreEmptive/Dotfuscator will be releasing an updated version in the next few days that works around this issue. In the meantime we've posted a Knowledge Base article that gives a few options for working around it manually - see Issue: Building a VSIP project in Visual Studio 2017 fails since it cannot find PreEmptive.Dotfuscator.Targets.

truist commented Mar 16, 2017

@drolevar FYI PreEmptive/Dotfuscator will be releasing an updated version in the next few days that works around this issue. In the meantime we've posted a Knowledge Base article that gives a few options for working around it manually - see Issue: Building a VSIP project in Visual Studio 2017 fails since it cannot find PreEmptive.Dotfuscator.Targets.

@drolevar

This comment has been minimized.

Show comment
Hide comment
@drolevar

drolevar Mar 16, 2017

@truist Good to know! I have opted for option 2. But probably options 1 or 3 would be more future-proof, since the file gets overwritten.

drolevar commented Mar 16, 2017

@truist Good to know! I have opted for option 2. But probably options 1 or 3 would be more future-proof, since the file gets overwritten.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment