IIRC WiX 2.0 didn¹t do ICE validation so you probably had the warning just
didn¹t know you did.
Neil
Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
Seemed to be working through the compiler and linker errors one by one
just
fine until I hit ICE38 regarding shortcuts.
From: http://msdn.microsoft.com/library/aa371168.aspx the meaning of the
integer in the Root column:
The one missing enumeration represents either Machine and User, so
HKey-(localMachine|currentUser) or HKMU.
Someone else expressed it this way: HKMU stands for either HKLM or HKCU
depeding
Several of our packages use unadvertised shortcuts to point to various files in
their installation. However, I have learned that we were setting the
WorkingDirectory attribute wrong for them (because I had to replace one for
an application where WorkingDirectory matters). I had followed the
1. Validation isn't possible because the WorkingDirectory attribute is a
reference to a Property identifier (during CostFinalize all Directory Id's
become accessible as Properties). Thus, you could have a custom action that
sets INSTALLDIR that the WiX toolset cannot see and would be a false
WorkingDirectory is just a name that is closer to the name in the MSI
file's shortcut table - WkDir. It helps people see what's going on when the
names are similar, that's my assumption why they are similar.
INSTALLDIR is just a convention, TARGETDIR is the Windows Installer
directory which is
You could experiment with MSIFASTINSTALL to see if there is a difference.
The file costing only option might tell you if there's some other
expensive costing going on.
Phil Wilson
On Wed, Dec 4, 2013 at 6:17 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote:
Hmm,
3000 files shouldn't be
Also large, complex programs place binaries in various different directories,
so there can be no single convention as to the “install location” nor even a
single “working directory” for those systems. As such, you are expected to
establish your own conventions and stick to them as they apply to
We have changed the shortcuts and suppressed the ICE57. This went well. Now
ICE64 is popping up for the shortcuts in question.
It appears that the Component containing the Shortcut needs to also contain a
RemoveFolder.
RemoveFolder Id=ProgramMenuCSSIDir On=uninstall/
The RemoveFolder doc
Hi Phil,
Thanks for the reply. I'm not sure what you mean by Are you sure you
haven't overlapped the Progid element with the registry
stuff? - can you please elaborate?
- Brian
Brian Gillespie
Rhinoceros Development
Robert McNeel Associates
On Wed, Dec 4, 2013 at 9:06 AM, Phil Wilson
Generally, I recommend pretending that TARGETDIR doesn't even exist.
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Thursday, December 5, 2013 8:01 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Question about shortcuts
I have created a path (msp file) as difference beetwen small update 1.0.0.0 to
1.0.0.1. One dll is changes. this dll is .Net assembly (COM Object). So I need
to reregister it ( generate new tbl file) after the patch is applied. Does the
path supported to perform some custom actions such as
I was thinking of the advertised case, but I see now that you're not using
it in that ProgId component definition. If you have an advertised=yes
ProgId, WiX populates the MSI's Extension and ProgId tables and there's
nothing else needed - no need for registry entries. I was thinking there
could be
If you registered that type library with a CA in the original install that
may not have been the best option, TLB entries are basically just a bunch
of HKLM\Interface entries that can be put in the registry (Heat may even
extract them) so there is no need to run any code at all. So it matters how
Yes, I register library by executing regasm.exe library /silent /codebase /tl
in CA during original install
CustomAction Id=CmdInstallComId Property=InstallComId
Value=quot;[NETFRAMEWORK20INSTALLROOTDIR]regasm.exequot;
quot;[APPLICATIONROOTDIRECTORY]BARSToolbar.Service.dllquot; /silent
Don't patch it, Major Upgrade it and kill that CA. You can use heat to harvest
the COM info from the DLL and then easily support patches without having to
fight Windows Installer because the previous developer did it in a non-standard
way.
If your issue is with VBA, you may also need to
Hi all,
Quick question… I haven’t set this up yet but would like to know if it is
feasible first before doing the work…
My application’s MSI has 3 features”
1. Client app 1
2. Client app 2
3. Client app 3
There is a feature tree page so you can select which feature you want to
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder'
Directory Id='INSTALLDIR' Name='CSSI'
With the above directory structure the WixUI_FeatureTree is showing a
Location of C:\ on the feature selection dialog shown just after accepting
the
2013/12/5 Dave Williamson, Clear Sky Software d...@clearskysoftware.com:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder'
Directory Id='INSTALLDIR' Name='CSSI'
With the above directory structure the WixUI_FeatureTree is showing a
Location
Thanks Nicolás for the extra pair of eyes. That was it. The
ConfigurableDirectory was an old value.
dave williamson
-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com]
Sent: Thursday, December 05, 2013 5:40 PM
To: General discussion about the WiX toolset.
I did some tests on multiple ways to handle shortcuts a few months ago:
http://sourceforge.net/mailarchive/message.php?msg_id=31481614
I didn't really get any authoritative answer on whether my findings
are correct or what option is better, though.
--
Nicolás
Leave it to Microsoft to make
Nice write up. A slight variation for your list ... We separated a
non-advertised shortcut from the exe into its own component with reg entry and
remove folder ... And nested that in a directoryref.
Eventually we get to an ICE69 because we too have multiple shortcuts across
multiple features
Currently, the stock BA doesn't allow feature selection but you could certainly
write this in a BA/UX yourself. If you are using feature trees in your MSI and
have an existing UI in it, you might be able to get away w/ showing the
internal UI but I personally would try to avoid it.
Classification: Public
I wasn't expecting the BA to show the UI for feature selection.
So what your saying is that if you run the BA once it is an install, 2nd time
it is an uninstall or repair, but it can't run the MSI in Modify mode so I can
remove/add another feature ?
Steve
-Original
Thank you for the information.
Listview .../ is also not displaying on UI using WIX3.7
On Tue, Dec 3, 2013 at 2:29 PM, Sergey Yukhno
sergey.yuk...@visutechsystem.by wrote:
Use not ListView ...,
use Listview ...
11/28/2013 12:06, dileep s пишет:
Hi All,
How to add ListView control
Hi,
We got two different products, say product A and product B.
Product B's msi is identical with product A's except the UpgradeCode is
different, and lacking some features.
Product B's source code is based on Product A's, so the components are the
same as Product A's.
Product A and
25 matches
Mail list logo
