Hi,
currently I'm updating all of our Visual Studio 2010 projects and choosed Wix
to support Visual Studio 2012.
Now all installers are running with Wix and are doing their job fine in Testing
environment.
Our AQ Department asked me to implement Updates as well.
One of our custom Installer
Many thanks darbid, yes i have had option 2 up and running but for other
reasons needed to go with option 1 and had hoped I could remove the dialog.
On Mon, Apr 14, 2014 at 2:53 AM, darbid davidbo...@gmx.de wrote:
I have read that if you want to add a certificate to the current users
store
Hi All,
Do we create an MSI package without installing WIX toolset in target
machine?
Any help on this?
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph
Suppose 4 users needs to create MSI package on their machines. Everyone
should install WIX toolset to create MSI package. So, for time being is it
possible to create MSI package without installing WIX toolset?
On Thu, Mar 13, 2014 at 6:15 PM, Verbuk, Artem artem.ver...@intel.comwrote:
Ok,
Classification: Public
Dileep,
You can install only what is required to build WIX MSI's
I presume you want to build the MSI's and not create the MSI's?
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html
Steve
-Original Message-
From: Dileep S
For generating MSI package using WIX, which are required things to install
from WIX Toolset?
On Tue, Apr 15, 2014 at 5:31 PM, Steven Ogilvie steven.ogil...@titus.comwrote:
Classification: Public
Dileep,
You can install only what is required to build WIX MSI's
I presume you want to build
Classification: Public
Read the link I sent you... it explains what you must do
-Original Message-
From: Dileep S [mailto:dileep.sanamp...@gmail.com]
Sent: April-15-14 8:20 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Create MSI package with out installing Wix
Hi Jamie,
The major upgrade section should have been present in the older product too for
the current installer to upgrade it.
--Pavan
-Original Message-
From: Jamie Hankins [mailto:jamiehank...@hotmail.com]
Sent: Monday, April 14, 2014 8:57 PM
To: wix-users@lists.sourceforge.net
I would like to thank Phil (and others on this list) for the assistance in
tracking down this problem. The core problem is related to the following
attempt to write this registry value when the value of the SDA property is
not an integer:
RegistryValue Root=HKMU Key=$(var.Release_CompanyRegKey)
Did you uninstall wix toolset and reinstall it after VS2013 was installed. I
have read other posts to the effect that just doing a repair is not
sufficient to detect a new version of VS on a system.
--
View this message in context:
Chris,
This looks like a bad design choice in the previous version. Most of the
time, you're going to want to embed your custom action DLL as a Binary in
the MSI package rather than installing it on the target machine as a File in
a Component. I.e., put the custom action DLL on a Binary rather
Hello All,
I have a service that is dependent on a DLL that gets installed from within
the same MSI. This DLL gets registered with the GAC on install.
My service hangs on install. If I modify my install not the start the
service on installation through service control, and manually start
What kind of custom action was that in the original VS 2010 setup
project? If it was managed code, VS 2010 inserts a C++ Dll to load a
framework and run your code via reflection. If so, you'd need to
migrate that to a DTF custom action. You should also check that there
isn't already a custom
Small correction: I meant to say, we are going to ... create a dummy
installer whose sole purpose is ... to prevent [the custom action DLL] from
being removed when you UNINSTALL the first product. I.e., to make sure
that it is still around when the post-RemoveFiles custom action tries to use
it.
If you've got a major upgrade element in your new product it should
work. It's not clear to me what those strange errors are around the
REP area in the log. I've never seen anything like that. It might be
the kind of error you get when your ProductCodes or UpgradeCodes are
not all uppercase, or
From http://msdn.microsoft.com/en-us/library/aa371634.aspx
Note: Services that rely on the presence of an assembly in the Global
Assembly Cache (GAC) cannot be installed or started using the ServiceInstall
and ServiceControl tables. If you need to start a service that depends on an
assembly in
Hi Mike
Thanks for the input... I'll change my approach... I had seen a post from
Rob that dated a few years ago, I was hoping this had changed...
Thanks for your time,
Marc
-Original Message-
From: Michael Turner [mailto:mcturner...@gmail.com]
Sent: April-15-2014 2:58 PM
To:
Hi,
Thx for the answer. The uninstallation of the previous Version is working fine.
The error is ocuring only during Upgrade within the wix installer.
The strange thing the CustomAction.dll is searched within the default targetdir
of the wix installer and Not within the targetdir of the
Back tracking a Bit to help Phil Decode those error massages in his
earlier response. Sorry if you feel barged in on Phil :)
2205: Database: [2]. Table does not exist: [3].
2228: Database: [2]. Unknown table '[3]' in SQL query: [4].
Taken from:
It was a c# Custom Action.
This Custom Action is Not deployed within the new wix installer because it is
Not needed any more.
Am 15.04.2014 um 20:45 schrieb Phil Wilson phildgwil...@gmail.com:
What kind of custom action was that in the original VS 2010 setup
project? If it was managed
Uma,
Apologies for the delayed response. If you haven't figured it out already,
you only need to remove the parent 'SnippetDir' node, and all of its
children will be removed with it. However, you will need to be clever with
your XPath to make sure you select the correct 'SnippetDir' node for
Arg, yes, I'd forgotten about that whole set of weird errors in the
error table :)
---
Phil Wilson
On Tue, Apr 15, 2014 at 12:32 PM, Carter Young ecyo...@grandecom.net wrote:
Back tracking a Bit to help Phil Decode those error massages in his
earlier response. Sorry if you feel
Chris,
Is your new version a Major Upgrade
(http://msdn.microsoft.com/en-US/library/aa369786.aspx), as opposed to a
Small Update or Minor Upgrade
(http://msdn.microsoft.com/en-us/library/aa370579.aspx)? Also, if it is a
Major Upgrade, then when is your RemoveExistingProducts action scheduled?
We have some components that are the same file names but different DLLs.
For the sake of the example, let's say they're x86 vs. x64 versions of a
file. Here is what the feature looks like:
Feature Id=ServicesFeature
Feature Id=PrintServiceFeature
ComponentGroupRef Id=PrintComponents /
Hi Phil,
Here are the FindRelatedProducts log entries. I don't see much.First:MSI (c)
(38:DC) [20:24:29:864]: Doing action: FindRelatedProductsMSI (c) (38:DC)
[20:24:29:864]: Note: 1: 2205 2: 3: ActionText Action 20:24:29:
FindRelatedProducts. Searching for related applicationsAction start
Hi Pavan,
The MajorUpgrade element is new, so I don't believe that it is required in the
old version for an upgrade. According to what I've read, it's just a simpler
way of creating an Upgrade element.
My understanding is that the only thing in the previous version that should be
required is
Some confusion here - the original post referred to the failure of a
custom action because the Dll was missing, but is this now the custom
action you don't need, according to your earlier post? If the Dll is
called InstallUtilLib.dll than that's the Visual Studio Dll.
I was pointing out that
As I understand it component conditions are only evaluated the first time the
component is installed. If you want them to be evaluated again later they
need to be marked as transitive.
--
View this message in context:
There is an option you might want to try but it isn't very pretty, schedule a
call to net start servicename after the GAC install.
As someone else said it is better to remove the GAC dependency but I think it
should work.
Neil
-Original Message-
From: Marc Beaudry
The old installer was an Visual Studio Installation Project.
The Old Version Number was 5.015.004 with an Different guid. So the wix
installer is Doing a Major Upgrade.
During the installation of the new Version the uninstallation of the Old
Version is scheduled.
During the uninstallation an
Hi Jamie,
Yes, I was trying to ask if there was any major upgrade code implemented in the
previous installer.
-Original Message-
From: Jamie Hankins [mailto:jamiehank...@hotmail.com]
Sent: Tuesday, April 15, 2014 1:21 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
Hmmm, it does not seem to be changing the file. Would Bob's comment have
anything to do with it I wonder?
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-installation-status-not-affected-by-condition-tp5562579p5572902.html
On Tue, Apr 15, 2014 at 4:33 PM, Phill Hogland
Dileep,
Theoretically, there are other ways to utilize the WiX Toolset without
formally installing it on a machine, but none of them work very well with
Visual Studio Integration. If you're using Visual Studio Integration and
you only need to work with one version of the WiX Toolset at a time,
Yes, I suspect Bob has explained it.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Modify-Components-w-Conditionals-tp7594143p7594155.html
Sent from the wix-users mailing list archive at Nabble.com.
Chris,
Well, it looks like you've found a workaround for now: just uninstall the
old version before installing the new one. It isn't pretty, but it seems to
be working for you. Sometimes, that's just what you have to do when you're
migrating from one toolset to another.
But if you want to
All..we seem to have quite a conundrum.
We have a custom WiX MSI that incorporates several C# custom actions. We
have deployed the MSI to our end users via MS SCCM. Everything seemed to
work fine with no problems.
The next week we release an update and go to apply the MSP to our already
Yes. Thanks for asking.
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Tuesday, April 15, 2014 12:39 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix 3.8 Heat.exe error against VS2013 Toolset
Did you uninstall wix toolset and reinstall it
Are you using elevated InstallPrivileges and PerMachine in your package ID?
InstallPrivileges=elevated
InstallScope=perMachine/
Also,
Did you set any components in your original installer to PatchIgnore=yes?
I haven't necessarily done patches but I do set
Oh and see if you can enable verbose logging through SCCM to see what else
may be going on.
/l*v logname.log
On Tue, Apr 15, 2014 at 5:55 PM, Jeremiahf jeremi...@gmail.com wrote:
Are you using elevated InstallPrivileges and PerMachine in your package ID?
InstallPrivileges=elevated
My plan is to run verbose logging tomorrowby design of the application we
must use per user installation so our scope is per user and we haven't tried
elevating the rights level because it always worked in test doing the manual
install without elevating to admin.
The weird thing is that when
The SCCM actions may be doing something with the installer policy on
the client machines. This kind of thing:
http://support.microsoft.com/kb/227181
and things like the AlwaysInstallElevated policy that allows MSI
installs to be pushed to limited users who would otherwise not be able
to install
41 matches
Mail list logo
