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 t
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 w
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 wrote:
> Are you using elevated InstallPrivileges and PerMachine in your package ID?
>
> InstallPrivileges="elevated"
> Ins
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
Instal
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 af
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
i
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 keep
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.
--
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, th
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 w
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] WiX-
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 e
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 [mailto:mbeau...@ma
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:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Modify-Compone
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 mana
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 th
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 20:
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:
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 schedule
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 wrote:
> Back tracking a Bit to help Phil Decode those "error massages" in his
> earlier response. Sorry if you feel barged in on Phil :
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 rem
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" :
>
> What kind of custom action was that in the original VS 2010 setup
> project? If it was managed code, VS 2010 insert
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: http://msdn.microsoft.com/en-us/library/aa37283
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 already
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: wix-users
>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 t
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 the
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
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 actio
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
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 t
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:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/
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:
It was introduced several weeks ago when I changed how t
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
Subje
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
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 wrote:
> 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
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 [mailto:dileep.san
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 wrote:
> Ok, let's try to clarify the
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 databas
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 wrote:
> I have read that if you want to add a certificate to the current users
> store
> then you need th
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 has
41 matches
Mail list logo
