Thanks for help from Peter, Rob Hamflett and Rob Mensching!
I have achieved detecting the process with "WixCloseApplications" and
killing the process by "taskkill".
But I still have an issue that when I try to uninstall it pops "FileInUse"
dialog. But the application it indicates has no relationsh
I'm using an external UI to chain several msi files together. I have an
ExternalUIHandler that is part of a WPF MVVM wizard application. Most of the
msi files are 32bit ("Intel" platform) but one of them is a 64 bit ("x64"
platform, let's call it "my-x64.msi") that contains both 32-bit and 64-
I thought you might say that. It's one of those "leap of faith" things.
Go to Start | Run and type in C:\Windows\Installer and hit Enter. It
should open the folder.
-Original Message-
From: CoolBreeze [mailto:coolbreeze...@googlemail.com]
Sent: Thursday, March 31, 2011 2:08 PM
To: General
Personally I wouldn't use Windows Installer for this. If you want some
code to do this without Windows Installer there is an example here:
http://neilsleightholm.blogspot.com/2008/08/report-loader-for-sql-server
-reporting.html
Neil
-Original Message-
From: Sean Farrow [mailto:sean.far...
Thanks for the suggestion. I'm on XP, so I don't know if that matters or
not, but I don't have an Installer folder anywhere under my C:\Windows
folder.
On Thu, Mar 31, 2011 at 4:59 PM, Chad Petersen
wrote:
> Oh, and an easy way to see what each MSI was used for is to open the
> C:\Windows\Install
Oh, and an easy way to see what each MSI was used for is to open the
C:\Windows\Installer folder in Explorer and add the Subject column to
the details. I can immediately see what each MSI belongs to. Quite
informative.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.
If it was pre-installed perhaps the MSI is cached and you could inspect
it using Orca or similar tool. Normally in C:\Windows\Installer. Just a
thought. A combination of the date/time stamp of when it was installed
and/or the Properties of the MSI in that folder and looking at the
Summary tab will
I don't have one because it is not a part of my installer. It was
pre-installed and I don't have the .msi for that specific version of csla.
On Thu, Mar 31, 2011 at 10:14 AM, Rob Mensching wrote:
> ComponentSearches are a little weird because you need to make sure the
> search Type matches the C
Thanks for your suggestion Christian.
I followed your adive but looks like my CA is not getting called at all. I
checked the verbose log and there is no entry of my CA.
Following is how I have defined and sequenced my custom action.
SOLUTIONEXISTS = notexists
NOT Installed
NOT In
Thank you I will try this.
Two questions. What is the 'verbosity' needed to show a 'light' stack trace?
What is the difference between output verbosity and log file verbosity?
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Orig
Thanks so much Peter.
Your suggestion works like a charm.
Regards
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-check-for-Acrobat-reader-tp6223495p6227952.html
Sent from the wix-users mailing list archive at Nabble.com.
Hello,
I have a solution in Visual Studio with several Merge and Setup WiX projects. I
want to have a single localization file for all of these projects so that I can
keep track of the localization strings easier.
I have achieved this to some extend. I have created a WiX library project which
Oh, and look in the Output pane for the Build output. It will show you more
information than the Error List pane.
Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
I'm using Visual Studio 2010. Your mileage may vary with other versions of
Visual Studio.
1. Click the Tools menu
2. Select the Options... menu item
3. Expand the Projects and Solutions category in the left pane
4. Select the Build and Run option
The right side of the Options dialog should now c
I have TWO ca which are executed when the user clicks the Finished button on
the last page of the dialog
However the ca always seems to execute as the elevated user and to be
ignoring the impersonate attribute.
How can I execute them as the original user?
-
I issue the build from Visual Studio and it is undoubtedly calling MSBuild
under the covers but I am not sure how to coerce Visual Studio to give up more
information than the information about the exception. Also it doesn't happen
all the time. I could get this exception with Visual Studio and t
WiX v3.5 also shipped with the RestartApplication element that allows you to
add more files to the Restart Manager (which gives the user the option to
shut things down).
On Thu, Mar 31, 2011 at 2:12 AM, Peter Shirtcliffe wrote:
> Agreed, it doesn't look like it can kill them forcibly but there is
ComponentSearches are a little weird because you need to make sure the
search Type matches the Component's KeyPath. What's the KeyPath in the
target MSI?
On Tue, Mar 29, 2011 at 1:08 PM, CoolBreeze wrote:
> Thanks for everyone's help. I still haven't resolved why this is not
> working
> for me af
(why do people always jump to assuming it's a bug first? )
Your Property and IniFileSearch are in a Fragment that is never referenced.
You need to reference the content in there. Give the example, I would add a
PropertyRef under the Product element somewhere to the Property for the
IniFileSearch.
Which version of WiX v3.5? We didn't start dropping .pdbs until WiX v3.6.
However, actually, I don't think we need them. Is there more information
available about the crash? There should be a callstack. If you're running
from MSBuild, turn logging on, the stack trace should be in there.
On Thu, Ma
OK. You meant .pdb's. Is there a distribution of those or do I need to build
WiX from source?
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesd
I am using 3.5. Where is the .pbs? I was not able to find a file with that
suffix in the installation directory.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.c
The condition element is in this context used to show the message and stop
the installation if the condition is false. In other words it is a condition
that must be fulfilled to to start the installation.
The condition you have does the opposite, it shows the message if the DB
doesn't exist. Inste
You could use a custom action to generate such a string out of the
property PrimaryVolumeSpaceRequired.
2011/3/31 Pally Sandher :
> MSDN appears to say you can't. See
> http://msdn.microsoft.com/en-gb/library/aa368608.aspx
>
> Palbinder Sandher
> Software Deployment Engineer
> T: +44 (0) 141 945
MSDN appears to say you can't. See
http://msdn.microsoft.com/en-gb/library/aa368608.aspx
Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Re
Agreed, it doesn't look like it can kill them forcibly but there is an option
to set a property when it can't so that the installer can abort or prompt the
user if the application doesn't close. It depends on whether the user is in
danger of losing any work if you terminate the process. There is st
Can CloseApplication kill processes though? It doesn't look like it can. If
you need to forcibly
kill something you might need a custom action to run taskkill or some custom
code that does the job.
Rob
On 31/03/2011 09:45, Peter Shirtcliffe wrote:
> Look at the CloseApplication element in th
Look at the CloseApplication element in the util schema in the Wix
documentation.
-Original Message-
From: lxy.su...@gmail.com [mailto:lxy.su...@gmail.com]
Sent: 31 March 2011 09:40
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [Wix-users] How can I kill p
Hi all
How can I achieve killing the process with the given name when uninstall my
application. Is there something that Wix can support that feature?
Thanks!
--
天行健,君子以自强不息
--
Create and publish websites with WebMatri
If you need to see if the user can read a PDF file, rather than detect the
Acrobat reader application specifically, why not test for the file
association so that *any* PDF reader will satisfy the check (I much prefer an
alternative PDF reader myself).
The keys to test for would be HKLM\Software\Cla
30 matches
Mail list logo