I took a stab at this over the weekend (IniFileSearch, not reading another
bundles variables) and I have a functional branch at
https://wix.codeplex.com/SourceControl/network/forks/jchoover/Wix?branch=IniFileSearch.
I’d like to know if the ability to read arbitrary in files from a bundle would
be considered for 3.8. I would need to flesh out the IniFileSearch a bit more
in the compiler, to allow it to be a child of a few more of the search elements.
My intent behind this change is for administrators to download a bundle, create
a deployment point via a layout, and then optionally being able to preconfigure
the install via the ini file. This would simplify SCCM deployments and reduce
concerns of exceeding the max buffer for command line parameters. The bundle
must be authored to read from the ini, so this change wouldn’t impact any
existing bundles.
I believe the way I set this up, you could easily configure the bundle to read
from predefined locations or from an ini file passed on the command line (via
another variable). I also coded it in such a way that if the path isn’t
absolute, it will make the path absolute based on the location of the bundle.
If the variables from the ini need to be persisted for repair or removal, a
user would use the existing Variable/@Persisted.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Monday, April 01, 2013 2:23 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Reading bundle defaults from an INI file
No, a bundle cannot access other bundle variables. There is a feature request
to enable this but it is something that needs to be thought through carefully
to ensure the communication is backwards *and* forwards compatible. Makes it a
much harder feature to implement. <smile/>
On Fri, Jan 25, 2013 at 12:40 PM, Hoover, Jacob
<jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>> wrote:
I would be using the standard format created by
GetPrivateProfileString/WritePrivateProfileString.
As such, the ini for my snippet could look like:
[Options]
NetworkShare=\\foo\bar
AutomaticUpdates=1
This would be similar to the concept of “answer files” for unattended installs.
Today, does a variable stored in a previous bundle automatically get read from
an updated bundle when doing an upgrade?
From: Rob Mensching [mailto:r...@robmensching.com<mailto:r...@robmensching.com>]
Sent: Friday, January 25, 2013 2:22 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Reading bundle defaults from an INI file
Can you show an example of the Ini format you're thinking about?
On Fri, Jan 25, 2013 at 11:06 AM, Hoover, Jacob
<jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>> wrote:
I was thinking an INI because it was easy. Also, I seem to remember there
being security issues with reading an app.config file off of a network share.
GetPrivateProfileString works fine with network/UNC paths. I was also a bit
biased because I want to live in the Win32/WixStdBA world.
My primary reason behind these logical defaults in to have the administrator do
a /layout and move the bundle and payload to a network share, provide the
intended defaults, and then use SCCM or similar tools to deploy it. In the
case of more lax networks, the end users could install it themselves and have
the proper defaults. (Yes, if it were via SCCM the admin could provide it all
with command line parameters.)
Jacob
From: Katherine Moss
[mailto:katherine.m...@gordon.edu<mailto:katherine.m...@gordon.edu>]
Sent: Friday, January 25, 2013 12:06 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Reading bundle defaults from an INI file
Why not instead of a .ini file, why not use a .config file? INI is so
worthless and out-of-date in this Day and age. Just my input.
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, January 25, 2013 12:03 PM
To: Windows Installer XML toolset developer mailing list
Subject: [WiX-devs] Reading bundle defaults from an INI file
.
I tried searching for this feature request and couldn’t find it. I’m pondering
the usefulness of a bundle defaults option, where the bundle could use an INI
file to load the default values for variables. I know you can pass command line
parameters to a bundle to set them, but I was thinking an INI file might be
useful in the cases where an admin configures the install preferences once from
a network share, and the bundle could then be ran by multiple users and inherit
those values.
The way I would see this working is similar to how all the other existing
Searches work. This means a change to the Util extension to allow for a
ReadINI option (only in scope for burn) and a modification to the engine to
assign variables the values of the ini if the file exists. If the file doesn’t
exist, simply ignore any processing. In the bundle, I would expect to see
something like…
<Variable Name=”NetworkShare” Persisted=”yes” Type=”string” />
<Variable Name=”AutomaticUpdates” Persisted=”yes” Type=”numeric” Value=”#1” />
<util:ReadINI Name=”Setup.ini” Section=”Options” Name=”NetworkShare”
Variable=”NetworkShare” />
<util:ReadINI Name=”Setup.ini” Section=”Options” Name=”AutomaticUpdates”
Variable=”EnableUpdates” />
And then these values could be mirrored on the Options page of
the bundle with:
<Page Name="Options">
<Text X="11" Y="80" Width="-11" Height="30" FontId="2"
DisablePrefix="yes">#(loc.OptionsHeader)</Text>
<Text X="11" Y="121" Width="-11" Height="17" FontId="3"
DisablePrefix="yes">#(loc.OptionsLocationLabel)</Text>
<Editbox Name="NetworkShare " X="11" Y="143" Width="-91" Height="21"
TabStop="yes" FontId="3" FileSystemAutoComplete="yes" />
<Checkbox Name="AutomaticUpdates " X="11" Y="165" Width="-91"
Height="17" TabStop="yes" FontId="3"
HideWhenDisabled="yes">#(loc.AutomaticUpdatesCheckbox)</Checkbox>
<Button Name="BrowseButton" X="-11" Y="142" Width="75" Height="23"
TabStop="yes" FontId="3">#(loc.OptionsBrowseButton)</Button>
<Button Name="OptionsOkButton" X="-91" Y="-11" Width="75" Height="23"
TabStop="yes" FontId="0">#(loc.OptionsOkButton)</Button>
<Button Name="OptionsCancelButton" X="-11" Y="-11" Width="75"
Height="23" TabStop="yes" FontId="0">#(loc.OptionsCancelButton)</Button>
</Page>
In order to support this I would again have to enhance
WixStdBA, so I am wondering how useful this would be outside of my realm before
I put in the effort of the modifications.
Thanks,
Jacob
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5,
CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5,
CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
