D8036 error with converted solution (2008->2010)

Question

Hello,

I am running into a D8036 error when building a converted solution (2008->2010). More details follow.

(This paragraph is here just in case it might be the cause of the problem, feel free to skip it on first read.) I converted my 2008 solution with 8 projects (4 EXEs, 4 DLLs, 3 property sheets) to 2010 format according to walkthrough instructions. Only problem I had was that the property sheets that were inherited from other property sheets were not correctly converted, so to workaround (according to another post in this forum), in the next project to convert, I edited it by text editor before conversion and in one configuration (i.e. Debug), I changed name of the directly inherited property sheet to the indirectly inherited. After conversion, I hand-edited both the 2008 and 2010 format project and corrected the name of property sheet back to the real value. This way, since I have 8 projects and 3 property sheets, I was done after 3 projects (including the first where I learned about the problem). I am writing about this just in case it could have had an influence on my actual problem.

Then I added project-to-project references and typed msbuild.exe Punctus.sln, and it ended with an error (this output is copy/pasted from the Console window):

  C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I"\"Z:\Downlo
  ads\Boost_1_34_1\"" /I"\"C:\Program Files\GnuWin32\include\"" /I"Z:\platform-
  test\Punctus\include\\" /ZI /nologo /W4 /Od /D WIN32 /D _DEBUG /D _WINDOWS /D
   _USRDLL /D CZECH_EXPORTS /D Punctus_Czech_DLL /D Punctus_Czech_EXPORTS /D BO
  OST_ALL_DYN_LINK /D BOOST_IOSTREAMS_NO_LIB /D "BOOST_LIB_TOOLSET=\\\"vc100\\\
  "" /D _SCL_SECURE_NO_WARNINGS /D Punctus_TextSource_DLL /D Punctus_Czech_DLL
  /D Punctus_Dict_DLL /D Punctus_Logic_DLL /D _WINDLL /D _UNICODE /D UNICODE /G
  m /EHsc /RTC1 /MDd /Fp".objs\\CzechCzech.pch" /Fo".objs\\Czech" /Fd".objs\\Cz
  echvc100.pdb" /TP Encodings.cpp Letters.cpp MorphTag.cpp Word.cpp

  Tracker (omitted, seems the same as above)

cl : Command line error D8036: '/Fo.objs\\Czech' not allowed with multiple sour
ce files

Now Czech DLL is really the first to be compiled - basically everything else depends on it. So it seems have setup the project-to-project references correctly. Also the include directories and some of the defines are from one of the indirectly inherited property sheets, so it again seems these work alright.

Is this something that could result from the involved conversion procedure I described above? Any pointers as to where should I look to solve this D8036 problem?

Also while I am no DOS expert, it seems to me that some values might be overescaped with backslashes. (i.e. -I"\"Z:\..\boost\""). But is how it worked with 2008. Nevertheless premature worry when I can't even get the compiler command line options right :-)

Thanks,
Boris

Answer 1

I discovered one mistake - I have this in Punctus.vsprops.settings:

  <PropertyGroup>                                                                                               
    <OutDir>$(BuildPrefix)$(ConfigurationName)</OutDir>                                                         
    <IntDir>$(BuildPrefix).objs\$(ConfigurationName)\$(ProjectName)</IntDir>                                    
    <RootDir>$(SolutionDir)</RootDir>                                                                           
    <BuildPrefix>$(RootDir)bin\$(PlatformName)\</BuildPrefix>                                                   
  </PropertyGroup>                                                                                              
  <ItemGroup>                                                                                                   
    <BuildMacro Include="RootDir" />                                                                            
    <BuildMacro Include="BuildPrefix" />                                                                        
  </ItemGroup>                                                                                                  

Yet it seems from directory inspection that the compiler creates Czech\.objs\Czech directory (the first "Czech" is directory of the project of same name).

