Project|Options|Use MSBUILD externally to compile

Project|Options|Use MSBUILD externally to compile

Why was this put in the project file!?

IMO, this should have been in the Project Group file, configurable under the Build Group settings.

 

9 thoughts on “Project|Options|Use MSBUILD externally to compile


  1. Personally, if it was that way, the “default” for the group would be in the project group file but the project could override it. The reason being that if I have a large project, the only way to compile successfully multiple times in a row is to shell out to MSBuild but for small projects, the internal compiler would able to do the job and be faster at it


    Just my 2c worth 🙂


  2. IMO, you would turn it on/off in the Build Group, like you set configuration and platform for each project.  I like the default/override suggestion.


  3. I guess only because there is not a single other project option at the project group level… you can handle configurations, not option. Still, you can use an external project options files to share settings for projects in a group. I know, not so simple to set up…


  4. Marco Cantù – The reason I balk at it being in the .dproj, is that my preferences for compiling may differ from those of my colleagues.  


    When I build a large project alone, I don’t normally run into memory issues, and rebuilding the same project doesn’t seem to eat as much memory as building multiple projects.


    I have a pretty large Project Group with several Build Group configurations, some of which barfs about half-way, and that’s why I’d love to be able to decide/override this in the in each Build Group.


  5. As long as there is no inflation of build configurations (i.e. just Release and Debug), you can create child configurations of each changing only that one setting. The Build Groups can then reference those child configurations.


  6. Lars Fosdal Many of us have missed many features since printed documentation ceased to exist. I think one reason D7 has remained string for so long is that its users have excellent printed docs. For my part, I have little doubt that I knew the ins and outs of D7 better than those of any of its successors.


  7. Bill Meyer  – That is true, but I have to admit that I haven’t used manuals for years.  The death of the oldschool help was bad, though.  It is baffling that in this day and age, where web content can be dynamic, rich, and searchable – that we don’t have better online documentation.


  8. Lars Fosdal The huge problem with non-linear docs is in ensuring reasonable coverage, as well as in making sure that intro sections get written. I’ve written a lot of docs, and not one was ever as terse or unhelpful as the average “help” file.

Leave a Reply to Bill MeyerCancel reply