One package in our installer bundle downloads data from our server and then uncompresses it. The size of this data is 15gb.
I want to put this value into the Add/Remove programs size column.
The InstallSize attribute would appear to do what I want however, when I set it "15050494389" I get the following error:
The MsiPackage/#InstallSize attribute's value, '15050494389', is not a legal integer value. Legal integer values are from -2,147,483,648 to 2,147,483,647.
Ignoring why I would want a negative value, is there a way of setting the value correctly? Is there some setting I need to tell burn that I want values bigger then 32bit?
That's not supported today in WiX v3.8. You can file a feature request.
I thought this property would be set automatically? Either way, it looks like you need kilobytes, not bytes for this field. Try 15728640.
Are you referring to ARPSIZE or something else btw?
Add or Remove Programs Entries
Configuring Add/Remove Programs with Windows Installer
Related
I have a json payload where one value for a key is 99999999999.99. When I pass this value, the camel is converting this into 9.999999999999E10. The camel version I'm using is 2.22.1.
I've upgraded the camel version to 2.23.2 but didn't work. I can upgrade to another version if needed.
I expect the value to be 99999999999.99. I need no conversion happening in the framework.
As #james-k-polk already commented, this is not a conversion but a different way to show the same number in Java.
The extension E10 means that the decimal point has to be shifted by 10 (e is for exponent, see also on Wikipedia).
So that means: 9.999999999999E10 is equal to 99999999999.99. It is just another way to display the same value.
If this different display form is causing a specific problem, create a new question for it.
There were few attempts of questions answerered in regards to ICE03 (String overflow) for CustomActionData, but I cannot seem to determine/conclude the correct (or accepted) practice of how to go around this issue.
My current resolution was to reduce the length of the key-value-pair by keeping both the key and property names short, i.e. from:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="myKeyName1=[SOME_PROPERTY_NAME];myKeyName2=[SOME_DESCRIPTIVE_PROPNAME]"/>
to:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="k1=[K1];k2=[K2]"/>
But I feel that I'm just sweeping the problem under the rug and sooner or later, I'll encounter again (also, this is based on assumptions of my additional question below).
The more obvious solution is the re-evaluate and re-design it so that least amount of data needs to be passed down to the C# CustomAction (the classic "why would you want to declare a function method to pass 20 parameters?" question by all code-reviewers). Obviously, for most languages today, we can easily redesign the API and pass an object (as a class, struct, etc - depends on languages) that self-contains what it needs, but how does one go about it for inter-process calls (I've seen JSON RPC messages with reasonably large data and I'd usually wonder if it was because somebody tried to fix some legacy code by adding more and more until it got bloated rather than sitting down and re-design, which is not possible on some "11th hour" deadline that just has to get fixed in shortest time allowed).
Perhaps the solution is to create an XML file and use expat ('util:XmlFile') to search and replace the key-value-pair before calling CustomAction, and pass the filename of the altered XML as CustomActionData for CustomAction to use, which then in C# CustomAction code, it just deserializes it and treats it as objects. But that too feels a little klunky (it may also confuse the next developer who takes over my task in the future), not to mention if it was passwords we'd want to not have it in an XML file and keep it as Property with Hidden="yes"...
So my question is, what are the clean/elegant solutions or pattern (or practices) to resolve this issue of passing CustomActionData that may exceed table column size?
If I may also ask an additional question which is somewhat related, I am assuming that the linker (light) warning LGHT1076 is based on the length of the value (i.e. "keyA=[A];keyB=[B]") being too long, and so if I chose very short property variable and key-names, it would most likely not trigger this warning. But from what I understand, the table column size is 255 characters (please correct me if I'm wrong) thus during the run-time, if property value is longer than column size, it can cause some issue (or truncated)?
The solution I use is to create multiple properties and then concatenate the properties at the end into a single property, this way:
<CustomAction Id="SetSqlProperties"
Property="SqlProperties"
Value="SQL_LOGIN_ID=[SQL_LOGIN_ID];SQL_PASSWORD=[SQL_PASSWORD];
SQL_AUTH_TYPE=[SQL_AUTH_TYPE];SQL_SERVERS=[SQL_SERVERS]" />
<CustomAction Id="SetServerProperties"
Property="ServerProperties"
Value="Domain=[DOMAIN];ComputerName=[COMPUTER_NAME];
FullServerName=[FULLCOMPUTERNAME];Version=[ProductVersion];
ServerType=[SERVER_TYPE];SrvMode=[SrvMode]" />
<CustomAction Id="SetPropertiesConfigReplace"
Property="ConfigReplace"
Value="InstallFolder=[INSTALLFOLDER];[ServerProperties];[SqlProperties]" />
In this example I would use the property [ConfigReplace] containing all values from SQL Server and local server.
About the ICE03, in the documentation you can find this:
The string's length is greater than the column width specified by the column definition. Note that the installer does not internally limit the column width to the specified value. See Column Definition Format.
MSDN
As mentioned in the element's documentation, the default value for the ID attribute is the file name portion from the Source attribute.
The problem occurs when we add multiple files with the same name (but different locations), thus the ID attributes that should be unique become a duplication.
Is there an easy way to give the attribute a random identifier (something like the asterisk in the GUID of the Product element)?
I want not to set the identifiers manually since the files with the same name increase and spread in many .wxs files all over the project.
How about the option of making a WiX extension for that? Something like a function call to get random values.
Thank you!
In WiX Toolset v3.7, the Ids get automatically generated. This will work most of the time (still an issue when 2 filenames are similar e.g. when the only difference is a blank in one file and an '_' at the same position within the filename in the other)
I can use "!(bind.property.ProductVersion)" to set for example the UpgradeVersion\#Minimum attribute. Works fine.
But now I want to set that attribute to something like:
"!(bind.property.ProductVersion.Major).!(bind.property.ProductVersion.Minor).0.0"
But that does not work.
I get this error: The UpgradeVersion/#Maximum attribute's value, '!(bind.property.ProductVersion.Major).!(bind.property.ProductVersion.Minor).0.0', is not a valid version. Legal version values should look like 'x.x.x.x' where x is an integer from 0 to 65534.
Any ideas how I can get this to work?
Regards, Jaap
Unfortunately, it appears the version attribute is only allowed to have a single binder variable to replace the whole string. It doesn't support the scenario you describe. However, it seems like it should. You could file a bug at http://wixtoolset.org/bugs
How can we search a (Default) registry entry with value (value not set) from WIX?I tried by using RegistrySearch without Name attribute still its not working.Anyhelp would be appreciated.
(value not set) is not a real value. It's just what you see in regedit when the (Default) value for the key is actually not set.
If you do a RegistrySearch search for a value that is not set, or a registry key that does not exists, then in both cases the windows installer property will not be set. You cannot make the distinction between both.
So how do you verify that a registry key is present or not? The simplest way is to search for another value that is always set when the key is present, instead of searching for (Default). Typically there is one. If not, you'll have to write your own custom action as detailed in this answer.