Oops :)
When doing a major upgrade on Vista without any service pack the VC merge
modules are uninstalled (in RemoveExistingProject) and not replaced by the
new package.
This only happens on Vista (no sp) all other OS it works as expected.
-Original Message-
From: Jeremy Farrell
On Tue, 19 Apr 2011 09:53:41 -0700
Thai-Hoa Nguyen taiwa...@hotmail.com wrote:
I'm looking for a way to create a SSL certificate during install
time. I don't think makecert.exe is allowed to distribute. Please
give me your suggestions.
Could you use openssl to generate the certificates
Thanks Mahesh.
After creating 2 MSIs I verified it through ORCA. The component GUIDs
are same in the Component table. There is no difference.
But when I viewed a patch over the first MSI(open first MSI in ORCA,
then select Transform- View Patch), It shows lot of difference in
Component table.
If you update to Windows Installer 4.5 is the same behaviour observed?
Why are you testing on Vista without any Service Packs installed anyway?
There's a reason why Microsoft issue service packs for operating systems, this
is one of them.
Palbinder SandherÂ
Software Deployment Engineer
T: +44
Is the component table shows new component (that is ok)? But if it shows change
in component GUID, or Removed Components then the patch will not work.
Possible problem:
Make sure that the file fragments are only updated when you create the second
MSI. If you create(not update) the fragment
Hi, I modified the custom actions from the original MSI so that during patch
install, those CAs can correct something that I missed in the original MSI.
The conditions I modified (I added AND NOT PATCH AND NOT MSIPATCHREMOVE )
are something like:
BEFORE (i.e. in the original MSI):
You're right, the original custom action and condition are run at patch
uninstall because the patch package is not applied to the MSI when the patch
is being uninstalled.
http://msdn.microsoft.com/en-us/library/aa370739%28v=vs.85%29.aspx
If the original MSI has already been released it looks like
Wow. Thank you VERY MUCH for the lightening fast answer, Peter!!!
Can you elaborate issue a patch that fits earlier into the sequence first
please?
--
View this message in context:
I have tried the recipe described here:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2011/02/23/web-application-installer-in-wix.aspx
But somehow it either doesn't work, or I have messed things up.
My IIS 6 setup:
Default Web Site (listening to port 81)
test (listening to port 82)
I've never done it but I think it's possible by creating a patch with an
earlier patch sequence number than the patch you're fixing (in the same
family). However, if you've superseded all earlier patches in the latest one,
I don't think it'll work. You'll have to experiment or ask someone more
Hi All
I'm trying to build a simple installer but I'm getting the following error:
The Component element contains an unhandled extension element
'util:EventSource'. Please ensure that the extension for elements in the '
http://schemas.microsoft.com/wix/UtilExtension ' namespace has been
Hi Guys,
I've been writing a custom-action for detecting if a given feature is installed
on the machine. If I use it as an executable, it is fine:
Binary Id=CheckWindowsFeatureInstalledCustomAction
Hi,
I think DTF custom actions always need a Session object as parameter.With the
session object you can get installer properties.
Here is a example of a working C# CustomAction.
[CustomAction]public static ActionResult ConnectDb(Session session){string
test = session[property];}
Binary
Did you create a full DTF custom action project or just add the
references/attribute to a normal c# one?
A DTF custom action dll has the c# dll embedded in it as a resource with a
manifest file...
Dave
-Original Message-
From: Dick Van den Brink [mailto:d_vandenbr...@live.com]
Sent: 20
I've created a custom action project (in vs2008) from the project template
custom action project from the category Windows Installer XML.
All the class/method has is the following:
using Microsoft.Deployment.WindowsInstaller;
namespace CheckWindowsFeatureEnabled
{
public class
Hi,
That's great - but how have you injected the value of session[property]?
Many thanks,
J.
-Original Message-
From: Dick Van den Brink [mailto:d_vandenbr...@live.com]
Sent: 20 April 2011 15:24
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# CustomAction DLL won't run?
Ignore this one, I was being stupid. :) Still getting the same error message
though (see my other email).
J.
-Original Message-
From: John Thornborrow [mailto:j...@pinesoft.co.uk]
Sent: 20 April 2011 15:45
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# CustomAction DLL
Your code seems to be ok, what does it say in an install log?
Are you sure you are adding the
CheckWindowsFeatureInstalledCustomAction.CA.dll to the project and not the
CheckWindowsFeatureInstalledCustomAction.dll?
Also I don't see where you schedule your custom action, I assume though that
you
I just discovered that I was not referencing the *.CA.dll (was writing this
email just as you replied), and that has solved it.
Thanks a lot for the help. :)
J.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 20 April 2011 17:18
To: wix-users@lists.sourceforge.net
Hi,
I have been trying to roll a few msps together into an installation bundle
and I am getting some odd errors.
I am using wix 3.6.1615.
If I use the unmodified WixStandardBootstrapperApplication.RtfLicense and
build and click through to the install i get the following errors in the log
and my
20 matches
Mail list logo
