[WiX-users] Difference between FileCost and CostFinalize actions
Hello Install gurus, Could anyone tell me the difference between FileCost and CostFinalize actions in the windows installer sequence tables? The description in the MSDN tables is not very clear. Also the dialogs are displayed after the CostFinalize action. Does this mean that the costing process takes place again ,depending upon what the user chooses in the Feature tree? Thanks, Kiran Hegde -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Difference-between-FileCost-and-CostFinalize-actions-tp7588088.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] IRC channel
For anyone who prefers real-time forms of communication: there is a #wix IRC channel on freenode, and apparently has existed since August 2005. Currently it's pretty much dead, there's only two users and I have never seen them talk :) You can connect with an IRC client on server chat.freenode.net, channel #wix. Or, if your client supports URLs: irc://chat.freenode.net/wix Or, from a web browser: http://webchat.freenode.net/?channels=%23wix Feel free to join, ask WiX questions (maybe even receive answers! :P), rant about the component rules, or make fun of other people's bad-quality installers :) -- Nicolás -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dependent DLLs of a Custom Action Binary are not getting loaded properly
...and if any of these dependencies turn out to be dependent on a WinSxS C++ runtime Dll, these aren't actually available until InstallFinalize when the install is committed so it's pretty much mandatory to have statically bound C++ runtimes in custom action Dlls and their C++ dependencies. Phil W -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Thursday, August 15, 2013 4:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dependent DLLs of a Custom Action Binary are not getting loaded properly When is this action scheduled? Generally it is recommended that custom actions be DLLs in the Binary table compiled to "statically" include their runtime environment. Suryadeep Biswal wrote: Hi, I have a Type 17 Custom Action in my wxs file. The Custom Action dll depends on another dll that is in the same directory. However, i see that runtime does not load the dependent dll and as a result loading of the Custom Action fails with error 1157 (One of the library files needed to run this application cannot be found). This is how the Custom Action is defined - I am setting the PATH variable correctly inside the MSI but that does not help. Can someone suggest a way to get past this issue? Regards, Surya -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to retain a config file after a Major Upgrade?
You need to figure out why the upgrade is removing that file because as I
said before it's not inevitable.
1. You should add that config file to your new setup with the same component
guid. If you haven't got it in the new install then clearly it will be
removed because that file is no longer in the later version of the product.
2. Then, if RemoveExistingProducts is late in the upgrade AND the existing
config file has been modified after it was installed by the older product as
you said, then it will not be removed because of the file replacement rules.
File replacement rules:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370532(v=vs.85).as
px
People are always upgrading their products without uninstalling databases
and other data files, and this is the way it's done. Modified files don't
get overwritten (see 1) and RemoveExistingProducts at the end of the install
(see 2) is the way to do that.
Phil W
-Original Message-
From: Kai Peters [mailto:kpet...@otaksoft.com]
Sent: Thursday, August 15, 2013 6:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to retain a config file after a Major Upgrade?
Hi,
As elaborated in an earlier post my problem is this:
I have to deal with MSIs that are out in the wild (created with Wise); our
next MSIs will be created with Wix since Wise doesn't exist anymore.
These old MSIs have installed an inifile that needs to survive a major
upgrade coming from the new Wix based MSI because it contains valuable
information added by our clients. During the uninstall portion of the Major
Upgrade this inifile unfortunately does get removed.
We know there are easy ways to handle this going forward, but for now our
first Wix "release" is in jeopardy unless we can overcome this obstacle.
So how does one reliably retain a config file under the given circumstances?
A number of people (well, 2 I have found) mentioned the use of the CopyFile
element in order to
1) backup of config file to a safe location
2) perform the uninstall of the old MSI
3) restore of config file from safe location
This would be an approach that appeals to my common sense - none of the
articles/answers related to this do provide an answer as to how one could
schedule the backup & restore operations.
From my understanding, only actions can be scheduled and I could not find
any mention on how to wrap CopFile elements in there
I also found another piece of the puzzle which has a slim chance of working
for me:
According to
http://blogs.msdn.com/b/astebner/archive/2008/10/19/9006538.aspx
If my old MSI has been built like described above
("1. Place each .config file in its own component and mark the .config
file as the key path of the
component.")
then I might be in luck assuming I build the new MSI as described under 2).
Do I understand that correctly? I will test this when back at work on
Monday.
As always, thanks for all suggestions & your time,
Kai Peters
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to retain a config file after a Major Upgrade?
Hi,
As elaborated in an earlier post my problem is this:
I have to deal with MSIs that are out in the wild (created with Wise); our next
MSIs will be
created with Wix since Wise doesn't exist anymore.
These old MSIs have installed an inifile that needs to survive a major upgrade
coming from the
new Wix based MSI because it contains valuable information added by our
clients. During the
uninstall portion of the Major Upgrade this inifile unfortunately does get
removed.
We know there are easy ways to handle this going forward, but for now our first
Wix "release" is in
jeopardy unless we can overcome this obstacle.
So how does one reliably retain a config file under the given circumstances?
A number of people (well, 2 I have found) mentioned the use of the CopyFile
element in order to
1) backup of config file to a safe location
2) perform the uninstall of the old MSI
3) restore of config file from safe location
This would be an approach that appeals to my common sense - none of the
articles/answers related to
this do provide an answer as to how one could schedule the backup & restore
operations.
From my understanding, only actions can be scheduled and I could not find any
mention on how to wrap
CopFile elements in there
I also found another piece of the puzzle which has a slim chance of working for
me:
According to
http://blogs.msdn.com/b/astebner/archive/2008/10/19/9006538.aspx
If my old MSI has been built like described above
("1. Place each .config file in its own component and mark the .config file
as the key path of the
component.")
then I might be in luck assuming I build the new MSI as described under 2).
Do I understand that correctly? I will test this when back at work on Monday.
As always, thanks for all suggestions & your time,
Kai Peters
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Use a TargetProperty in a Verb in a ProgId, for file association
This might be a silly response, and I haven't had to think about Property behaviour for a while, but isn't that the wrong way to set a Property to the value of another Property? From http://msdn.microsoft.com/library/aa370908.aspx it says: "Note that you cannot use the Property table to set a property to the value of another property. The installer does nothing to the text string entered in the Value column before setting the property in the Property column. If FirstProperty is entered into the Property column and [SecondProperty] in the Value column, the value of FirstProperty is set to the text string "[SecondProperty]" and not to the value of the SecondProperty property. This is necessary to prevent creating circular references in the Property table. Instead, you can set one property to another by using a Custom Action Type 51." Does it work if you change your code to: ? NB: I didn't think at all about the sequencing, so you'd want to work out what is best for your situation. Cheers, Michael Ps. I've not added a Verb to heat output in the way you're attempting. Coming from WiX2, I post-processed the tallow output to add in my Verb. If I was doing it from scratch for WiX3, then I'd probably use XSL to generate the Verb directly into the heat output, but xsl isn't for everyone. -Original Message- From: jo...@msli.com [mailto:jo...@msli.com] Sent: Thursday, 15 August 2013 5:54 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Use a TargetProperty in a Verb in a ProgId, for file association I am using wix-3.7 on windows7, to associate my program (Compass.exe) with file-names ending in galileoGlobalProject. I can build the msi and install it, but double clicking a file raises error dialog: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item." How do I populate the correct path to my program? Details: Heat generates my list of files using the following syntax: heat.exe dir dist -dr INSTALLDIR -cg group_ProductFiles -alias .\ -norootdirectory -ext .WXS -ext .wixobj -ext .wxi MyProgram.resource_list.wxs The auto-generated section is as follows: I add this to the Project element: I try to use the TargetProperty in a Verb in order to create an Extension in a ProgId: After installing I search the registry for my extension HKEY_CLASSES_ROOT\.galileoGlobalProject (default) REG)SZ CompassgalileoGlobalProject HKEY_CLASSES_ROOT\CompassgalileoGlobalProject\shell\open\command "[group_ProductFiles:Compass.exe]" "%1" HKEY_CURRENT_USER\Software\Classes\.galileoGlobalProject HKEY_CURRENT_USER\Software\Classes\CompassgalileoGlobalProject\shell\open\command "[group_ProductFiles:Compass.exe]" "%1" HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.galileoGlobalProject\OpenWithList (value not set) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.galileoGlobalProject\OpenWithProgids CompassGalileoProjectREG_NONE (zero-length binary value) Have I done everything right? My previous post got no love, so I'm trying to rephrase the question. NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
Hi Dave, Yeah, I agree that's a good solution. However, one of the constraints of the shared component is that we can only have one COM registered (it integrates into a thirdparty application). So reversion/relocate and re-guid is not available as a solution. (We did workshop a development solution that would resolve the problem and allow us to re-guid for correct deployment, but the face the Engineering Manager pulled told the story :) .) The idea of a separate msi isn't too bad - I guess I'd be able to do something so that when all products that depend upon the shared component are uninstalled then it would also be uninstalled. I'm a very recent upgrader from WiX 2 to WiX 3, so not sure if Burn, etc would help me do this. However, again, dollars will win over technical correctness - the likelihood of this problem affecting a client is quite low and the fix is relatively simple for our support team to resolve, so I don't think I'll get much support for doing the work. Everyone's advice has definitely helped though - at least we understand the problem that we're creating for ourselves, which is much better than doing it by accident. Once again, thanks to all for the input, I appreciate it. Cheers, Michael -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Wednesday, 14 August 2013 7:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules When we release side by side versions of products we have to reversion/relocate(re-guid if com) all our shared components. e.g. All file major versions are increased and we install into different locations. All com components have version dependent naming and are reworked to not clash with previous versions. This may not be an option if it is a third party com component though, but there is the potential to use registry free com but this does have limitations. %commonfiles%\my company\product1shared %commonfiles%\my company\product2shared %programfiles%\my company\product\product1 % programfiles %\my company\product\product2 If you are not dealing with com you can load your dependencies dynamically from the new common folder in the later version of the software. Beyond that you are getting into bad practices. Could you install the dependent dll (or shared components) in a separate msi that doesn't get uninstalled automatically on product2 removal. Or some horrendous custom action that puts the dependent dll back if you are removing it and will break product1. Dave -Original Message- From: Michael Partridge [mailto:michael.partri...@petrosys.com.au] Sent: 14 August 2013 03:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules Thanks to all for the feedback. I do agree with the consensus that Product1 is broken and should be fixed with an upgrade or patch. However, in the real world, that isn't going to happen in this case. As I said, Product1 and Product2 are side-by-side installs of the same application, where there is separate Product for each major version shipped. So, in my example Product1 is really a placeholder representing 12 different Products (which then all have their own minor version history). I know I'll never get the resources to make the fix for all these versions, unfortunate situation where money wins over perfection. At least I understand (correctly!) the compromise we're making. (And yeah, we do have a service plan for all our earlier versions for, say, security issues, but this issue won't be high enough up the list to trigger one of those. I will keep a record and put in the fix if we do create a new version of one of the existing "Product1"'s.) Thanks again for the useful input. Cheers, Michael Ps. I have pushed back to the developer to see if we can remove this additional dependency, but unsure if that will be possible. -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Wednesday, 14 August 2013 8:08 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules I agree. A common shared component has been updated and it needs fixing in all the products because it can no longer be shared properly. Phil -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, August 13, 2013 10:14 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent fileger to shared component without breaking component rules This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for that product, what if it has a critical security issue/flaw? You could release product2 a
[WiX-users] Complex Burn UI sample?
Hi, I'm presently working on a multi-package installer with a custom UI, and I'm using WPF. I've got something primitive working that looks something like NSIS's MUI since that's what our old installer used, but I was hoping to move towards something a bit more modern. Sadly however I'm at a loss for examples. The WixBA is attractive, but a bit too simple with no support for selecting optional features, while the Visual Studio Installer is closed source but clearly exercise much more of Burn's functionality. Is there any chance something as complex as the visual studio installer might be opened up as an example to help drive consistent install UX? Alternatively, are there any other installers besides Wix & Visual Studio 2012 that might be good examples to look at? -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dependent DLLs of a Custom Action Binary are not getting loaded properly
When is this action scheduled? Generally it is recommended that custom actions be DLLs in the Binary table compiled to "statically" include their runtime environment. Suryadeep Biswal wrote: Hi, I have a Type 17 Custom Action in my wxs file. The Custom Action dll depends on another dll that is in the same directory. However, i see that runtime does not load the dependent dll and as a result loading of the Custom Action fails with error 1157 (One of the library files needed to run this application cannot be found). This is how the Custom Action is defined - I am setting the PATH variable correctly inside the MSI but that does not help. Can someone suggest a way to get past this issue? Regards, Surya -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Simplest 64bit Install
I believe file type associations are made using the ProgId and related elements. Brett Sandberg wrote: Hi, I'm new to WiX and I'm trying to create a simple installer of a 64 bit program (called CalcLab) using Wix and VS2012. I made a new VS project by choosing Project|New and then choosing Windows-Installer-XML and Setup-Project. Then I modified the default Product.wxs file to suit my situation. I did this by browsing examples on the web without really understanding the details of WiX. I ended up with the Product.wxs file below which almost works. CalcLab appears to install ok but if I try to associate a file type with it (CalcLab loads files with a .clb ext), I can't. If I right click on a .clb file and choose "open with" and "choose default program" and then click "browse" and then choose CalcLab.exe, CalcLab doesn't appear in the list of programs to choose from. If I go to "Add or Remove Programs", CalcLab is in the list so Windows7 knows it's installed. Any help would definitely be appreciated, Brett. http://schemas.microsoft.com/wix/2006/wi";> -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msiexec.exe /qn option causes memory corruption?
Whether you have UI or not, if you didn't suppress the hi sequence table
creation it will run. Costing occurs in both sequences (usually before most of
the dialogs).
George Fleming wrote:
Thanks for the tip. Moving my CA from after CostInitialize to after
CostFinalize seems to do the trick.
I have no UI in my installer, so I wonder how the variable got set before, but
not now.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Thursday, August 15, 2013 12:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] msiexec.exe /qn option causes memory corruption?
No, it doesn't corrupt memory, but with UI completely suppressed, only your
"execute" sequence is going to run. Also, in general you can't count on
Directory "properties" being valid until after CostFinalize. The combination
of early scheduling and your "UI" sequence not running probably results in
INSTALLFOLDER not being initialized. When the UI runs, the InstallDir Dialog
(or something like it--I don't know your authoring) has a chance to set this.
--
John Merryweather Cooper
Build & Install Engineer -- ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Thursday, August 15, 2013 2:25 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] msiexec.exe /qn option causes memory corruption?
I recently made some changes to installer code, and now it doesn't install
properly. Investigations show that if I install without /qn option at command
line, everything works as expected. If installed with /qn option (which also
requires installer to run as admin), the variable INSTALLFOLDER mysteriously
becomes null in my custom action. In my custom action, I have:
string oldString = session["INSTALLFOLDER"]; session.Log("string value = {0},
oldString);
and it's invoked right after CostInitialize (non-deferred) stage. Log shows
that oldString has a value of null, but log also shows that INSTALLFOLDER is
set correctly elsewhere.
If I don't use /qn option, then oldstring has correct value. I'm guessing that
/qn somehow corrupts the memory, but not sure how at the moment.
I will try to back out my changes to try and isolate this, but has anyone else
seen anything like this?
Thanks,
George
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended exclusively for the individual or entity to which it is addressed. The
message, together with any attachment, may contain confidential and/or
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email and delete all
copies.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=4
Re: [WiX-users] how to reference an element in heat generated file?
That's why I use a transform to insert the file association code under the file element and I don't harvest my icons. To ne fair, harvesting was originally intended to be performed just once, not each build. Most projects don't need to be harvested each time, but there are systems that do require it. "jo...@msli.com" wrote: If heat generates a file with unique identifiers for each element, is it true that the Id of a particular element can't be referenced elsewhere, as there is no way to determine the correct name? I am facing this situation by trying to create a file association, where my exe has an Id that changes every time I run heat, yet creating a file association requires a TargetFile and Icon that refer to an Id, and not the name of the file it self. The following is a file association, but the '?' are the areas of interest: A hack is calling heat.exe with argument -suid, which sets the Id = file name, and I simply use the file name in TargetFile="file_name.exe", but it has issues if two files have the same name in different areas (i think). Since heat is part of wix it seems like in the design of how all the parts fit together there must be a better way. NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Dependent DLLs of a Custom Action Binary are not getting loaded properly
Hi, I have a Type 17 Custom Action in my wxs file. The Custom Action dll depends on another dll that is in the same directory. However, i see that runtime does not load the dependent dll and as a result loading of the Custom Action fails with error 1157 (One of the library files needed to run this application cannot be found). This is how the Custom Action is defined - I am setting the PATH variable correctly inside the MSI but that does not help. Can someone suggest a way to get past this issue? Regards, Surya -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ExePackage and Quiet install condition.
Can I disable some ExePackage on a Wix BA when installation executed in quiet mode ? Thanks Andrii T. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Simplest 64bit Install
I am realativly new also, but I posted my file association code in answer to another question, here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Use-a-TargetProperty-in-a-Verb-in-a-ProgId-for-file-association-td7588039.html -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Simplest-64bit-Install-tp7588068p7588074.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Simplest 64bit Install
Hi Brett, I am a newbie myself so other might improve my reply... You'll need to handle the file association by adding something like below inside of your component underneath the file element (untested) Cheers, Kai Argument='"%1"' /> -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msiexec.exe /qn option causes memory corruption?
Thanks for the tip. Moving my CA from after CostInitialize to after
CostFinalize seems to do the trick.
I have no UI in my installer, so I wonder how the variable got set before, but
not now.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Thursday, August 15, 2013 12:39 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] msiexec.exe /qn option causes memory corruption?
No, it doesn't corrupt memory, but with UI completely suppressed, only your
"execute" sequence is going to run. Also, in general you can't count on
Directory "properties" being valid until after CostFinalize. The combination
of early scheduling and your "UI" sequence not running probably results in
INSTALLFOLDER not being initialized. When the UI runs, the InstallDir Dialog
(or something like it--I don't know your authoring) has a chance to set this.
--
John Merryweather Cooper
Build & Install Engineer -- ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Thursday, August 15, 2013 2:25 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] msiexec.exe /qn option causes memory corruption?
I recently made some changes to installer code, and now it doesn't install
properly. Investigations show that if I install without /qn option at command
line, everything works as expected. If installed with /qn option (which also
requires installer to run as admin), the variable INSTALLFOLDER mysteriously
becomes null in my custom action. In my custom action, I have:
string oldString = session["INSTALLFOLDER"]; session.Log("string value = {0},
oldString);
and it's invoked right after CostInitialize (non-deferred) stage. Log shows
that oldString has a value of null, but log also shows that INSTALLFOLDER is
set correctly elsewhere.
If I don't use /qn option, then oldstring has correct value. I'm guessing that
/qn somehow corrupts the memory, but not sure how at the moment.
I will try to back out my changes to try and isolate this, but has anyone else
seen anything like this?
Thanks,
George
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended exclusively for the individual or entity to which it is addressed. The
message, together with any attachment, may contain confidential and/or
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution is strictly prohibited. If you have received this message in
error, please immediately advise the sender by reply email and delete all
copies.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Simplest 64bit Install
Hi, I'm new to WiX and I'm trying to create a simple installer of a 64 bit program (called CalcLab) using Wix and VS2012. I made a new VS project by choosing Project|New and then choosing Windows-Installer-XML and Setup-Project. Then I modified the default Product.wxs file to suit my situation. I did this by browsing examples on the web without really understanding the details of WiX. I ended up with the Product.wxs file below which almost works. CalcLab appears to install ok but if I try to associate a file type with it (CalcLab loads files with a .clb ext), I can't. If I right click on a .clb file and choose "open with" and "choose default program" and then click "browse" and then choose CalcLab.exe, CalcLab doesn't appear in the list of programs to choose from. If I go to "Add or Remove Programs", CalcLab is in the list so Windows7 knows it's installed. Any help would definitely be appreciated, Brett. http://schemas.microsoft.com/wix/2006/wi";> -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msiexec.exe /qn option causes memory corruption?
No, it doesn't corrupt memory, but with UI completely suppressed, only your
"execute" sequence is going to run. Also, in general you can't count on
Directory "properties" being valid until after CostFinalize. The combination
of early scheduling and your "UI" sequence not running probably results in
INSTALLFOLDER not being initialized. When the UI runs, the InstallDir Dialog
(or something like it--I don't know your authoring) has a chance to set this.
--
John Merryweather Cooper
Build & Install Engineer -- ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Thursday, August 15, 2013 2:25 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] msiexec.exe /qn option causes memory corruption?
I recently made some changes to installer code, and now it doesn't install
properly. Investigations show that if I install without /qn option at command
line, everything works as expected. If installed with /qn option (which also
requires installer to run as admin), the variable INSTALLFOLDER mysteriously
becomes null in my custom action. In my custom action, I have:
string oldString = session["INSTALLFOLDER"]; session.Log("string value = {0},
oldString);
and it's invoked right after CostInitialize (non-deferred) stage. Log shows
that oldString has a value of null, but log also shows that INSTALLFOLDER is
set correctly elsewhere.
If I don't use /qn option, then oldstring has correct value. I'm guessing that
/qn somehow corrupts the memory, but not sure how at the moment.
I will try to back out my changes to try and isolate this, but has anyone else
seen anything like this?
Thanks,
George
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] msiexec.exe /qn option causes memory corruption?
I recently made some changes to installer code, and now it doesn't install
properly. Investigations show that if I install without /qn option at command
line, everything works as expected. If installed with /qn option (which also
requires installer to run as admin), the variable INSTALLFOLDER mysteriously
becomes null in my custom action. In my custom action, I have:
string oldString = session["INSTALLFOLDER"];
session.Log("string value = {0}, oldString);
and it's invoked right after CostInitialize (non-deferred) stage. Log shows
that oldString has a value of null, but log also shows that INSTALLFOLDER is
set correctly elsewhere.
If I don't use /qn option, then oldstring has correct value. I'm guessing that
/qn somehow corrupts the memory, but not sure how at the moment.
I will try to back out my changes to try and isolate this, but has anyone else
seen anything like this?
Thanks,
George
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How not to uninstall a file?
Hi Marlos, yes, that's what is happening BR, Kai On Thu, 15 Aug 2013 10:07:33 -0300, Marlos Gottschild wrote: > Hi Kai, > > Is your file deleted if the previous (Wise) installation package is > uninstalled? > > BR, > Marlos > > > 2013/8/14 K Peters > >> Hi all, >> >> my problem is this: >> >> I have to deal with MSIs that are out in the wild (created with Wise); our >> next MSIs will be >> created with Wix since Wise doesn't exist anymore. >> >> These old MSIs have installed an inifile that needs to survive a major >> upgrade coming from the >> new Wix based MSI. >> >>> From decompiling an old MSI I conclude that it contained a custom DLL used >>> >> to make a backup of said inifile and then copy it back into place at then >> end of the upgrade. >> >> Will I have to do the same or is there (much preferred) a way to achieve >> this without a custom >> dll? >> >> TIA, >> Kai >> >> PS: Blair - thank you much for all your answers - much appreciated! >> >> -- >> Get 100% >> visibility into Java/.NET code with AppDynamics Lite! It's a free >> troubleshooting tool designed >> for production. >> Get down to code-level detail for bottlenecks, with <2% overhead. Download >> for free and get >> started troubleshooting in minutes. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> ___ WiX-users mailing list WiX- >> us...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > -- > Get 100% > visibility into Java/.NET code with AppDynamics Lite! It's a free > troubleshooting tool designed > for production. > Get down to code-level detail for bottlenecks, with <2% overhead. Download > for free and get > started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ WiX-users mailing list WiX- > us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Converting VS Setup project to WiX
SharedDllRefCount is almost always not required. You need it only if the same files might be installed to the same location at a later date with a non-Windows Installer setup - these typically update SharedDllRefCount for the file path in the registry. As the MSDN docs say: "If this bit is set, the installer increments the reference count in the shared DLL registry of the component's key file. If this bit is not set, the installer increments the reference count only if the reference count already exists." And as you can see, if you tell Windows that a file is shared with a non-MSI setup, it won't remove it if the decremented count is greater than zero. At the risk of stating the obvious, MSI setups use component guid ref counting, not the shared Dll ref count. Phil W -Original Message- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Thursday, August 15, 2013 6:43 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Converting VS Setup project to WiX I am replacing a (very) old Visual Studio installer project with WiX. I've copied the UpgradeCode from the old installer and have remove existing products scheduled after install validate but I am seeing slightly odd behaviour if I upgrade from old to new and subsequently uninstall: some DLLs are not being removed. If I manually uninstall the old version before installing the new one, I don't get this problem. The difference between these DLLs and others which are removed seems to be that the component IDs for those left behind have changed. (OK so, as I *now* understand it, that breaks component rules, however these are shared components which have already been released into the wild in other installers.) A verbose log of the upgrade install shows "SharedDllRefCount=3" for each of the DLLs in question which I guess is why they aren't subsequently removed. So the first question is, why is ref count 3 (given that the previous version has been removed)? Also I had SharedDllRefCount="yes" and, after further testing, it appears that setting it to "no" fixes the problem. The next question, then, is: is that a good idea? would it have other consequences, especially with regard to the other installers already "out there"? Thanks, Kevin -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How not to uninstall a file?
...also, it's not inevitable that a major upgrade will remove a file. If RemoveExistingProducts is towards the end of the execute sequence then the upgrade is essentially a merge of the new product over the old, subject to file replacement rules which mean (for data files) that it will not be overwritten by the new one in your new setup if it's been updated since it was first installed. Phil W -Original Message- From: Marlos Gottschild [mailto:marlos.gottsch...@gmail.com] Sent: Thursday, August 15, 2013 6:08 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How not to uninstall a file? Hi Kai, Is your file deleted if the previous (Wise) installation package is uninstalled? BR, Marlos 2013/8/14 K Peters > Hi all, > > my problem is this: > > I have to deal with MSIs that are out in the wild (created with Wise); > our next MSIs will be created with Wix since Wise doesn't exist anymore. > > These old MSIs have installed an inifile that needs to survive a major > upgrade coming from the new Wix based MSI. > > >From decompiling an old MSI I conclude that it contained a custom DLL > >used > to make a backup of said inifile and then copy it back into place at > then end of the upgrade. > > Will I have to do the same or is there (much preferred) a way to > achieve this without a custom dll? > > TIA, > Kai > > PS: Blair - thank you much for all your answers - much appreciated! > > -- > Get 100% visibility into Java/.NET code with AppDynamics > Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c > lktrk ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixStdBA - LoadBootstrapperBA changes m_fPrereq
A simple repo was create which has the same behavior. Bug 3357 was created. I also had another thread at wixextba.codeplex.com which ended up discussing this issue. I'm sorry for the double post and appreciate all comments. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WixStdBA-LoadBootstrapperBA-changes-m-fPrereq-tp7588034p7588062.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to reference an element in heat generated file?
If heat generates a file with unique identifiers for each element, is it true that the Id of a particular element can't be referenced elsewhere, as there is no way to determine the correct name? I am facing this situation by trying to create a file association, where my exe has an Id that changes every time I run heat, yet creating a file association requires a TargetFile and Icon that refer to an Id, and not the name of the file it self. The following is a file association, but the '?' are the areas of interest: A hack is calling heat.exe with argument -suid, which sets the Id = file name, and I simply use the file name in TargetFile="file_name.exe", but it has issues if two files have the same name in different areas (i think). Since heat is part of wix it seems like in the design of how all the parts fit together there must be a better way. NOTICE: This email may contain confidential information. Please see http://www.meyersound.com/confidential/ for our complete policy. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixStdBA - LoadBootstrapperBA changes m_fPrereq
Just to clarify, I'm not setting the m_fPrereq variable. I was just stepping through the code to learn how it works, and I can see that m_fPrereq is set to zero in the constructor of the class, but under WinDbg I can see that it unexpectedly changes in the call to LoadBootstrapperBAFunctions(); (and there is not BAFunction.dll defined in my project), and that the next if-else block is not executed as I expect which would seem to indicate a problem to me. It is just something I observed while stepping through the code. In the mean time Neil let me know that I had not added a element to my project and I will make that change. I will then step into the code to see if this observation still exists. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WixStdBA-LoadBootstrapperBA-changes-m-fPrereq-tp7588034p7588057.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Theme 3.8 - Customize WixStandardBootstrapperApplication
Yes, you are correct. It is documented in the 3.8 help. I missed the idea that I needed to add "http://example.com/license.html"; LogoFile="path\to\customlogo.png" ShowVersion="Yes" /> " As a child of the element. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Theme-3-8-Customize-WixStandardBootstrapperApplication-tp7587999p7588056.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Converting VS Setup project to WiX
I am replacing a (very) old Visual Studio installer project with WiX. I've copied the UpgradeCode from the old installer and have remove existing products scheduled after install validate but I am seeing slightly odd behaviour if I upgrade from old to new and subsequently uninstall: some DLLs are not being removed. If I manually uninstall the old version before installing the new one, I don't get this problem. The difference between these DLLs and others which are removed seems to be that the component IDs for those left behind have changed. (OK so, as I *now* understand it, that breaks component rules, however these are shared components which have already been released into the wild in other installers.) A verbose log of the upgrade install shows "SharedDllRefCount=3" for each of the DLLs in question which I guess is why they aren't subsequently removed. So the first question is, why is ref count 3 (given that the previous version has been removed)? Also I had SharedDllRefCount="yes" and, after further testing, it appears that setting it to "no" fixes the problem. The next question, then, is: is that a good idea? would it have other consequences, especially with regard to the other installers already "out there"? Thanks, Kevin -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How not to uninstall a file?
Hi Kai, Is your file deleted if the previous (Wise) installation package is uninstalled? BR, Marlos 2013/8/14 K Peters > Hi all, > > my problem is this: > > I have to deal with MSIs that are out in the wild (created with Wise); our > next MSIs will be created with Wix since Wise doesn't exist anymore. > > These old MSIs have installed an inifile that needs to survive a major > upgrade coming from the new Wix based MSI. > > >From decompiling an old MSI I conclude that it contained a custom DLL used > to make a backup of said inifile and then copy it back into place at then > end of the upgrade. > > Will I have to do the same or is there (much preferred) a way to achieve > this without a custom dll? > > TIA, > Kai > > PS: Blair - thank you much for all your answers - much appreciated! > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
