The MSI file replacement process says that if a non-versioned file has been
modified since installation (even if it was the installer that modified it)
then it will not be overwritten on upgrade. See
http://msdn.microsoft.com/en-us/library/aa370532(VS.85).aspx
Did you try that before writing
Sounds a lot like this -
http://sourceforge.net/tracker/index.php?func=detailaid=3131700group_i
d=105970atid=642714
Try using XMLConfig instead as suggested on that bug report see if it
fixes it for you.
Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945
Error Code 2228 is according to MSDN Database: [2]. Unknown table
'[3]' in SQL query: [4]. -
http://msdn.microsoft.com/en-us/library/aa372835.aspx
The only difference I can see between your PathEdit control the one in
the WiX UI source for InstallDirDlg is the WiX UI source has
Indirect=yes. I
According to my Google this has been discussed on the list many times.
Set the Control's Property to whatever you specify in CheckBoxValue to
check it, set it to {} to uncheck it.
Perhaps try Bing next time if Google is failing you.
Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141
I don't use Burn but I would check why it's using the path
\.\Packages\X.msi as the Note: 1: 1324 2: . 3: 1 in the log refers
to an invalid character . in a path that's the only path I can see
in your log which has a . in it it appears to start rolling back
right after that.
Palbinder Sandher
@WyrdFish,
Thanks for the reply.
As MSI won't rewrite the unversioned file if it is modified, I have taken
the following approach as a workaround. During install, my custom action
writes some valus to web.config. During upgrade, installer wouldn't replace
this web.config file as it is
Seems eminently possible using ServiceInstall if you use one Component
with one File as the KeyPath multiple ServiceInstall elements. However
if your Services need to be in separate Components then I think you'll
need to use Custom Actions.
Unfortunately Windows Installer is the weak link here
You could simply avoid creating duplicate entries by using appropriate
Conditions thus neatly side-stepping the whole, move replace procedure
which appears to be the root of your problem.
Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
Initially I tried making that component that writes to the web.config file
conditional, so that it gets executed only during install but not during
upgrade or removal. But that condition failed. I have used *Not Installed*
property to make this component conditional.
So i don't have a choice
You do have a choice. dblock has already done the hard work of writing
appropriate Conditions for you -
http://code.dblock.org/ShowPost.aspx?id=101
You can use those Properties in your Conditions thus you no longer
need Custom Actions to work around something which doesn't need a work
around.
After some googling, the schema appears to live in wix.xsd.
On my machine this is installed to C:\Program Files\Windows Installer XML
v3.5\doc\wix.xsd
which is identical to what's in
YourVisualStudioInstallDirectory\Xml\Schemas\wix.xsd
Eric Teutsch
Mon, 20 Jun 2011 11:07:02 -0700
Hi, I have to
Yes, the Class element would handle the first couple registry keys.We don't
have elements for the extra Shell folder stuff today though so given how
much registry there is specific to shell-goo, you might be best off with the
registry elements. smile/
A WiX extension that handled the Shell
Correct, that's one of the big features that Burn brings in WiX v3.6.
On Thu, Jun 23, 2011 at 7:34 AM, ColinBowern co...@bowern.com wrote:
@Palbinder - I am looking specifically how to inject custom controls - not
change the order of the UI or modify the dialog layout itself. Any of the
Yeah, VS and MSBuild and Votive conspire in evil ways to prevent the value
from coming back in a way that you can edit. You can actually get into this
same situation with C# projects.
You have to edit the .wixproj (or .csproj is you mess up your C# project,
like I did once) to fix it.
On Tue,
It seems like Wine hasn't implemented the MsiGenerateTransform() function.
Without that Torch isn't going to be much use to you.
The WiX toolset works (or at least it did work a couple years ago, I haven't
checked in a while) on Mono but you need the MSI API implemented so that
means Windows or
WebSite/CertificateRef then a Certificate element, IIRC. It was a long time
ago that I dealt with certificates and web sites...
On Tue, Jun 28, 2011 at 8:36 AM, Ryan Scott rsc...@computerlabsolutions.com
wrote:
Joe, I'm trying to do something similar. Did you have any luck figuring
this
one
Hi,
I need a way decide the registry path to write to based on the OS
architecture the installer is installing on.
E.g:
If OS is x64 bit
create a registry key under HKLM\SOFTWARE\WoW6432Node\MyCompany
otherwise write to
create a registry key under HKLM\SOFTWARE\MyCompany
To achieve this, I
DirectoryRef Id=INSTALLLOCATION
Component Id=WebSiteComponent Guid= KeyPath=yes
Win64=yes
iis:WebAppPool Id=MyAppPoolID Name=My Application Pool
ManagedRuntimeVersion=v4.0 ManagedPipelineMode=integrated /
iis:Certificate Id=SslCertificate
Hey all. This is a combination batch/MSBuild and WiX question:
I have a .wxs that builds a .MSI with the output from a console app.
I now need to build the same MSI 3 times, changing some parts of the .wxs and
some parts of the .exe.config for the console app (the console app does not
need
I've got a wix installer that installs a backend service and a front end to
control the backend service.
The Admin front end is being placed in one directory and the service is being
placed in another directory. They have a few dlls that I would like to share
between them.
My plan is to
We place some of our shared files in C:\Program Files\Common Files\our
company name
-Original Message-
From: Robert Hermann [mailto:rob.herm...@nicewareintl.com]
Sent: Tuesday, June 28, 2011 1:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How do you
Oh, and there is a known property called CommonFilesFolder as documented
here.
http://msdn.microsoft.com/en-us/library/aa367994%28VS.85%29.aspx
So, makes it real easy to use.
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, June 28, 2011 1:46
Here is the situation:
I am creating a Burn bootstrapper to install my app (an MSI) and its
prerequisites. One of the prereqs is SQL Server 2008. One of SQL Server's
prereqs is Windows Installer 4.5.
Unsurprisingly, the WI4.5 installer exit code is 0xbc2 REBOOT REQUIRED. Can I
manage
Is there a community location where standard package definitions are publicly
available in one common repository? If not, that would seem like a good idea,
so that each of us individually are not all reinventing the wheel.
For example, I just made a separate post asking about problems I'm
On 28/06/2011 23:08, Dan Puza wrote:
For example, I just made a separate post asking about problems I'm having
bootstrapping Windows Installer 4.5 and SQL Server 2008. I wouldn't wish the
trial and error pain and time on anybody duplicating the same effort. That
doesn't seem like it
I have a set of SQL Scripts that run and create tables, stored procedures,
and populates a couple of the created tables. We are only doing
MajorUpgrades with our installer. Is there a way that when it comes time to
run a Major Upgrade that I can prevent the SQL Scripts from running again? I
want
Hi
What I have done, is to have two components for the Database, one is
conditioned to be installed if it is a clean install (not a major upgrade) and
the other is installed on the major upgrade, not on clean install. The initial
table creation script is against the first component, but not
That sounds like a good idea. Thanks I'll look at updating my installer.
On Tue, Jun 28, 2011 at 9:58 PM, Michael Osmond mosm...@baytech.com.auwrote:
Hi
What I have done, is to have two components for the Database, one is
conditioned to be installed if it is a clean install (not a major
28 matches
Mail list logo