So I tried if the order in which properties are declared is significant and discovered that it is - changing it to:

  <PropertyGroup>
    <RootDir>$(SolutionDir)</RootDir>                                                                           
    <BuildPrefix>$(RootDir)bin\$(PlatformName)\</BuildPrefix>                                                   
    <OutDir>$(BuildPrefix)$(ConfigurationName)</OutDir>                                                         
    <IntDir>$(BuildPrefix).objs\$(ConfigurationName)\$(ProjectName)</IntDir>                                    
  </PropertyGroup>                                                                                              

When compiling again, I got an improvement:

  cl : Command line error D8036: '/FoZ:\platform-test\Punctus\bin\Win32\.objs\\
Czech' not allowed with multiple source files

So you see that now the paths are nearly correct (when you compare with cl message in previous post), just the $(ConfigurationName) does not expand to Debug or Release.

Maybe the bad order of items is because of the hack I used to convert the property sheets?

Answer 2

Seems like ConfigurationName got renamed to Configuration - this fixes the path. (The D8036 still remains, of course)

Answer 3

Hi Boris,

Thanks for your investigation. There are a few bugs in our conversion based on the snippets you pasted in your post:
    - $(ConfigurationName) should automatically be converted to $(Configuration) throughout all the property sheets (looks like we only do this for the project file). Same for $(PlatformName) that should be converted to $(Platform)
    - $(IntDir) and $(OutDir) must have a \ appended to them during conversion.

We'll fix these bugs. 

As a workaround, add a \ at the end of the definition of $(IntDir) and $(OutDir). Let us know if this fixes the build.

Thanks,
Marian Luparu
Visual C++

Answer 4

Hello Marian,

thanks for your response. Adding \ at the end of OutDir and IntDir made the D8036 problem vanish. But other problems arose (and for 3 of them, I found a solution):

• I had the include directories in original project set to AdditionalIncludeDirectories="&quot;$(BoostIncludeDir)&quot;;&quot;$(IconvIncludeDir)&quot;" After the conversion, they were listed in the converted format as <AdditionalIncludeDirectories>"$(BoostIncludeDir)";"$(IconvIncludeDir)";%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>. The quoting did prevent the include paths from being found, removing the quotes around BoostIncludeDir and IconvIncludeDir in the converted format fixed the problem
• AdditionalDependencies="&quot;$(IconvLibDebug)&quot;" in original format did not get into converted format at all. I however did try converting again with the original format project with quotes removed (i.e. AdditionalDependencies="$(IconvLibDebug)") and the link appeared in the converted format as <AdditionalDependencies>$(IconvLibDebug);%(AdditionalDependencies)</AdditionalDependencies>
  
• I had to move the 2 imports of property sheets (one for Debug, one for Release) before the property group where PostBuildEventCommand gets defined. The conversion tool left it right after that group (and after import of Microsoft.CPP.settings, to be precise). The original setting caused OutDir and IconvDLLDebug macros being empty in post-build event (during which I copy the DLLs to output directory).
  
• This last one I did not solve and is where I am stuck now. I get the Czech project to compile perfectly. Then Logic project starts compiling. Obviously there is something strange - Logic depends on Dict, which has not yet been compiled (only Czech). So it should not be built. Nevertheless, I get error MSB3107 on compiling Logic:

Target "SplitProjectReferencesByType" in file "C:\Windows\Microsoft.NET\Framewo
rk\v4.0.11001\Microsoft.Common.Targets" from project "Z:\platform-test\Punctus\
Logic\Logic.vcxproj":
Using "AssignProjectConfiguration" task from assembly "Microsoft.Build.Tasks.v3
.5, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "AssignProjectConfiguration"
C:\Windows\Microsoft.NET\Framework\v4.0.11001\Microsoft.Common.Targets(1046,9):
 error MSB3107: The specified project reference metadata for the reference "..\
Dict\Dict.vcxproj" is missing or has an invalid value: Project
Done executing task "AssignProjectConfiguration" -- FAILED.
Done building target "SplitProjectReferencesByType" in project "Logic.vcxproj"
-- FAILED.
Done Building Project "Z:\platform-test\Punctus\Logic\Logic.vcxproj" (default t
argets) -- FAILED.

