Share via

More on configurations

  • Article

Greetings, all!  In my entry
about devenv /build, a reader named Toby mentions the pain of maintaining multiple
configurations when you have a lot of them that are identical except for one flag.  He
says:

"urn:schemas-microsoft-com:office:office" />

 

In my work, I'll deal with
several types of configurations: release, debug, profile build, unicode/mbcs, managed/unmanaged,
xbox/pc, inline assembly/unoptimized C, etc. Some of these are truly unique configurations,
requiring differing compiler options, etc. However, some are really just toggling
a flag (unicode/mbcs for example). Each of these toggled flags requires twice the
number of configurations. And when one of the configurations changes, all of the variants
need to be changed.

 

I’m sorry that this is a less than pleasant experience, Toby.  I
don’t know of any way to do this any better than the workarounds you mentioned, at
least for VS 2002 / 2003.  What you really
want is a way to define a solution configuration that sets a few variables and then
passes those into project configurations that are otherwise shared.

 

I can say that we are doing some things in the next version of VS (known as Whidbey)
that should make this significantly less painful, especially in the command-line build
scenario, although you may have to do a little low-level project file tweaking.  We’re
announcing some Whidbey features related to this area at the PDC in late October,
so interested people should stay tuned (and I’ll be commenting on these new Whidbey
features here in my blog).

 

Toby also asks why this evolved the way it did.  I’ve
been working in the solution/project area for only about a year & a half now,
so I don’t have lots of insight into the historical evolution of this feature.  But
I would guess that most users are not doing the multi-axis customization of builds
that Toby is, so this scenario was never really optimized for.  But
being able to richly handle this kind of scenario, unconstrained by any particular
assumptions of the IDE, is definitely the direction we are moving in for Whidbey &
beyond.

 

That’s all for now! -Chris

Comments

  • Anonymous
    September 21, 2003
    I have tried on a number of occasions to get the /deploy option to work. I believe the following should work... "devenv /deploy Debug MySolution.sln /out my.log", but it doesn't. There's no mention of a error or anything in the log file. I've also tried pretty much every combination of /project and /projectconfig to no avail. Is /deploy supposed to work with vdproj files or am I missing the point? I would love to get this working as it would greatly simplify my build files.
  • Anonymous
    December 24, 2003
    Just tripped across this so pardon if I'm comenting on an old topic, but Visual Studio GETS IT WRONG.'Toby' is dead right -- and this shouldn't be such a big deal.But it is. Because Microsoft -- for years -- simply DOES NOT GET IT.There's a solution to this problem (and a host of like issues):STYLESHEETSGo look up Borland C++ 4.xThey botched their quality and killed their market presence, but they supported a stylesheet-like configuration.I want a LAYERED set of options.Apply the hard-coded defaults.Then MyCompany.settingsThen MyDivision.settingsThen MyProduct.settingsThen MyConfig.settings (aka the 'Flavor', or as VC/VS puts it, the 'Configuration')Why is this so hard to grasp?"Add these settings, Remove these settings, and inherit everything else", N layers deep.BC++ 4.x had this (though not as extensive as I'd like, if memory serves).For something a little closer to home...Microsoft Word has it.I've talked to numerous people in the VS and VC teams over the years, and for those who immediately grasped the point (a notable %, to their credit) all pointed to 'current release freeze' and 'you should talk to so-and-so' -- almost a "not my problem" sort of thing. Well intentioned, but in the end nothing has ever happened.Yes I'm a little cranky.I've been poking and prodding Microsoft folks to do this for almost a decade now.This is one reason why MAKE-based solutions are the norm. As Morpheous would say - "Control." Microsoft's C++ IDE has never provided the necessary degree of control to solve this issue.It's a scope issue.Small little Windows-only dev shops, not such a (big) headache.As you scale up -- bigger companies, more projects, ...esp. enterprise class development -- Microsoft's notion of "project management" in the C++ IDE has been severely lacking at best.[Don't take it too hard -- everyone else's IDE seems to have the same problem. "Do it just like this", 'cause after all, one size surely fits all...]</rant>The 'stylesheet' approach is the only one I've ever heard of that could solve this problem, though I'd love to hear if someone else knows an equally effective alternative.I would love to see Microsoft finally solve this problem.Open invitation to the VS team: contact me any time on this subject.Please.