I'll see if I can make a simple repro first and try and come up with some
ideas.
dmm - can you raise a defect so this is not lost?
Any thoughts how to fix it? I hope we don't have to do the whole
marshalling to a separate process that DTF does just to handle COM+
registration. That will be
Thanks for the answer.
I have already enabled the .NET framework in the Management Console.
Regards Michael
Date: Thu, 21 Mar 2013 16:19:12 +
From: Pally Sandher pally.sand...@iesve.com
Subject: Re: [WiX-users] wix v3.7 on win2008r2
To: General discussion for Windows Installer XML toolset.
Hi!
I try to implement major upgrade and find some issue:
Msi code has some action, wich write Property value to the registry:
RegistryKey Root=HKLM Key=[UninstallKey][BUNDLEGUID]
ForceCreateOnInstall=yes ForceDeleteOnUninstall=yes
RegistryValue Id=WriteSomeValue Name=ValueName
My COM+ experience is 10 years old but here's something I'm wondering:
I wonder if what ever classes that are in System.Enterprise.Services ( or
whatever that namespace is that was thrown around ) are really needed?
Maybe those are just wrappers in .NET for the COMAdmin objects just like
You'll need this:
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
That is a really dangerous design, by the way.
On Fri, Mar 22, 2013 at 4:26 AM, AK kisslo...@gmail.com wrote:
Hi!
I try to implement major upgrade and find some issue:
Msi code has some
What do you mean, unneeded code for installing Windows services? What if the
service is written in .net? Then the code is needed.
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Friday, March 22, 2013 9:24 AM
To: General discussion for Windows Installer
I am building an installer for a product that uses WCF and needs an
exception added to the Windows firewall.
Unfortunately, I have been unable to get a FirewallException element to work
for me. I found this solution at
Hi everyone,
I'm getting the hang of Util:EventSource, and I realized our original plan was
to have several of our applications (which are all of a kind - they are a
bunch of collection instruments which are from the perspective of installation
more or less identical) share a source. If one
On 22/03/2013 11:26, AK wrote:
Is some way available to pass some custom arguments to obsoleted msi?
One possible hack is to schedule RemoveExistingProducts after
InstallExecute and to add an empty component with the same Guid as the
existing one. That way, Windows Installer won't remove the
I'm referring to the ServiceInstaller class
(http://msdn.microsoft.com/en-us/library/system.serviceprocess.serviceinstal
ler.aspx) and I assure you it is not needed. The only class needed
(unless you want to rewrite all this yourself) for a service that is
written in .NET is ServiceBase
If you look at the built MSI, you'll see EventSource is just some syntactic
sugar to express simple registry keys/values.Create a component in a
fragment / wix library and mark it as shared. Then do a ComponentRef in your
various installers and they will all share that component. Last
This isn't much to go on. Can you show us the FirewallException and related
tags you're using, so we might see what could be wrong?
Alain
-Original Message-
From: John Lalande [mailto:j...@psrm.ca]
Sent: March 22, 2013 11:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
Classification: Public
Hey John,
This works for me:
Component Id=cmpCreateFireWall Guid={some GUID} KeyPath=yes
!-- Add port to firewall --
firewall:FirewallException Id=ManagementFirewallPort
Port=[MANAGEMENTSERVICEPORTNUM] IgnoreFailure=yes Name=MYCORP Service
Port
Hello,
I'm pretty new to WiX. I've looked all over for some definitive answer but
have not found resolution to my issue, so I'm bringing it to this list.
I have a Bundle and a MBA written in WPF. The bundle contains two packages,
both packages are MSI compiled from other WiX Product
I'm very new to WiX and have inherited an existing project. I've been
deciphering it fine except for a few things. In this project I have the
following element:
Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show
The question with this is the NOT Installed condition. What exactly
As far as I understand it, Installed means, Before this installer was run, a
version of this program was already installed on
this machine. Someone please correct me if that isn't quite true.
As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet.
Alain
-Original
Huh, I just noticed that my explanation directly contradicts the behaviour
you're seeing, so...either I'm wrong, or there might be
something flaky going on in your installer.
Alain
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: March 22, 2013 11:43
To: 'General
ForceAbsent allows you to remove permanent packages. However, Burn will
ignore your Bundle's request to remove a package if another Bundle has a
reference count on the package. You'll see a statement in the bundle log
file to that effect.
On Fri, Mar 22, 2013 at 8:26 AM, Doug Beard
Remember, WiX is just an authoring tool for Windows Installer databases.
For the underlying knowledge, please see:
Conditional Syntax Statement (Windows)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012%28v=vs.85%2
9.aspx
Installed property (Windows)
Answers are in the following two links:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx
On Fri, Mar 22, 2013 at 8:44 AM, Alain Forget afor...@cmu.edu wrote:
Huh, I just noticed that
Please don't mark things permanent that are part of your application. Have
your application clean up correctly. The only time you should think about
leaving stuff is for user generated data (including user settings).
On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.comwrote:
Classification: Public
NOT Installed means this product is not on the machine Installed means the
product has been installed
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: March-22-13 11:44 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re:
It means an MSI sharing this ProductCode ( either this PackageCode which
would indicate a maintenance transaction or another PackageCode which would
indicate a small or minor update ) is already installed. In the case of a
Major Upgrade the ProductCode has been changed and therefore from
Hi Rob,
Do you have any advice on my question per se, then? Should the developers just
use a separate source for each of these very similar applications?
Troubleshooters will often want to see them all at once, and not have to go
back and forth between different names and things. But I do see
Dangit Chris, beat me to it :)
Switch on verbose logging (http://support.microsoft.com/kb/314852),
and look for something like this:
MSI (c) (14:28) [11:56:32:469]: Doing action: FindRelatedProducts
Action 11:56:32: FindRelatedProducts. Searching for related applications
Action start 11:56:32:
If you want to share the event sources, put them in a single
Component (probably with the resource .dll) and give the Component a Guid.
Now the event sources and .dll will be correctly reference counted by the
Windows Installer no matter how many MSIs share it. You could go as far as
to put the
PS: there was a discussion about this on wix-devs. To support instance
transforms in Burn, more code would need to be added to Burn. It just isn't
supported today. Someone else said, instance transforms are more trouble
than they are worth, and I tended to agree. smile/
On Thu, Mar 14, 2013 at
So what property is it actually checking to see if it's installed? On my
product element there is a Version attribute and there is an UpgradeCode
attribute, are these what are being used?
Again I have already installed the product and when I run the installer again
(with the Version attribute
Yes, the Installed property means this ProductCode is installed. If you
see that Welcome dialog again the most obvious thing to check is whether the
ProductCode has changed. The idea is that you only see the Welcome dialog on
fresh first time install. Later actions based on the same ProductCode
Ah, the other explanation is that you installed that MSI in a per User
context, and now you're installing it a different user context (another user
or per System).
Phil
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Friday, March 22, 2013 9:51 AM
To: 'General
That's not the case. I'm installing it on the same machine logged in as the
same user. I guess my question is, what is the ProductCode, where is it set?
Here's my Product element, what should be changed so that it knows that this an
upgrade to a product that is already installed?
My thought here is that there is user data. There are going to be a bunch of
event log entries written to a log by an application and there's going to be an
event source associated with them.
No? In general I agree with you but what are your thoughts with this exact
scenario?
That would probably explain it as well.
By default, I believe WiX will use a property called
WIX_UPGRADE_DETECTED. Again, remember that WiX is just a way of
creating MSI files, so that MajorUpgrade element creates entries in
the Upgrade table in the install. One of the columns in this table
Product Id=* generates a new product code each time you build.
-Original Message-
From: Ackerman, Buddy [mailto:backer...@tnsi.com]
Sent: 22 March 2013 17:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about conditional statements in
My thinking: If the application is removed, the archived event log entries
aren't interesting any longer.
On Fri, Mar 22, 2013 at 10:02 AM, Christopher Painter chr...@iswix.comwrote:
My thought here is that there is user data. There are going to be a bunch
of event log entries written to a
...And that's not necessarily a bad thing, since major upgrades work
just fine for most scenarios. However, you probably need to include a
check against your upgrade property (which, if you're just using
MajorUpgrade, is probably WIX_UPGRADE_DETECTED).
On 22 March 2013 17:12, David Watson
The answer is, it depends. I worked on some very large products that had a
lot of code reuse and sometimes the asset that had the logging dependency
wanted the event source to be named a certain thing regardless of what product
it shipped with and other assets wanted the event source to be
Possibly. I work in enterprise IT these days so I can imagine the operations
guys might be interested in certain scenarios.
From: Rob Mensching r...@robmensching.com
Sent: Friday, March 22, 2013 12:22 PM
To: Christopher Painter chr...@iswix.com, General
Hi Alain,
In general, Product ID=* is a good thing. Each new build should generate a
new product code because it typically means you've made changes to the product
(i.e. made a new version). If you want to test the Maintenance dialog then run
the same MSI (without rebuilding it!) twice.
When
Running Wix 3.7, I have a feature with several ComponentGroupRef's:
Feature Id=, Title=, Level=1
ComponentGroupRef Id=one /
ComponentGroupRef Id=two /
...
ComponentGroupRef Id=xxx /
ComponentGroupRef Id=yyy /
/Feature
I need to yyy to execute after xxx because of a dependency (it needs
Running Wix 3.6.1922, I have a Setup.exe that's a custom managed boostrapper
application. When I execute, I see two or three instances of Setup.exe in the
Task Manager. Problem is, when the Setup.exe terminates (normally or
abnormally), it almost always leaves an instance of Setup.exe still
With Wix 3.6.1922, I manually add the WixToolPath, WixTargetsPath and
WixTaskPath to my .wixproj file. If I use absolute paths, there's never any
problem. However, due to build servers not having Wix installed, I must use
relative paths, and that's where I run into all kinds of problems,
I have a similar situation where I am building two different WIX burn chainers
(long story, has to do with .Net versions). In any case I was running into
similar issues with the paths. I ended up creating an environment variable for
my Wix 3.6 binaries path and inserting that in my WIX files
Neil Sleightholm wrote
I'll see if I can make a simple repro first and try and come up with some
ideas.
dmm - can you raise a defect so this is not lost?
Thanks Neil!
I believe there are already a couple of bug reports / fix requests for this
but I will double-check and enter one if my
Thanks for the help, I ended up splitting them into different features and
now I can install on older versions of XP.
Sarvesh
On 3/18/13 7:21 PM, Rob Mensching r...@robmensching.com wrote:
VS2012 Ultimate shipped with 130 packages. smile/
On Mon, Mar 18, 2013 at 5:59 PM, Hoover, Jacob
Hi,
I have a custom managed bootstrapped that works fine when .net 3.5 is
installed. When testing the scenario where .net 3.5 is not installed burn fails
to install the .net redistributable (local redistributable install). It is is
the first item in the chain
BootstrapperApplicationRef
Hi all,
Struggled with this one for the last few hours and finally found what I'd
like to think is just a work-around. What I'm trying to do is add a node
to an xml config during install using Node=document and then CDATA to add
the whole xml element. One of the attributes is just set to a
Hello,
I have an installer version 1.0.0 released as per-user installation, and in
version 2.0.0(and after) I need to do per-machine installation.
When doing upgrade from 1.0.0 to 2.0.0 installation, it has problems that
the previous one cannot be uninstalled.
Finally I find msi cannot support
Order of Components matters none. Order of actions is defined by the
Sequences.
On Fri, Mar 22, 2013 at 11:20 AM, George Fleming gef...@microsoft.comwrote:
Running Wix 3.7, I have a feature with several ComponentGroupRef's:
Feature Id=, Title=, Level=1
ComponentGroupRef Id=one /
Uhh, that is a very old build of WiX v3.6. You're probably hitting some
ancient bug that we fixed in the year+ after that build was made available.
smile/
On Fri, Mar 22, 2013 at 11:24 AM, George Fleming gef...@microsoft.comwrote:
Running Wix 3.6.1922, I have a Setup.exe that's a custom
You probably need:
WixVariable Id=WixMbaPrereqPackageId Value=Netfx35 /
To tell the prereq BA to install that package when NETFX is missing.
Also, you probabl want to remove your InstallCondition.
On Fri, Mar 22, 2013 at 2:37 PM, Chinnappa, Sarvesh [Audatex - Americas]
51 matches
Mail list logo
