Editing MSBuild .targets files ... bogus warnings

I'm not certain whether it's ReSharper or VS, but editing a .targets file in VS2008 shows a lot of squiggles and "undefined" terms that are defined just fine.

For example, all these predefined symbols are listed as properties that are not defined:






As well as items we've defined ourselves.  These ARE defined (builds are successful), but they're showing up with warnings and error stripes in the ReSharper error bar, and I have no clue how to eliminate them.

Any ideas?  Is this something that can be fixed in 5.0 if it's a real problem that exists in 4.x?



For example, all these predefined symbols are listed as properties
that are not defined:


MSBuild has these properties predefined: MSBuildProjectDirectory, MSBuildProjectFile,
MSBuildProjectExtension, MSBuildProjectFullPath, MSBuildProjectName, MSBuildBinPath,
MSBuildProjectDefaultTargets, MSBuildExtensionsPath. All of the others are
custom to some extent; they could be defined in the project file, in the
.targets files included in the project, and so on. Some are guaranteed to
exist in a Visual Studio project when building from within a solution, others
are added by installed packages like MSTest that provide more .targets files,
and so on.

As you say you're

editing a .targets file

this probably means that the file is not self-contained. Not only it could
include other files (these should be an easy thing for ReSharper to inspect),
but the file itself is included into some project. That parent project could
be defining those properties before including the .targets file in question,
and the .targets file has no reference to that parent project -- the <Include/>
only links one way. ReSharper could have some difficulties figuring out where
the .targets is intended to be included and what properties should be available
from that environment.

ReSharper got some logic for guessing the parent project file. If you open
the two files side-by-side, or add them to the same project, ReSharper could
find the <Include/> and make a note of the parent backlink. This way the
properties from the parent project could get known to the child .targets
file. If this heuristic is not working for you, then either the case is too
complicated or the logic is broken and it's not too late to fix it yet for
this release if we get more info on the case, like a small repro that demonstrates
the wrong behavior.

As well as items we've defined ourselves.  These ARE defined (builds
are successful),

MSBuild has no exact notion of defined or undefined properties, all of the
possible properties are "defined" to an empty value, much like in Javascript.
Indeed a build would not fail if you use an undefined property, that's why
they're warnings not errors in R#.

but they're showing up with warnings and error
stripes in the ReSharper error bar,

Currently we're not picking any of Visual Studio anaylses for the Error Stripe.
The fact they're present means those are ReSharper results.

Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


I'm not the most experienced MSBuild person in the world, I just know ReSharper is showing tons of warnings and "undefined" issues where everything is perfectly well defined.  These .targets files are part of our build system, and really aren't part of any project or solution.  Perhaps I could work with others on the team to come up with some better organization for these things, but right now we just push them out to the build machines and it all just works.

I also know that we aren't creating those symbols ($(SolutionRoot), et al) that I listed.  They're Microsoft defined symbols that we're using.  ReSharper certainly shouldn't be flagging those as undefined.

There is at least one case where a "DependsOnTarget=xxxxx" symbol is undefined, even though "Target xxxxx" is defined in the exact same .targets file.

Perhaps the best thing to do is just provide an option to turn off all the symbol checking in .targets files, since from the sounds of things, there's little you can do to figure things out.

Whatever the solution, the current situation seems the worst of all worlds... dozens of warnings and an error strip that seems more yellow than not... and nothing that can be done to fix it.


Hello Paul
     Could you please send your .targets and .build files to andrew dot serebryansky at jetbrains dot com (with the corresponding folder structure if the files are located in different folders)? This would really help us to track the problem down. Thank you!

Andrey Serebryansky

Support Engineer

JetBrains, Inc


"Develop with pleasure!"

Please sign in to leave a comment.