Thanks for the elaborate explanation, it made things clearer. But the
current structure that i am trying to follow is something that has been
decided upon.
How would i parse the INSTALLDIR value after it's been changed in the UI
and isolate out the part that has changed, i mean is there some
Thanks Phil, for the elaborate explanation, it made things clearer. But
the current structure that i am trying to follow is something that has
been decided upon.
How would i parse the INSTALLDIR value after it's been changed in the UI
and isolate out the part that has changed, i mean is there
Sorry, if this is a re-post.
We have lots of third party components (msi, exe installer) to be delivered
on user's machine. Although, there is a main script, used to install these
in a required sequence on user's machine, but for delivery purposes, we are
creating one self extracting archive
Hi Ravi,
Heat creates its unique file/component references based on the source name
of the file.
So if you change the name, or the relative location of the source file, then
the file reference may well change.
I believe there is a way to force it to not generate new references, however
I've found
Suvrajyoti,
If you allow the INSTALLDIR to be changed, then the whole thing could be
different...
For instance if someone changed the INSTALLDIR to be C:\, then what do you
consider that the C:\ProgramData.. folder should be named?
I believe that you shouldn't allow the user to select any
Hey Walter,
As of now no, i do not have that option.
Regards,
Suvra Jyoti
On 19-03-2014 17:27, Walter Dexter wrote:
Do you have the option to disallow install directory being changed? Seems
like a lot of software is doing that lately.
On Mar 18, 2014 8:03 AM, Suvrajyoti Panda
Look at ProductSearch in the chm.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Identify-installed-product-by-productCode-tp7593540p7593541.html
Sent from the wix-users mailing list archive at Nabble.com.
Notice that there is a Util:ProductSearch (for use in Bundles) and a
wix:ProductSearch for use in an MSI.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Identify-installed-product-by-productCode-tp7593540p7593542.html
Sent from the wix-users
Hi Guys, somebody please help me with this problem:
http://stackoverflow.com/questions/22504176/win-32-application-is-not-launching-in-win-64-bit-os
I couldn't run my application on Win 64 bit OS( Win 8.1). Please help me.
Thank you.
karthik
-
Wix 3.8 users
--
View this message in
1) Client side isn't going to give you very many details, but basically, the
server is refusing to allow a connection.
2) The Persist Security Info attribute on your connection strings opens a
truck-sized security hole in your application. I would strongly recommend
removing it.
3) This
Typically you would create a Bootstrapper project which has a Bundle element
and a Chain element. In the Bundle element you could use the
util:ProductSearch and then use the result to notify the user in the BA or
condition whether an MSI gets installed. The MSI would be added to the
Bundle's
It's clear your catch handler is being called because of the EXCEPTION property
being set. You're probably having an exception in the course of handling the
exception. In general, having things that can throw exceptions in catch blocks
(especially unreliable things such as File I/O access) is
Hi Bevan,
Could you please provide some sample code on how to have a formatted
string as the folder names for these two items or the custom action thing.
Regards,
Suvra Jyoti
On 19-03-2014 17:37, Bevan Weiss wrote:
Suvrajyoti,
If you allow the INSTALLDIR to be changed, then the whole thing
You're trying to sign your WinRar exe with signtool? I'm betting a 3.5 GB file
is probably not supported with signtool, but regardless this isn't a Wix issue.
I'm having trouble wrapping my head around scheduling a custom action of
mine. I want to run the CA on these conditions:
- it's the first time installing
- on the INSTALL portion of a major upgrade
- NOT on the remove portion of the major upgrade
- NOT during an uninstall
I have my condition
a good summary of conditions can be found in the
http://blogs.flexerasoftware.com/installtalk/2013/04/installer-cheat-sheet-series.html(Common
MSI Conditions Cheat Sheet -
http://www.flexerasoftware.jp/webdocuments/PDF/IS-CHS-Common-MSI-Conditions.pdf)
or on e.g.
It looks like I need to change to:
(NOT Installed) OR (NOT UPGRADINGPRODUCTCODE AND REMOVEALL)
I will verify :) Thank you!
On Wed, Mar 19, 2014 at 11:20 AM, Tobias S tobias.s1...@gmail.com wrote:
a good summary of conditions can be found in the
If I could kiss you, I would. THANKS!
On Wed, Mar 19, 2014 at 11:20 AM, Tobias S tobias.s1...@gmail.com wrote:
a good summary of conditions can be found in the
http://blogs.flexerasoftware.com/installtalk/2013/04/installer-cheat-sheet-series.html(Common
MSI Conditions Cheat Sheet -
1. Probably a DWORD's worth.
2. I'd say, don't create Bundles 300 MB. Windows is slow to verify/launch big
executables.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
I may be misunderstanding your requirement, but UPGRADINGPRODUCTCODE
is set in the *older* product that is the target of the upgrade, not
in the newer incoming product. If you wish your install to not run a
CA if it is upgrading an older version then use the property set by
the newer upgrade,
I think my wife would get a tad upset about that lol.
-Original Message-
From: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Wednesday, March 19, 2014 8:35 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] CA Condition on Major Upgrade
If I could kiss you, I
I need to throw a message on the screen during uninstall. How do I do that?
Thanks
Woody
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
http://msdn.microsoft.com/en-us/library/gg513929.aspx
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Making-64-bit-installer-from-32bit-wix-file-tp7593557p7593558.html
Sent from the wix-users mailing list archive at Nabble.com.
Hi Phil, the dependencies are common and no other 3rd party dll. When you
pull the files from release folder it works on Window 8.1 64 bit OS. But
it's not working right after the installtion.
thank you.
karthik
-
Wix 3.8 users
--
View this message in context:
If your application is a 32 bit application, you should only use a 32 bit
installer. Regardless, this isn't a WiX issue. If you copied your application
from your development machine to the x64 test machine, it would die in the same
way. You need to debug and analyze your application ad see
Hi Harold,
The uninstall cannot have standard Wix Dialogs from what I know. We had a
similar requirement and I used a custom action (c#) to pop-up a OK message
box.
Something like this. Schedule this action only during uninstall(REMOVE=ALL) in
the installExecute sequence.
[CustomAction]
Hi, if i grab the release folder files, it's working. I don't understand why
the installer is not working. The files are put up in the folder x86 of
64bit os.
-
Wix 3.8 users
--
View this message in context:
Hi Alan,
Like Bryan said your exception block does seem to be invoked.
Since you have Return=check, the Installation is rolling back.
--Pavan
-Original Message-
From: Bryan Wolf [mailto:brw...@jackhenry.com]
Sent: Wednesday, March 19, 2014 7:05 AM
To: General discussion about the WiX
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7593563/photo_3.jpg
This is the error message from Event log.
-
Wix 3.8 users
--
View this message in context:
That wouldn't work for a silent installation if you did it across the
network, would it? I think you'd end up with a dialog box that you couldn't
do anything with. I could be wrong.
On Wed, Mar 19, 2014 at 1:54 PM, Pavan Konduru
pavan.kond...@accelrys.comwrote:
Hi Harold,
The uninstall
Have you compared the Release folder files to that of the ones on the
destination machine?
-Original Message-
From: karthikrangaraj [mailto:kranga...@dnpphoto.eu]
Sent: Wednesday, March 19, 2014 12:58 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Making 64 bit
Hi, right after the installation I'll copy paste the files from Release
folder make a test.
Does it make sense for testing purpose?
Thank you
-
Wix 3.8 users
--
View this message in context:
The condition should be :
REMOVE = ALL AND UILevel 2
This way it wouldn't cause issues with silent installation.
-Original Message-
From: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Wednesday, March 19, 2014 11:05 AM
To: General discussion about the WiX toolset.
Subject: Re:
Thanks!!
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Wednesday, March 19, 2014 10:55 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] UI on uninstall
Hi Harold,
The uninstall cannot have standard Wix Dialogs from
If the operator does the uninstall from the control console is that a silent
uninstall?
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Wednesday, March 19, 2014 11:19 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] UI on
I thought the DTF custom actions had a message call that ultimately
uses MsiProcessMessage(), the point being that it automatically won't
show the message if the UI is missing. Maybe it's Session.Message or
something like that.
---
Phil Wilson
On Wed, Mar 19, 2014 at 11:33 AM,
That looks like an issue with your Xaml data trying to start up the
UI. I don't see how that can be a WiX issue.
---
Phil Wilson
On Wed, Mar 19, 2014 at 11:04 AM, Hoover, Jacob
jacob.hoo...@greenheck.com wrote:
Have you compared the Release folder files to that of the ones on the
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_
a_file.html
Try this..
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=APPLICATIONROOTDIRECTORY Name=[YOUR SILLY PROGRAM
FILES PATH]/
/Directory
Directory
That's right Phil, We can use something like this in the custom action which
would take care of the silent mode installation:
Record record = new Record();
record.FormatString = string.Format(Some message.);
MessageResult value = session.Message(
Hi,
eveything is working perfectly on Win 32 and there is no other dependencies
fro 64bit. As i said if i launch a release folder files in Win 8.1 64
bit..everything is working.
Thank you
-
Wix 3.8 users
--
View this message in context:
It's not that code you have won't work, but:
You should never call the standard messagebox functions during an
install operation. They ignore silent installs, don't follow the UI
rules (minimal vs silent) and frequently show behind the main window,
and don't put the message in the MSI log. That's
Which is why I asked you to compare file by file to see what one is different.
I'm guessing either you missed a file (so it exists in your release folder but
not in the install), or you are grabbing the wrong file from a different
location. Compare file size, versions, and names. Something has
Hi Guys, i need some help. When I created a installer for 64bit OS, the
application is not launching. Even i made a 64 bit installer, same iisue.
App working fine on 32 bit os. Thank you
This is the product.wix file:
?xml version=1.0?
?define ProductVersion = 1.0.0.0?
?define ProductUpgradeCode
There's a collection of tips and links here for building 64/32 bit setups:
http://blogs.msdn.com/b/astebner/archive/2007/08/09/4317654.aspx
However you need to figure out why your app is failing, and we can't
debug that with WiX source. Typical issues are missing 64-bit
dependencies; .NET AnyCpu
Cool! Thanks!
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Wednesday, March 19, 2014 12:18 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] UI on uninstall
That's right Phil, We can use something like this in the custom action
Ok this is what I have so far:
Product.wxs
!--Display the uninstall message box so user is informed we will not
remove the databases--
Custom Action =UninstallMessage
After=InstallFinalizeRemove/Custom
Custom Action =UninstallMessage.Show
Is it me, or is it impossible to rename a C# custom action function once
you've built it?
My wxs files are correct to reflect the new name. I have verified that the
binary file that is in there has the newly named method after I build it (I
saved it from Orca and did `dumpbin saved.dll /EXPORTS`
I assume you've also modified your C# CustomAction to include the updated name
and rebuilt it? Do you have a full log available (or at least some of the
lines before that where the CA is being extracted). If need be, one could peek
into the temp file after extraction and ensure it's using the
Is is you. The entry point can be re-used with a new Id:
CustomAction Id=CallMeByThisName BinaryKey=MYCA
DllEntry=MyCSharpEntryPoint Execute=immediate /
CustomAction Id=CallMeByAnotherName BinaryKey=MYCA
DllEntry=MyCSharpEntryPoint Execute=immediate /
--
John Merryweather Cooper
Build
Windows Installer uninstalls MSI packages in passive mode so UI is not
displayed.
Ever get the feeling like you're not supposed to show UI during the uninstall
of an MSI? Yeah, me too. wink/
___
FireGiant | Dedicated support for
Yes, I actually started by using ReSharper to rename my CA method, as I
have unit tests around all of them. After that I updated all of my wxs
files so that they are correct. I backed out the changes for now, but I can
try it again later to see what the full log is. I may be able to put
together a
John,
I'm not following. I renamed the C# method that has the [CustomAction]
attribute on it, so shouldn't that change the DllEntry value in the
CustomAction / element?
On Wed, Mar 19, 2014 at 6:02 PM, John Cooper jocoo...@jackhenry.com wrote:
Is is you. The entry point can be re-used with a
Make the condition REMOVE=ALL
-Original Message-
From: Harold Wood (H10 Capital) [mailto:v-wow...@microsoft.com]
Sent: Wednesday, March 19, 2014 2:49 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] uI on silent uninstall
Ok this is what I have so far:
Product.wxs
I did that and it didn't work.
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Wednesday, March 19, 2014 3:20 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] uI on silent uninstall
Make the condition REMOVE=ALL
-Original
I am using wix 3.7.
Even though all my custom actions are marked as .bet 4.0 compatible, my
installer still requires .net 3.5.
I only want to require .net 4.0.
How can I configure my installer to not need .net 3.5?
Thanks,
Kevin Delafield
Sent from my T-Mobile 4G LTE Device
Did you declare the custom action in the .wxs file?
-Original Message-
From: Harold Wood (H10 Capital) [mailto:v-wow...@microsoft.com]
Sent: Wednesday, March 19, 2014 3:29 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] uI on silent uninstall
I did that and it
This may be a silly question, but have you also cleared out your temp
directories? Also, did you
I think it should be possible to export the DLL using Orca to a file on
disk, and then examine it to see what exported functions it has (say, with
Dependency Walker). This should settle the question
Yes, I do.
Sent from my T-Mobile 4G LTE Device
Original message
From: Pavan Konduru pavan.kond...@accelrys.com
Date:03/19/2014 7:03 PM (GMT-05:00)
To: General discussion about the WiX toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] uI on silent uninstall
That's probably because the MSI is running in the just-a-progress-bar mode
during uninstall. MSI message boxes are being suppressed.
On 19 March 2014 22:56, Pavan Konduru pavan.kond...@accelrys.com wrote:
Did you declare the custom action in the .wxs file?
-Original Message-
From:
Yes. I know that some of the Microsoft installers also throw a UI during the
uninstall form the control panel so there has to be a way to override the
/qn..arghh!
Thanks
Woody
-Original Message-
From: Pavan Konduru [mailto:pavan.kond...@accelrys.com]
Sent: Wednesday, March 19, 2014
Do an uninstall on sql server and you get a full Ui with a warning message, etc
etc, so there is a way around it, I just need to figure it out.
-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: Wednesday, March 19, 2014 4:12 PM
To: General discussion about the
That's not an MSI. That's a bootstrapper. That's why (I think it was) Jacob
suggested using a Bundle. Then you get full control over the UI.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
Ahh ok...
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Wednesday, March 19, 2014 4:29 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] uI on silent uninstall
That's not an MSI. That's a bootstrapper. That's why (I think it was) Jacob
I know that Heat is included in 3.8. What I'm saying is the integration of
it with Visual Studio 2013 is not there.
I can't simple put a:
ComponentGroupRef Id=Product.Generated /
in my wxs and have all the projects in the solution harvested
automatically. Unless I missing something. It was a
John,
I did not clear out my temp directories. I assumed everything it built
would be underneath my project. I can try though.
I did export from Orca and used `dumpbin` to view the exported functions.
My newly named method was there.
On Wed, Mar 19, 2014 at 7:09 PM, John Ludlow
Maybe cached MSI?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Levi Wilson [mailto:l...@leviwilson.com]
Sent: Wednesday, March 19, 2014 9:46 PM
To: General
Cached as in c:\Windows\Installer cached? I uninstalled my previous app to
see if a fresh install would do it as well...same problem.
On Thu, Mar 20, 2014 at 12:54 AM, Rob Mensching r...@firegiant.com wrote:
Maybe cached MSI?
___
67 matches
Mail list logo
