MSBuild warning MSB4011 for multiple imports is harmful for property sheets - by CornedBee

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 726728 Comments
Status Closed Workarounds
Type Bug Repros 3
Opened 2/27/2012 3:12:12 AM
Access Restriction Public
Moderator Decision Sent to Engineering Team for consideration


I have a bunch of static C++ libraries. Each of those has an associated property sheet that a project using the static library is supposed to import. The property sheet sets the library and include paths and may do other things, such as setting related preprocessor macros. It also imports the property sheets of the libraries it depends on itself, so that importing projects don't have to worry about transitive dependencies.

I have a library called libutil which contains basic utility functions. I have two more libraries, call them libfoo and libbar, both of which depend on libutil. Finally I have an app, call it app, which uses both libfoo and libbar.
libfoo's property sheet includes libutil's property sheet, as does libbar's. app's project then includes both libfoo's and libbar's property sheets.
And this means that libutil's property sheet is included twice, issuing MSB4011. I don't want this warning; the warning doesn't tell me anything I don't know, doesn't tell me that anything is wrong (because my setup is anything but unusual or dangerous), doesn't tell me anything about unexpected behavior (ignoring the repeated import is the right thing to do), and clutters my build output, but there is no way to disable or otherwise suppress it without a convoluted workaround that I'll post in the workaround section.
Sign in to post a comment.
Posted by Wyck on 4/1/2013 at 1:35 PM
I don't think this workaround is acceptable.

Every consumer of a property sheet would now require an "include guard" of some kind. It's clear from the history of C++ that this would be undesirable. The C++ equivalent of what's going on here is that a simple #include <string> has now become: #ifndef STRING_INCLUDED #include <string> #endif And it's not clear how to select the appropriate definition to guard against.

It's obvious this include guard has already been implemented internally, so why not allow us to take advantage of it by selectively disabling this warning?

If you're concerned about making the author opt-in to this, then have the included .props file declare the equivalent of "pragma once" so that subsequent imports are ignored.

Basically we want exactly the current behaviour, but without the warning. I propose that turning off the warning in the included .props file is the best idea here.
Posted by CornedBee on 3/6/2012 at 1:23 PM
Yay, include guards, but this time they're not even self-contained.
Posted by Amit [MSFT] on 3/5/2012 at 1:08 PM

To resolve this issue please define a property inside a prop sheet and check for it when importing the property sheet such that the property sheet is not imported twice.

Amit Mohindra
Visual C++ Team
Posted by CookieSnarf on 3/2/2012 at 7:39 PM
We use the same pattern at my company. It worked fine in VS2005 and VS2008. But after we updated to VS2010, we started getting lots of these useless MSB4011 warnings.

X.props(4,5): warning MSB4011: "Y.props" cannot be imported again. It was already imported at "Z.props (4,5)". This is most likely a build authoring error. This subsequent import will be ignored.

I haven't seen a better way to deal with the include paths from a bunch of reusable C++ libraries.
Copy & pasting the include paths to each project or putting all the headers in a common location are both painful to maintain.
Posted by Microsoft on 2/28/2012 at 1:22 AM
Thanks again for your quick response. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.
Posted by CornedBee on 2/28/2012 at 12:53 AM
I have attached a minimal project that exhibits the warning on build.
Posted by Microsoft on 2/28/2012 at 12:13 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(
Posted by MS-Moderator08 [Feedback Moderator] on 2/27/2012 at 11:25 PM
Thank you for reporting this issue. Could you please attach a sample project to help us reproduce this issue?