Hey all,
More details...
The problem seems to be restricted to <RegistryKey ..> elements with a child
<util:PermisionEx ..>.
Here's some pre 3.6 code that was fine:
<Component Id="RegistryValues" Guid="{.. hah ...}">
<RegistryKey Action="create" Root="HKLM" Key="SOFTWARE\blah\blah">
<util:PermissionEx User="Administrators" GenericAll="yes" />
<util:PermissionEx User="[My_USERID]" Domain="[My_DOMAIN]"
GenericAll="yes" />
<util:PermissionEx User="NetworkService" GenericAll="yes" />
</RegistryKey>
</Component>
This generates the following warning:
The RegistryKey/@Action attribute has been deprecated. In most cases, you
can simply omit @Action. If you need to force Windows Installer to create
an empty key or recursively delete the key, use the ForceCreateOnInstall or
ForceDeleteOnUninstall attributes instead.
Believing the "In most cases, you can simply omit @Action." I removed
action:
<Component Id="RegistryValues" Guid="{.. hah ...}">
<RegistryKey Root="HKLM" Key="SOFTWARE\blah\blah">
<util:PermissionEx User="Administrators" GenericAll="yes" />
<util:PermissionEx User="[MyUSERID]" Domain="[MyDOMAIN]"
GenericAll="yes" />
<util:PermissionEx User="NetworkService" GenericAll="yes" />
</RegistryKey>
</Component>
And bang... I get the error "Cannot set column 'SecureObject' with a null
value because this is a required field".
Adding ForceCreateOnInstall="yes" resolves the problem.
It would be nice if exceptions that occur during parsing/compiling/linking
were trapped and reported better. It took a lot of effort to track down that
the problem was caused by a simple change to remove a warning (a change that
was explicitly recommend by the warning message itself).
Regards,
Rob
-----Original Message-----
From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com]
Sent: October-15-12 10:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Runing the candle command from a command line window yields additional
exception output. As a side note, any ideas why wouldn't the exception
details be captured as part of the build output when invoked from VS2010
(sure would have saved me a ton of time)?
Here's the output:
Exception Type: System.InvalidOperationException
Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object
value)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio
nExElement(XmlNode node, String objectId, String componentId, Boolean win64,
Str ing tableName)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String& keyPath, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou
rceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElement element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo
de node, String componentId, Int32 root, String parentKey, Boolean
win64Componen t, String& possibleKeyPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode
node, ComplexReferenceParentType parentType, String parentId, String
parentLang uage, Int32 diskId, String directoryId, String srcPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN
ode node)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument
source)
at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args)
So... it looks like perhaps the problem is in ParsePemissionExElement.
Assuming this is complaining about <util:PermissionsEx ...> element I'm left
little better off. I use this in quite a few places and they all follow the
same pattern:
<util:PermissionEx User="Guests" GenericRead="yes" Read="yes"
GenericExecute="yes" />
<util:PermissionEx User="Users" GenericRead="yes" Read="yes"
GenericExecute="yes" />
<util:PermissionEx User="Everyone" GenericRead="yes" Read="yes"
GenericExecute="yes" />
<util:PermissionEx User="Administrators" GenericAll="yes" />
<util:PermissionEx User="CREATOR OWNER" GenericAll="yes" />
Commenting out every <util:PermissionEx ..> element allows the build to
succeed.
Adding back a single <util:PermissionEx User="Administrators"
GenericAll="yes" /> causes the build to fail with the " Cannot set column
'SecureObject' with a null value because this is a required field" error.
I have a reference to util (C:\Program Files (x86)\WiX Toolset
v3.6\bin\\WixUtilExtension.dll) and I have included the namespace:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
>
Has <util:PermissionEx ..> been dropped from 3.6?
Any suggestions?
Regards,
Rob
-----Original Message-----
From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com]
Sent: October-15-12 9:53 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Hey all,
Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few
warnings and now it compiles clean... _except_ for the following error:
candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a
null value because this is a required field.
The error output leaves a lot to be desired:
1. What source file is causing this?
2. What table does the column belong too?
The full candle command is (some names changed to protect the innocent):
candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\
-dPlatform=x86 -d"ProjectDir=C:\..snip..\MyProject\\" -dProjectExt=.wixproj
-dProjectFileName=MyProject.wixproj -dProjectName=MyProject
-d"ProjectPath=C:\ ..snip..\MyProject.wixproj" -d"TargetDir=C:\
.....snip..\MyProject\bin\Release\\" -dTargetExt=.msi
-dTargetFileName=MyProject.msi -dTargetName=MyProject -d"TargetPath=C:\
.....snip..\MyProject\bin\Release\MyProject.msi" -out obj\Release\ -arch x86
-ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixNetFxExtension.dll"
-ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll"
-ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUIExtension.dll" -ext
"C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixIIsExtension.dll"
Application.wxs CustomDialogs.wxs ErrorText.wxs Files.wxs
MicrosoftAssemblies.wxs MyAssemblies.wxs MyCustomActionDefinitions.wxs
MyEventLog.wxs MyRegistry.wxs
I've been through every <Property ..> element and removed Secure="yes" but
this has not helped.
I've reviewed this bug: http://sourceforge.net/p/wix/bugs/2941/ and its
original posting
(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-projects-
fail-to-build-after-upgrading-to-v3-6-2914-0-td7559640.html) but my project
is not suppressing .wixpdb output (even tried turning it on and then off).
Does anyone have any suggestions on what I can do to move past this problem?
Any suggestions on how to gather more output from candle to get a clue as to
the origin of the problem?
Thanks!
Rob
----------------------------------------------------------------------------
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly what is
happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at
no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
----------------------------------------------------------------------------
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly what is
happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at
no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
