Building both DLL and static libs from the same project

I have a number of native C++ libraries (Win32, without MFC) compiling under Visual Studio 2005, and used in a number of solutions.

I'd like to be able to choose to compile and link them as either static libraries or DLLs, depending on the needs of the particular solution in which I'm using them.

What's the best way to do this? I've considered these approaches:

1. Multiple project files

• Example: "foo_static.vcproj" vs "foo_dll.vcproj"
• Pro: easy to generate for new libraries, not too much manual vcproj munging.
• Con: settings, file lists, etc. in two places get out of sync too easily.

2. Single project file, multiple configurations

• Example: "Debug | Win32" vs "Debug DLL | Win32", etc.
• Pro: file lists are easier to keep in sync; compilation options are somewhat easier to keep in sync
• Con: I build for both Win32 and Smart Device targets, so I already have multiple configurations; I don't want to make my combinatorial explosion worse ("Static library for FooPhone | WinMobile 6", "Dynamic library for FooPhone | WinMobile 6", "Static library for BarPda | WinMobile 6", etc.
• Worse Con: VS 2005 has a bad habit of assuming that if you have a configuration defined for platform "Foo", then you really need it for all other platforms in your solution, and haphazardly inserts all permutations of configuration/platform configurations all over the affected vcproj files, whether valid or not. (Bug filed with MS; closed as WONTFIX.)

3. Single project file, selecting static or dynamic via vsprops files

• Example: store the appropriate vcproj fragments in property sheet files, then apply the "FooApp Static Library" property sheet to config/platform combinations when you want static libs, and apply the "FooApp DLL" property sheet when you want DLLs.
• Pros: This is what I really want to do!
• Cons: It doesn't seem possible. It seems that the .vcproj attribute that switches between static and dynamic libraries (the ConfigurationType attribute of the Configuration element) isn't overrideable by the .vsprops file. Microsoft's published schema for these files lists only <Tool> and <UserMacro> elements.

EDIT: In case someone suggests it, I've also tried a more "clever" version of #3, in which I define a .vsprops containing a UserMacro called "ModuleConfigurationType" with a value of either "2" (DLL) or "4" (static library), and changed the configuration in the .vcproj to have ConfigurationType="$(ModuleConfigurationType)". Visual Studio silently and without warning removes the attribute and replaces it with ConfigurationType="1". So helpful!

Am I missing a better solution?

I may have missed something, but why can't you define the DLL project with no files, and just have it link the lib created by the other project? And, with respect to settings, you can factor them out in vsprop files...