WDK 8.x and managing build settings

With the recent video on osr.com about Visual Studio / WDK integration
and coming across a discussion from last year about the hassle of
keeping a single set of build settings
(http://www.osronline.com/showthread.cfm?link=251080), I was wondering
if people were aware of how to use property sheets to maintain build
settings that are common across different platforms - in a simpler way
than having to remember to select “All Configurations” and “All Platforms”?

I hadn’t until about a year ago, but quickly realized how useful they
are.
http://msdn.microsoft.com/en-us/library/669zx6zc.aspx#bkmkPropertySheets
explains them, though with the help of Intellisense it may be simpler to
author them manually if you’re familiar with MSBuild. We use them to
make sure things like the warning level, LTCG, minimal rebuild etc. are
configured correctly, and add them to any new projects we create.


Bruce

On Jun 28, 2014, at 3:16 PM, Bruce Cran wrote:
> With the recent video on osr.com about Visual Studio / WDK integration
> and coming across a discussion from last year about the hassle of
> keeping a single set of build settings …
>
> I hadn’t until about a year ago, but quickly realized how useful they
> are.
> http://msdn.microsoft.com/en-us/library/669zx6zc.aspx#bkmkPropertySheets
> explains them, though with the help of Intellisense it may be simpler to
> author them manually if you’re familiar with MSBuild.

As a dinosaur, that?s exactly what I do. I maintain all of my vcxproj files by hand (with gvim, the world?s greatest editor ;). In fact, I wrote a Python script that factors out all of the ?common settings? to eliminate duplication. The IDE will create 12 virtually identical blocks, one for Win 7 Debug 32, one for Win 7 Release 32, one for Win 7 Debug 64, and so on. My script creates one undecorated global block, then one for Debug, then one for Release, then one for 32, then one for 64. It results in much smaller vcxproj files that are much easier to maintain by hand. Adding a new operating system will be trivially simple.

Of course, if I ever edit the settings in the IDE, it insists on recreating the 12 individual sections. So, I never edit my settings in the IDE.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

That last part was the killer for me. With multiple people working on
shared projects *somebody* is going to use the IDE and then everything goes
to hell. Plus there are some settings that if you optimize into global
settings don’t get displayed correctly in the IDE.

I ended up with “semi-optimized” project files.

Mark Roddy

On Sun, Jun 29, 2014 at 1:16 AM, Tim Roberts wrote:

> On Jun 28, 2014, at 3:16 PM, Bruce Cran wrote:
> > With the recent video on osr.com about Visual Studio / WDK integration
> > and coming across a discussion from last year about the hassle of
> > keeping a single set of build settings …
> >
> > I hadn’t until about a year ago, but quickly realized how useful they
> > are.
> > http://msdn.microsoft.com/en-us/library/669zx6zc.aspx#bkmkPropertySheets
> > explains them, though with the help of Intellisense it may be simpler to
> > author them manually if you’re familiar with MSBuild.
>
> As a dinosaur, that’s exactly what I do. I maintain all of my vcxproj
> files by hand (with gvim, the world’s greatest editor ;). In fact, I wrote
> a Python script that factors out all of the “common settings” to eliminate
> duplication. The IDE will create 12 virtually identical
> blocks, one for Win 7 Debug 32, one for Win 7 Release
> 32, one for Win 7 Debug 64, and so on. My script creates one undecorated
> global block, then one for Debug, then one for
> Release, then one for 32, then one for 64. It results in much smaller
> vcxproj files that are much easier to maintain by hand. Adding a new
> operating system will be trivially simple.
>
> Of course, if I ever edit the settings in the IDE, it insists on
> recreating the 12 individual sections. So, I never edit my settings in the
> IDE.
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

In general CMake rocks for this stuff, though it won’t help with drivers at the moment.

mm

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, July 01, 2014 12:40 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDK 8.x and managing build settings

That last part was the killer for me. With multiple people working on shared projects *somebody* is going to use the IDE and then everything goes to hell. Plus there are some settings that if you optimize into global settings don’t get displayed correctly in the IDE.

I ended up with “semi-optimized” project files.

Mark Roddy

On Sun, Jun 29, 2014 at 1:16 AM, Tim Roberts wrote:

On Jun 28, 2014, at 3:16 PM, Bruce Cran wrote:
> With the recent video on osr.com about Visual Studio / WDK integration
> and coming across a discussion from last year about the hassle of

> keeping a single set of build settings …

>
> I hadn’t until about a year ago, but quickly realized how useful they
> are.
> http://msdn.microsoft.com/en-us/library/669zx6zc.aspx#bkmkPropertySheets
> explains them, though with the help of Intellisense it may be simpler to
> author them manually if you’re familiar with MSBuild.

As a dinosaur, that’s exactly what I do. I maintain all of my vcxproj files by hand (with gvim, the world’s greatest editor ;). In fact, I wrote a Python script that factors out all of the “common settings” to eliminate duplication. The IDE will create 12 virtually identical blocks, one for Win 7 Debug 32, one for Win 7 Release 32, one for Win 7 Debug 64, and so on. My script creates one undecorated global block, then one for Debug, then one for Release, then one for 32, then one for 64. It results in much smaller vcxproj files that are much easier to maintain by hand. Adding a new operating system will be trivially simple.

Of course, if I ever edit the settings in the IDE, it insists on recreating the 12 individual sections. So, I never edit my settings in the IDE.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

That’s why I leave it up to Visual Studio to manage the .vcxproj files
except to add properties, post-build targets etc. which it doesn’t mess up.


Bruce

On 7/1/2014 1:40 PM, Mark Roddy wrote:

That last part was the killer for me. With multiple people working on
shared projects *somebody* is going to use the IDE and then everything
goes to hell. Plus there are some settings that if you optimize into
global settings don’t get displayed correctly in the IDE.

I ended up with “semi-optimized” project files.

Mark Roddy

On Sun, Jun 29, 2014 at 1:16 AM, Tim Roberts > mailto:xxxxx> wrote:
>
> On Jun 28, 2014, at 3:16 PM, Bruce Cran > mailto:xxxxx> wrote:
> > With the recent video on osr.com http: about Visual
> Studio / WDK integration
> > and coming across a discussion from last year about the hassle of
> > keeping a single set of build settings …
> >
> > I hadn’t until about a year ago, but quickly realized how useful
> they
> > are.
> >
> http://msdn.microsoft.com/en-us/library/669zx6zc.aspx#bkmkPropertySheets
> > explains them, though with the help of Intellisense it may be
> simpler to
> > author them manually if you’re familiar with MSBuild.
>
> As a dinosaur, that’s exactly what I do. I maintain all of my
> vcxproj files by hand (with gvim, the world’s greatest editor ;).
> In fact, I wrote a Python script that factors out all of the
> “common settings” to eliminate duplication. The IDE will create
> 12 virtually identical blocks, one for Win 7
> Debug 32, one for Win 7 Release 32, one for Win 7 Debug 64, and so
> on. My script creates one undecorated global
> block, then one for Debug, then one for
> Release, then one for 32, then one for 64. It results in much
> smaller vcxproj files that are much easier to maintain by hand.
> Adding a new operating system will be trivially simple.
>
> Of course, if I ever edit the settings in the IDE, it insists on
> recreating the 12 individual sections. So, I never edit my
> settings in the IDE.
> –
> Tim Roberts, xxxxx@probo.com mailto:xxxxx
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe,
> visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx>