Just so I'm sure I follow exactly, can you provide snippet of example code that
demonstrates the issue?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Bruce Cran
Hi,
I created one installer for web application using harvesting method.
installer gets created successfully and I installed it. It created directory
and app pool without any error. but while running website I got to know some
dll files are missing but those files are actually in solution
Hi,
I have created a WIX installer project and able to build and install with
create database and IIS everything works fine. But while try to uninstall
the application from add/remove program it is not removing the IIS web site,
Application pool and SQL Database.
Please guide me to delete
Hi Jacob,
thanks for the links.
So, i cloned your repo. After a lot of fiddling, I was able to compile
wixstdba. Then I copied the generated files to the installation folder
of the 3.9 RC:
* BootstrapperCore.dll
* ManageBundleRunner.dll
* WixStdBA.dll
I wanted to compile more, but there are
I have this working but I don't like my solution.
I have a perMachine install in which I ALWAY need to create 1 shortcut.
Optionally, I need to create a 2nd shortcut on the desktop (all users). My
component definitions look something like this...Is there a better way to
do this?
Component
In your Bundle.wxa, do you have your Update Location= / in place?
I wouldn't have copied the generated files. Easiest way to do a one off
WixStdBA mod that I found was to use
!-- The following props are needed to build the bundle based off of a
local Wix build --
I use something like this (without the condition, but that could be added, in
which case I would also make the component transitive):
Fragment
Component Id=myShortcut Directory=aDirId
Shortcut Id=myShortcut Target=[DirId]file.ext
Directory=MyMenuFolder Name=Name WorkingDirectory=DirId
But for perMachine installation, isn't HKCU wrong?, it kinda works though.
On Fri, Oct 31, 2014 at 3:37 PM, Phill Hogland phogl...@rimage.com wrote:
I use something like this (without the condition, but that could be added,
in
which case I would also make the component transitive):
When a file association is created, and the app is installed properly, in the
case of the Open verb, when a user double clicks on a file with that
extension, the shell launches the registered application and opens the file.
If the file association is advertised, and the application is not
No. It smells wrong but that is what you need to do for a per-machine
installation.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/perMachine-optional-shortcut-creation-tp7597616p7597621.html
Sent from the wix-users mailing list archive at
DesktopFolder is a per-user location.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, October 31, 2014 7:53 AM
To:
Hello,
I am new to WIX, and I am using the wix toolset visual studio extension
(3.8).
I created a new Wix Setup Project I added a reference from the Wix setup
project to another project within my solution CrmAdo
All i want to do is on installation, install the CrmAdo.dll to the GAC and
then on
I believe there are several complaints about it, because if one admin installs
the package, another could uninstall it and leave those entries stranded in the
other users hive.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html
-Original
What is the name of the alluser desktopfolder then?, when I do this, I wrap
it into an directory-element, which contains an component, and then the
shortcut, and the shortcut it self goes to the alluser desktop because
perMachine is set.
If the registryvalue which is required for removing it, is
From log:
Action 15:44:19: MsiUnpublishAssemblies. Unpublishing assembly information
MSI (s) (E4:38) [15:44:19:981]: Executing op:
Am I missing something here?
I have installed my product with version 14.8.6.x.
Each build the GUID is changed, i.e.: ?define ProductCode = *?
The UpgradeCode is not changed, i.e.: “?define UpgradeCode =
2E416B87-7FB9-4A28-9A7E-?”
The bundle.wxs has:
Bundle Name=$(var.ProductName)
You're not wrong. It's just the way the Windows Installer handles multiple
users logging into the same machine with Active Directory. It feels antiquated
but it is how the Windows Installer works.
_
Short replies here. Complete
So the logs look good then? Would the logs show if the call to
AssemblyUnpublish failed to remove it for any reason? Because I am starting
with a clean slate every time i.e I'm using gacutil to ensure it isn't
present in the gac, then run the install and verify that gacutil.exe /l
crmado shows its
According to http://msdn.microsoft.com/en-us/library/aa368276(v=vs.85).aspx
The installer sets the *DesktopFolder* property to the full path of the
current user's Desktop folder. If an All Users profile exists and the
*ALLUSERS* http://msdn.microsoft.com/en-us/library/aa367559(v=vs.85).aspx
On 10/31/2014 12:11 AM, Rob Mensching wrote:
Just so I'm sure I follow exactly, can you provide snippet of example code
that demonstrates the issue?
Chain
MsiPackage Id=Win7_driver
ForcePerMachine=yes
SourceFile=Win7\driver.msi
Correct but Windows Installer sill treats that like a user folder, which is the
root of the requirement for an per-user key path.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
A possible workaround would be to provide a MsiPackage/@Name putting them in
different directories in the layout. Ie:
Chain
MsiPackage Id=Win7_driver
ForcePerMachine=yes
SourceFile=Win7\driver.msi
Name=Win7\driver.msi
Yup, that's what I did - I could also have changed source or destination
filenames.
--
Bruce
On 10/31/2014 11:28 AM, Hoover, Jacob wrote:
A possible workaround would be to provide a MsiPackage/@Name putting them in
different directories in the layout. Ie:
Chain
MsiPackage
Could you file a bug to say that there should be an error message too?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk]
Sent: Friday,
I did a little more research into this observation (that using -dcl:none and
-dcl:high (or low, or no switch) all produces the exact same size output
files (msi and related external cab files)). Since these experments were in
part prompted by reading Bob's blog and the dev's discussions
The MSI/Fusion interface is very sensitive to the assembly
description. If the attributes that end up in the MsiAssemblyName
table don't exactly match the actual assembly then it won't uninstall.
---
Phil Wilson
On Fri, Oct 31, 2014 at 8:32 AM, Darrell Tunnell
On 10/31/2014 11:55 AM, Rob Mensching wrote:
Could you file a bug to say that there should be an error message too?
Done: http://wixtoolset.org/issues/4574/ .
--
Bruce
--
Based on the following document (and probably other pots to the forum, long
ago) I had implemented cab reuse.
http://wixtoolset.org/documentation/manual/v3/howtos/general/optimizing_builds.html
The cause of the problem detailed in this thread is that I had defined a
single cab cache path without
WiX v3.9 released
Friday, October 31, 2014
The production/stable release of WiX v3.9 has been released. You can
download it from here http://wixtoolset.org/releases/v3.9/stable. Read
more about the release at Rob's blog
29 matches
Mail list logo
