Questions: Reboots & Setup.exe "mouse over" file attributes

Nov 3, 2009 at 7:45 PM
Edited Nov 4, 2009 at 3:39 AM

Hello All-

First, I want to say an official Thank You for the excellent tool.  I was thrust into the world of installers rather abruptly with a challenging installer that needs to include .NET 2.0, VC++ redistributables, and a custom .NET app already wrapped in its own MSI using WiX.  dNI quickly allowed me to bridge from the set of individual installers to a single Setup.exe.

I have a few questions thus far with its use:

  1. Rebooting
    I wish to prompt for reboot upon finishing the installation via dNI but I do not wish for the dNI installer to auto-restart after reboot.  I've set auto_continue_on_reboot to FALSE, auto_start to FALSE, the 2 non-MSI components both have "must_reboot_required" and "mustreboot" set to FALSE.  Finally, the 1 MSI component has both "must_reboot_required" and "mustreboot" set to FALSE as well.  The MSI WiX config (and resulting MSI) is configured to return a code to indicate a reboot is required to dNI, and this works.  The user is correctly prompted for reboot, however, after reboot, the dNI installer auto-starts again.  This is mostly an annoyance to the customer and we'd like to prevent it.  (Its a little more complicated because it isn't easy to add an Installed Check for the MSI wrapped into the bootstrapper as its GUID is generated on-the-fly by the WiX config.)
  2. What is the best way to unobtrusively recognize the dNI project in the installer?
    Currently, mousing over the Setup.exe shows the company name "DevAge, Vestris Inc. & Contributors".  While I want to recognize the dNI team for this time-saving piece of software, customers are confused about this "other company".  I attempted to add a "Company" element to the dNI config file.  Although it added a 2nd "Company" attribute to the resulting Setup.exe, it did not override the "Company" displayed while mousing over the Setup.exe.  Suggestions?
  3. check_product
    I found that adding an installed check using method "check_product" always results in the error "Error in ::IIDFromString: The parameter is incorrect.".  After some monkeying, I discovered that the InstallerEditor records the id attribute without braces but that they are required.  Manually editing the XML file to add "{" & "}" around the id attribute for the installedcheck allowed the installer to continue.


T. Moody

Nov 4, 2009 at 1:09 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Nov 4, 2009 at 1:16 PM

Thanks for your kind words. Please don't forget to reply to this thread when you have production software shipping with dotNetInstaller.

  1. This is an obvious feature omission, copied as I'll think about how to implement this, maybe all it takes is to rerun installed checks before reboot to find out whether dotNetInstaller needs to start after the reboot or not.
  2. The correct attribute name is CompanyName. The other ones that matter are ProductName, LegalCopyright and FileDescription. Open any executable with Visual Studio and examine its version resource to find out other attributes.
  3. I filed to look at what's going on in the source. Are you seeing InstallerEditor strip the { } even when you write them?
Nov 4, 2009 at 2:50 PM
Edited Nov 4, 2009 at 3:14 PM

I will provide further elaboration on (1) and (3) in the Issue Tracking sections.

Thanks for the quick response & info on CompanyName.  I see now these are likely derived from VERSIONINFO, and have discovered your ResourceLib project.  Busy guy, you are.  It appears file version info is a complicated subject, but is there a way through dotNetInstaller to specify the file version as well?  I've tried setting attributes "FileVersion" and "ProductVersion" with x.x.x.x format strings.

I'm actually building an "installer builder" that creates another MSI before invoking the InstallerLinker.  Worst case, I believe I could use your ResourceLib after creation of the Setup.exe and modify the version # outside of dNI.

Also to be absolutely clear for historical purposes, I am using dotNetInstaller 1.7.29433.0


T. Moody

Nov 5, 2009 at 3:07 AM
Edited Nov 5, 2009 at 3:08 AM

I think this deserves a documentation page, so I wrote one. Here's the text that will go into the next release. Let me know if this answers your question. If you download the latest 1.8 build, the documentation has some pretty pictures too.

dotNetInstaller supports rewriting file attributes such as binary versions, company name and copyright. These attributes can be seen by hovering over a setup binary or by right-clicking on it and choosing the Details tab under Properties.

Configuration attributes are editable under the File Attributes section of the Config File in Installer Editor. 

Operating System Attributes
The configurable operating system attributes include the following language and code page independent fields.

 File's binary version number.
 Binary version number of the product with which this file was distributed.

String Attributes
The following attributes are reserved by the Windows shell. Their names are translated and presented in the language of the operating system.

 Product name.
 File description.
 Name of the manufacturer.
 Copyright notice.

You can also define additional attributes with the name of your choosing. These have no special meaning for the operating system and don't appear along the reserved attributes in the properties screens. They are embedded with the executable and may be used by proprietary software.

Nov 6, 2009 at 2:15 AM

Thanks, dblock.  That Help will help quite a lot.

Prior to your response, I did try ProductVersion and FileVersion via dNI but did not have success.

I did decide to try using your ResourceLib directly.  While I was able to add version information to a small .exe that did not have any before, I was not able to modify the file or product version information even using the sample code in the help files on a file that previously already had version information.  I believe there was another recent post (in October?) reporting something similar in 1.7 but I have not yet followed up with that poster.  I believe there are some unit tests for this.  You (?) stated that this definitely worked in 1.6.  I may try 1.6 for comparison.

I am in the process of assembling your build environment so I can dive deeper in to this though my time is quite limited for the next week.


T. Moody

Nov 6, 2009 at 12:38 PM

Can you please post your configuration file (you can strip it from components if you want) and the command line you use for InstallerLinker? Thx.