Hello All,
Thanks for understanding my issue. I have found the solution to my problem.
It was all because of harvesting the solution. I was missing the step so was
not able to run the MSI on machine other then the development.
I have then perform the harvesting of the Installer and it worked.
Hi Phil,
Thank you for getting back to me,
Yes I have tried doing a registry search then calling that variable within
the InstallCommand for exepackage however it doesn't seem to be able to read
it in that way, even though in the logs I do see the variable being declared
but when the installcomma
No, I never found a solution to this problem. I reverted back to using
embedded cab files, which avoided the problem, for now.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wix39-signing-external-cabs-tp7595976p7596202.html
Sent from the wix-use
There is no such thing as a 'Burn custom action' (and it would be overkill if
it existed). I suggest that you try the built-in functionality of
util:RegistrySearch and using the variable in the Install condition.
If it does not work for you, then post the relevant sections of code and a
verbose l
Hi all,
Previously I thought Bundles can be designed by creating a multilingual BAL
and bundle that with (a) monolingual english MSI(s). But now I mention
small things that make it inevitable to have MSIs with transforms e.g. for
things like Description + Command localization for File Extension
Re
I created a dummy basic installer with the same logic that has the issue,
code below and the log file attached.
See the installcommand below were the /D=[SDK_DIR]" should install the
SDK.exe to that location as determined in the registry search. In line 6 of
the log it declares the SDK_DIR variab
In your registry search, change Variable="[SDK_DIR]" to Variable="SDK_DIR".
On Mon, Aug 4, 2014 at 9:52 AM, psimms wrote:
> I created a dummy basic installer with the same logic that has the issue,
> code below and the log file attached.
>
> See the installcommand below were the /D=[SDK_DIR]" s
Hi All,
I have two MSI projects to a common root directory. The path to the root
directory can be selected by the user. Each project uses Heat to generate the
files to be deployed. I also have a burn bootstrapper that chains together the
two msi packages.
I am looking into implementing
My MSI will install a dll and an exe.
The dll will self-register.
The exe is run by a custom action with a command-line parameter to perform
registration and update the registry.
The exe can take a command-line parameter to unregister itself and remove
references in the registry.
How do I ensure
Don't use self registration, use the registry keys in the MSI Registry table.
Then it works, and you don't need to worry about a custom action.
-Original Message-
From: dpflan [mailto:dpflann...@gmail.com]
Sent: Monday, August 04, 2014 12:13 PM
To: wix-users@lists.sourceforge.net
Subject
This could be a good alternative. Though, I remember I could not use heat to
harvest a 64bit dll.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Ensure-Uninstall-When-Needed-Files-are-Deleted-by-User-tp7596209p7596211.html
Sent from the wix-users
Is there an equivalent tool for harvesting registry info for the 64bit dll?
1. One solution is to not let any files self-register.
Is there another solution?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Ensure-Uninstall-When-Needed-Files-are-D
If the only thing that is using your DLL is your EXE, use reg-free COM via an
application manifest and forget about the registry altogether.
-Original Message-
From: dpflan [mailto:dpflann...@gmail.com]
Sent: Monday, August 04, 2014 12:30 PM
To: wix-users@lists.sourceforge.net
Subject:
The EXE and DLL are independent.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Ensure-Uninstall-When-Needed-Files-are-Deleted-by-User-tp7596209p7596214.html
Sent from the wix-users mailing list archive at Nabble.com.
I have a Burn setup exe package and I'd like to make patches to update only a
few files using the same Burn interface, how can I make this?
Which is the right way for automate this process inside TFS build system?I have
a build definition that create all the msi packages that are included in the
This is how I make patches.
http://borgsdemons.com/blog/2014/07/11/yet-more-improve-wix-way-patch-project-with-burn-bootstrapper/
I currently don't have a product with multiple MSI's, although I am planning to
"debundle" a multiple feature MSI into multiple MSI's and deploy them with Burn.
--
>>I am wondering if it is possible to use Heat twice in one project.
A MSBuild target is only called once.
In one project I need to harvest files from different source locations. I
define MSBuild Targets with appropriate properties and in each I call the
HeatDirectory Task (not target). The
Hello,
I'm migrating an install from MSI based InstallShield to WiX using the
standard bootstrapper. Installation of the new product version (WiX based)
over older versions (IS MSI based) works fine.
The problem I'm having is the old IS installs do not recognize the newer WiX
installations and I
On 04-Aug-14 10:43, Tobias S wrote:
> What are the best approaches for MSIs within multilingual bundles?
Keep neutral resources in one package, localized resources in another
package, one per language (i.e., lang pack).
--
sig://boB
http://joyofsetup.com/
--
19 matches
Mail list logo