Same error happens for TextSource project and its reference to the Czech project. Maybe the interproject references are broken and Czech gets compiled simply because it's first alphabetically?

I have this after import of Microsoft.CPP.targets in the Logic project:
  <ItemGroup>
      <ProjectReference Include="..\Dict\Dict.vcxproj"/>
  </ItemGroup>
The path is relative to the project compiled (i.e. Logic). I have the classic setup - directory for solution and projects in subdirs of the same name as the project.

• The naming of some output files is inconsistent with VC9. I have a rule in one property sheet for DLLs that sets DLL names to $(SolutionName)$(ProjectName).dll. And several VC9 default values (i.e. those used by VC9 in a brand new project) reference these with TargetName, like .exp and .lib and .pdb file, however these did not somehow work in the converted project - this is how output directory looks like: Czech.exp Czech.lib Czech.pdb PunctusCzech.dll PunctusCzech.dll.embed.manifest PunctusCzech.ilk libiconv2.dll. Seems like .ilk and .embed.manifest got their names right though.
  
  

Thanks again,
Boris

Answer 5

Hi Boris, for your last problem, instead of doing "MSBuild Punctus.sln", if you do "MSBuild Logic.vcxproj", will Dict.vcxproj get build? It looks like ..\Dict\Dict.vcxproj are relative to the Logic.vcxproj file instead of relative to the solution file.

Li Shao, Visual C++

---

Li Shao

Answer 6

Greetings Boris,

Thank you for your feed backs.  I am looking into ways to unblock you with the project to project.  From looking log output, the project reference itemgroup contains a bad, not empty, "Project" metadata.  Check if the Project metadata is a valid GUID.

To show the value at run time, set CustomBuild command to echo %(ProjectReference.Project) and the BeforeTarget to SplitProjectReferencesByType.  Rebuild and look for CustomBuild command.

Thanks.

Felix Huang

Answer 7

Hello Li,

thanks for your response. I tried building from solution dir with "msbuild Logic\Logic.vcxproj" and from project dir with "msbuild Logic.vcxproj". They behave the same, unfortunately wrong. It seems from msbuild output that it correctly notices the dependencies, as it says that (reduced output) "Logic builds Dict" and then "Dict builds Czech", even though Czech is already built in the output directory of $(SolutionDir)\bin\Win32\Debug (and object files in a similar prefix). Running with detailed verbosity, I concluded that all these problems are because I am building project directly without a solution, so $(SolutionName) and $(SolutionDir) that are referenced in property sheets (for include, output and intermediate directories) are undefined (empty).

I tried changing the reference to be relative to solution directory (i.e. remove the "..\"), but I ran again into the MSB3107 issues - more in my response to Felix.

Thanks,

Boris

Answer 8

Hello Felix,

thanks for your response. I did enable the GUID logging with "Message>Echoing project GUID (%(ProjectReference.Project)).</Message><Command>echo %(ProjectReference.Project)</Command>". Apparently the echoed value is empty (unlike you supposed) - output is "Description: Echoing project GUID ()." for the Message and "ECHO is on." for the Command (which suggests again empty value).

Thanks,

Boris

Answer 9

Hi Boris, have you tried to define $(SolutionName) and $(SolutionDir) in your project file and build? Solution is something we did not handle well in CTP2. If you still have problem, could you send us the MSBuild log with /v:diag enabled? If you also have the VCBuild log building the same solution, that would be very helpful. Also, will you be able to send us the .vcxproj files and properties sheets?

Li Shao
Visual C++ 

---

Li Shao

Answer 10

Hello Li and Felix,

I am sorry I could not continue debugging the issue back in December, but it started to consume more time I could then afford. I am looking forward to trying again with the upcoming Beta.

Thanks for all your help,

Boris