For some reason, it wants to add per-file configurations
(<FileConfiguration> elements) for *all* .cpp files, and set
"VCCLCompilerTool" options per file - even for files that did not have
unique settings in VC 6.0. These per-file configurations have been
interfering when changes to global project settings are needed.
If you upgrade a .dsw/.dsp to a VC 7.0 .sln/.vcproj, and update that
same .dsw/.dsp to 7.1 or Whidbey, there's a handful of differences, but
the spurious per-file configurations seem like a bad decision.
For example, on one project, here's what the additional
<FileConfiguration> looks like for a .cpp
<FileConfiguration
Name="Debug|Win32">
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories=""
PreprocessorDefinitions=""
BasicRuntimeChecks="3"
BrowseInformation="1"/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
<Tool
Name="VCCLCompilerTool"
Optimization="2"
AdditionalIncludeDirectories=""
PreprocessorDefinitions=""/>
</FileConfiguration>
and for an .rc file:
<FileConfiguration
Name="Debug|Win32">
<Tool
Name="VCResourceCompilerTool"
PreprocessorDefinitions="_DEBUG;$(NoInherit)"/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
<Tool
Name="VCResourceCompilerTool"
PreprocessorDefinitions="NDEBUG;$(NoInherit)"/>
</FileConfiguration>
Why does it do this? The 6.0 project didn't have special per-file
configurations for these files. It's problematic to go rip out the
spurious <FileConfiguration> elements, because some files actually do
need per-file configurations (like stdafx.cpp).
For example, with stdafx.cpp, here's how 7.0 upgraded the .dsp to the
.vcproj:
<File
RelativePath=".\stdafx.cpp">
<FileConfiguration
Name="Debug|Win32">
<Tool
Name="VCCLCompilerTool"
UsePrecompiledHeader="1"/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
<Tool
Name="VCCLCompilerTool"
UsePrecompiledHeader="1"/>
</FileConfiguration>
</File>
and here's how 7.1 upgrades the .dsp to the 7.1 vcproj:
<File
RelativePath="stdafx.cpp">
<FileConfiguration
Name="Debug|Win32">
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories=""
PreprocessorDefinitions=""
BasicRuntimeChecks="3"
UsePrecompiledHeader="1"
BrowseInformation="1"/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32">
<Tool
Name="VCCLCompilerTool"
Optimization="2"
AdditionalIncludeDirectories=""
PreprocessorDefinitions=""
UsePrecompiledHeader="1"/>
</FileConfiguration>
</File>
Can this question be revisited before Whidbey or a VC 7.1 Service Pack
are released?
Thanks,
-Daniel
Thanks for posting in the community.
Currently I am looking for some resource to work on your problem. We will
reply here with more information as soon as possible.
If you have any more concerns on it, please feel free to post here.
Thanks!
Best regards,
Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
I consult your concern to the product dev team, they consider it maybe an
issue.
They also think file-level settings should never be added if they didn't
exist in the VC6 project.
Would you please upload a .dsp file(zipped) that exhibits this behavior to
let us perform some research on this problem?.
Very thanks for your sample project and detail notes to it!
I have already send them to the product dev team, it will help us a lot to
examine this upgrading issue.
Our product and test team have already confirmed it as an issue with your
feedback and sample project, they will perform some work to cover it.
Very thanks for your valuable feedback and concerns on our VS.NET product!
We are looking for continual improvement, and it's this kind of feedback
that let's us know what things you like to do, that maybe we just miss it
for you.
Thanks!
-Daniel