Inherited Properties and Property Sheets

re: Inherited Properties and Property Sheets

Pavan Adharapurapu — Wed, 29 Jul 2009 00:57:03 GMT

This is a response to the comment on Monday, July 27, 2009 3:38 AM by David Ward

MSBuild considers all relative paths appearing in Import statements to be relative to the importing file. In other words, if property sheet "A" imports property sheet "B" such that the import statement for "B" in "A" contains a relative path, then MSBuild considers it as relative to "A"'s location. However, we have a bug in Beta1 (the version you are using) wherein the project system computes the path relative to the *project* :( Hence when you add property sheets through the UI, you will see incorrect relative paths printed in the Import statements whenever the relative path w.r.t to project is different from relative path w.r.t. the importing property sheet. We have fixed this bug and in Beta2 you should be able to create your hierarchy of property sheets and use it in multiple projects.

For now, as a work around, you can manually correct the import paths using notepad. With such a correction, the build will work fine although the UI may be confused.

re: Inherited Properties and Property Sheets

David Ward — Mon, 27 Jul 2009 10:38:50 GMT

We have always had trouble using inherited property sheets effectively. I understand that relative paths are wrt to the project. This isn't very useful as we would like to define a hierarchy of propertysheets and share them across projects.

The only (unsatisfactory) solution we came up with is to use $(SolutionDir)/PropertySheets/.... which forces to put all our solutions at the same level in source.

Is there are more effective way?

Regards,

David.

re: Inherited Properties and Property Sheets

bahbar — Thu, 09 Jul 2009 11:56:48 GMT

I have only tested 2008 so far, so sorry if this is not relevant for 2010. However, it looks like none of the following issues have been addressed :

1) Finding exactly what a property sheet defines from the IDE is a pain. One has to open all the Rules one by one to try to find what it actually affects. AFAIK, there is no way to open the corresponding xml file either (again, from the IDE)

2) related, finding which file stores the sheet is non trivial . only the filename shows in the context menu, not the the path. Double clicking opens the properties dialog, not the underlying file. You know where it is, please let me look :D

3) When I see a unexpected inherited property, finding which property sheet defines it is painful (especially when there are many sheets).

There... I already feel better

re: Inherited Properties and Property Sheets

Brian Tyler — Fri, 03 Jul 2009 01:40:02 GMT

Jalf,

Good points - the first issue is something we need to clean up, the second is by design. Let me go into some more detail...

Wizards and their behavior

--------------------------

Yes, you are correct that the current wizards set too many values that are the defaults - we need to stop doing that. There is a discussion going on right now about that, but I can't say what, if anything, is going to be done - the code change is small, but the QA is larger, and there is still a lot of work to do before release. However - you have been heard!

General Properties

------------------

This one is harder to explain in a short space, but we'll have a blog post coming that explains the layout of .vcxproj files.

However, if you open it up, you'll see a group of properties that are set before Microsoft.cpp.props and then those that are set after. The ones that are set before that import are mostly the "General" properties and they control the system property sheets (and other cogs of the VC++ build system) that are brought in. For example, if you select Unicode or MSBC, or EXE or Makefile, it all controls what happens inside Microsoft.Cpp.props.

Therefore, these properties cannot be controlled via property sheets. It's a trade-off we had to make to avoid the complexity of pre-import and a pre-pre-import and a pre-pre-pre-import. I won't say it's a perfect solution, but it is one that we had to make some trade-offs on.

I doubt we are going to be able to change them this late in the game (the change has major ramifications through-out the system), but please file Connect issues with the ones you feel are serious problems. That will get them into discussions (yes, we look at Connect very closely for the Beta).

re: Inherited Properties and Property Sheets

Jalf1 — Thu, 02 Jul 2009 12:54:12 GMT

"What this allows Microsoft to do is define the defaults in a set of files that all projects import – and therefore not have to replicate them in everyone’s project file."

And yet you do just that (as seen in the bolded line in the example above. Why is so much replicated in everyone's project file by default?

The thing I really don't understand about property sheets is why you give us the feature, and then try to make it as troublesome as possible to use?

Please, in VS2010, can we have default projects that rely 100% on property sheets, without overriding anything in the .vcxproj? That would make it so much simpler for us to define our own property sheets. It is such a pain to have to manually clear out all your overrides in order for our property sheets to take effect.

Pretty please? You've got the feature, let's use it.

And the second problem is that for some reason, half the features under the General pane are not exposed to property sheets. I can't use a property sheet to toggle between dll/lib/exe, or switch Unicode on and off (or link-time code generation). Why why why why?

Those are my two complaints about property sheets. Both seem like simple oversights that could be fixed in about 20 minutes. But we've had to suffer them for years now. Any chance of a fix?