Hi All
I have an installer, which is working perfect ; if any of the folders
are open on uninstall , is there any way to notify user about the
open folders , as it may cause a faulty uninstallation ?
Thanks
ArunK
-
Please don't double post. I saw this question yesterday...
Quoting "Arun Krishnan [ NeSTIT]" :
> Hi All
>
>
>
> I have an installer, which is working perfect ; if any of the folders
> are open on uninstall , is there any way to notify user about the
> open folders , as it may cause a faulty
My understanding was, you can read the ProductVersion of each MSI of a
bootstrapper in the event:
DetectPackageBegin(object sender, DetectPackageBeginEventArgs e)
or in the event
DetectPackageCompleted(object sender, DetectPackageCompleteEventArgs e)
something like: e.ProductVersion
but I c
Hi,
Has anyone used one of the new EV Authenticode certificates to sign MSIs and
bundles?
If so have you had any issues with it so far?
Also is it possible to export the public key into a cer file from the hardware
token to allow you to embed it in an MSI to do UAC-less patches?
Cheers
Dave
You have to get use the PackageID to get that information from the
BootstrapperApplicationData.xml file. Note that it wasn't available until
WiX 3.9.421. C# code is at http://stackoverflow.com/questions/12846421.
On Wed, May 28, 2014 at 10:41 AM, Ingo Fischer
wrote:
> My understanding was, you
We've run into this issue in which it appears as though our .sln builds
correctly when built through VS (Votive installed), but when built using
MSBuild, the WiX project dependencies appear to be ignored. This results
in a build order problem (csproj is built _after_ wixproj that needs its
output)
With the proviso that WiX is installed on all of my build servers:
1) I use express references to projects containing assemblies that the wixproj
will consume in the wixproj
2) I use Votive macros to layout the paths to all of my assemblies. I never
attempt to guess where the assembly will be
Schedule RemoveExistingProducts very very early?
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Jesper Alf Dam [mailto:j...@medical-insight.com]
Sent: Monday, May
Sounds a lot like:
http://blogs.msdn.com/b/msbuild/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Me
IIRC, I don't think that's going to work out well. You can try but I think
patching across directory moves probably doesn't work out great since IIRC
moving Component directories during repair doesn't tend to work out real well
either. But that's just from memory...
I think C# projects do the same thing.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, May 23, 2014 8:20 A
You should change the component code if the destination of the component
changes, as documented here:
http://msdn.microsoft.com/en-us/library/aa367849(v=vs.85).aspx
Changing the component code is incompatible with minor/small updates; since
you're talking about a patch and a major upgrade patch is
It might not be a common practice, but I faced it due to some customer
requirement when we have to move a dll to another location. So ethically,
it should be a Major Upgrade which would handle it with no problem. But I
was asked to build a patch, as it is just one dll,
So we build a new dll with a
13 matches
Mail list logo
