Heh, yeah, that sounds like the bug. Can you make sure a bug gets opened on
the issue? I'm not the Votive expert so I'm not sure there is a work around
but something needs to be fixed. In the very least, the error message is
horrible.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Holder
Sent: Thursday, May 15, 2008 08:27
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Where do WiX Variables Come From?
Am having a bit of an issue with WiX variables this a.m. which I'm hoping
someone can clue me in on. In a large Visual Studio solution, there are these
two projects called "Common.csproj", each referring to logic in different
namespaces, each in different physical folders. When setting the File tag's
Source attribute to a WiX variable, we run into a problem. The syntax for the
variable for both projects is as follows:
$(var.Common.TargetDir)
In order to solve this problem, we looked at the .wixproj file's schema,
wherein we have a series of ProjectReference tags. Beneath the
ProjectReference node, there's a Name tag - presumed to contain the string
referred to by the WiX toolset to identify the project name within the WiX
variable syntax. Consequently, we changed our .wixproj as follows (note the
<Name> tag content):
58 <ProjectReference
Include="..\..\..\src\Application\MultiChannelSDK\Service\Common\Common.csproj">
59 <Name>ServiceCommon</Name>
60 <Project>{7b6ebb1f-3b75-4497-85fb-e524fc9486fc}</Project>
61 <Private>True</Private>
62 </ProjectReference>
63 <ProjectReference
Include="..\..\..\src\Application\MultiChannelSDK\Shared\Common\Common.csproj">
64 <Name>SharedCommon</Name>
65 <Project>{13736794-cc44-4834-86a6-9733ba4c2089}</Project>
66 <Private>True</Private>
67 </ProjectReference>
Ordinarily, the <Name> tags would have contained strings like "Common
(Shared\Common)" and "Common (Service\Common)"; and these strings would have
appeared within the References node of the WiX project. Instead "SharedCommon"
and "ServiceCommon" now appear in the References folder, as they do in the
listing above.
However, when building the WiX project from within Visual Studio, we're still
seeing the same original error we had when we'd first started building using
diplicate $(var.Common.TargetDir) strings in our .wxs file:
candle.exe(0,0): error CNDL0001: Item has already been added. Key in
dictionary: 'Common.Configuration' Key being added: 'Common.Configuration'
Done building project "Sonora.wixproj" -- FAILED.
The -d arugments used when candle.exe is run by the build still use the
"Common" string, suggesting that WiX is actually not looking at the .wixproj
file's ProjectReference\Name nodes for the strings used as WiX variable names -
it's simply using the project file name, looks like.
Can anyone verify this? Further - can anyone suggest an alternative approach
for handling duplicate project names (if indeed any approaches exist, other
than telling all your devs to use unique project names in each solution)?
Gratefully,
ross.holder |
Office 613.727.9898 ext 2018 | Mobile 613.293.7673 | Fax 819.420.0121
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
Application Developer - Product Development
P Before printing this, think about the environment|Avant d'imprimer ceci,
pensez à l'environnement
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
