To display the version you need to set bal:WixStandardBootstrapperApplication
ShowVersion=yes /
(I think this is documented in the help file but if not let me know and I'll
add it.)
Neil
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: 13 August 2013 23:08
Hi Kai,
Is your file deleted if the previous (Wise) installation package is
uninstalled?
BR,
Marlos
2013/8/14 K Peters kpet...@otaksoft.com
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
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
Yes, you are correct. It is documented in the 3.8 help. I missed the idea
that I needed to add
bal:WixStandardBootstrapperApplication
LicenseUrl=http://example.com/license.html;
LogoFile=path\to\customlogo.png
ShowVersion=Yes
/
As a child of
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();
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
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:
...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
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,
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 kpet...@otaksoft.com
Hi all,
my problem is this:
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
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
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
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,
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
!-- register 'clb' file extension to be opened by CalcLab.exe
--
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:
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
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
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
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 gef...@microsoft.com wrote:
Thanks for the tip. Moving my CA from after CostInitialize to after
CostFinalize
I believe file type associations are made using the ProgId and related elements.
Brett Sandberg brettl...@hotmail.com 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
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 surya6...@hotmail.com wrote:
Hi,
I have a Type 17 Custom
Action in my wxs file. The Custom Action dll
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
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
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
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
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
...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
28 matches
Mail list logo
