I use:
Date: Sat, 27 Jun 2015 21:00:50 -0700
From: ml-node+s687559n7600730...@n2.nabble.com
To: nickra...@hotmail.com
Subject: Re: Bootstrapping SQL Server 2012 Express
Nick Ramirez wrote
Finally got it to work, after installing .NET Framework 4. I guess the SQL
Server installer
e from the book or try running
your arguments directly against the SQL Server executable. That may give you
better error output. Also, there may be a log of the install in the temp
directory.
Nick
Date: Sat, 27 Jun 2015 03:01:55 -0700
From: ml-node+s687559n7600728...@n2.nabble.com
To: nickra...@h
fails-td7590635.html#a7590638
I've picked up the development build and ran with the -xn switch, which fixes
up the custom action issue, but I am still left with the merge module one.
Is there a way around this?
Lux, as I understand it, tests that a property has a particular value after a
custom action has run.
As far as a robust test, this is pretty weak. Setting a property is just a
small part of the install process. But the sum total of an installation is
to put files on the system, configure the regis
I tried something similar and it compiled okay for me.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0091-Duplicate-symbol-error-tp7598838p7598856.html
Sent from the wix-users mailing list archive at Nabble.com.
-
Thanks for the fantastic detailed clarification on this issue! I will endeavour
to use the melt approach outlined in Bob's post.
-Nick
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
Gi
Sounds like undocumented functionality of Melt. I don't see anything about
using it that way in the WiX.chm.
Also, binder variable don't solve the problem of binding the source files
into the XML file. They only give you a way to list a bunch of paths to
probe. So they don't replace the functiona
Bind paths vs. Visual Studio project references (e.g.
$(var.MyProject.TargetDir))...the latter doesn't require passing custom
parameters to light. Why make the specifying of a source file more arcane
with a bind paths binder variable? Especially when the use case is a patch
file in the unseen futur
Ouch. So now you have to keep your old and new source files on hand. Would be
nice to keep the bind-files option or work it into the wixpdb. Also, not
being able to bind the files into the wixout or wixpdb means that if you
move the wixout/wixpdb and then try to run Pyro against it, all the paths
a
if this is the best approach. Should
I just use the wixpdb approach instead?
Regards
Nick
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership wit
I forgot about it, but you may have to publish the AddLocal event. I guess
it's been a little while since I thought about it, because I can't remember
if you can add/remove features with a feature condition outside of the
feature tree or if you have to use the AddLocal event (published by the
"Next
Components can also be included in more than one feature. Could you add
subfeatures under your codec features?
- Feature: “Core files” (required)
--- Subfeature: “Codec A” (optional)
-- Subfeature: “Windows Explorer integration” (optional)
--- Subfeature: “Codec B” (optional)
-- Subf
Okay, so it sounds like you want to:
1. Install the file to the Documents folder
2. Edit the file in place after it's been installed
I've often seen people posting about having problems using XmlFile. I have
always used the XmlConfig element instead and haven't had any problems. You
might get les
/1) First try - I have installed the file on the Document's folder and the
modified it with the wix extension XmlFile.this work for coping the file but
fail to modify it as reported the error that it can't find the file to
modify/
Some questions I have:
1. What error are you seeing?
2. What are y
WiX doesn't have a UI control that will show files in a file-explorer window.
You'll probably have to write a custom action that opens one.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/File-explorer-dialog-tp7598706p7598708.html
Sent from the wi
You cannot check whether a condition or feature is going to be installed in a
feature or component condition, since costing hasn't taken place yet.
Maybe you have a very special use-case, but in most cases, you've likely got
your features badly organized. With more information, we may be able to
s
I saw this and thought I'd pass it along. Books on the Packt Publishers
website are $5 until Jan 6. Includes the WiX book and the pre-release of the
new WiX Cookbook.
www.packtpub.com/all/?search=wix
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.c
Shouldn't need CreateFolder either.
Can you use a Property to store the password? Put the Hidden attribute on
it. I'd check the log after that to make sure it's hidden.
I am assuming the the IisExtension hides its custom action data already
(CustomAction/@HideTarget).
--
View this message in
The "personal" store is available at localmachine too. Go to:
Run -> mmc -> File -> Add/remove snap-in -> Certificates -> Add...
You'll see the option for "Computer account" and that's analogous to WiX's
localmachine. It has a "personal" and "root" (aka Trusted Root Certification
Authorities).
I thought it worked for me before too. But trying it again, it only
associated the certificate with the Web site after I'd added a
CertificateRef inside the WebSite.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Iis-Schema-Usage-tp7598329p7598673
Does /-ext WixUtilExtension/ work?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/XmlFile-or-XmlConfig-in-patch-msp-tp7598517p7598616.html
Sent from the wix-users mailing list archive at Nabble.com.
---
Should you do this at all? Run a configuration script after the installation?
In most cases, you shouldn't. It should be part of the install. Collect all
the data you need for the configuration during the UI portion of the install
and then use that data in deferred custom actions during the execute
What your WiX mark-up for the file look like?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE60-during-install-of-ttf-file-to-private-folder-tp7598542p7598557.html
Sent from the wix-users mailing list archive at Nabble.com.
---
Are you handling the ResolveSource event? See:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-4-pre-req-in-WixNetFxExtension-td7579058.html#a7579356
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Bootstrapper-download-an
Take a look at
http://msdn.microsoft.com/en-us/library/aa370739%28v=vs.85%29.aspx where it
says:
/The Custom Action Patch Uninstall option is not available. There is no
method for marking a custom action within a patch package to be run when the
patch is uninstalled because the installer does not
What do your calls to torch.exe and pryo.exe look like? Do they include the
-ext flag for the UtilExtension?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/XmlFile-or-XmlConfig-in-patch-msp-tp7598517p7598549.html
Sent from the wix-users mailing li
You'll want to make sure that your CA is scheduled during
InstallExecuteSequence and is "deferred". Then, set the CustomActionData for
that CA, passing it your ENV property that way.
However, since you're updating an XML file, then the UtilExtension has XML
elements (XmlConfig) to do that, so you
You said that you wanted this to work through automation when deployed to
various machines. Having a message might not be necessary, if, using a
feature condition, you never allow the installer to get into a bad state in
the first place.
Allowing a user (or automated process) to choose a possibly
It looks like what you have is correct. You have a SAME_VERSION property.
Although you might want to set OnlyDetect to yes if you want to keep the
existing product there and not overwrite it.
Then, use a launch condition to stop the new installation from going through
if SAME_VERSION is found. The
Use a feature condition. A feature condition is where a Condition element is
placed inside a Feature element. There, it can change whether or not that
feature gets installed depending on if the statements evaluates to true.
It does this by changing the Level of the Feature:
If S
According to the documentation for the Requires elements
(http://wixtoolset.org/documentation/manual/v3/xsd/dependency/requires.html),
it can be put inside of a Product element.
I am wondering if that's a feature that hasn't been implemented yet. What
I'm saying is, it sounds like the WiX team wou
I was just thinking about this: What's the best practice for a custom action
that has a problem?
* Catch all exceptions and return ActionResult.Failure
* Allow the exception to be thrown?
Maybe ActionResult.Failure should be used for non-exception failed states?
Such as the user entered someth
A bootstrapper is just a list of install packages that are installed one
after the other. So, if you had three install packages in the bootstrapper,
you wouldn't have one install directory, you would have three. For example,
if you bootstrapped SQL Server, the .NET framework and then your
applicati
This probably isn't going to be helpful because I'm not that well-versed with
using Group Policy. But when I tried it once, the program ended up on a
different screen that regular programs. I had to go to *Control Panel ->
Programs and Features -> Install a program from the network*.
I base this
I would only suggest uninstalling WiX and reinstalling. For me, when I do
Ctrl + SPACE, I get a list of WiX elements. I clicked just underneath the
Package element in the Product.wxs file and did Ctrl + SPACE.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.n
You're overthinking it. You can set up your Directory elements for whatever
directory structure you need and wherever the user changes INSTALLFOLDER to
be, its child Directory elements will follow it there. For example, if the
user changes the path of INSTALLFOLDER to C:\MyStuff, they'll get:
C:/
To bind the certificate to the Web site, you can do something like:
That should go into the same Component as your Certificate elements. That
should be enough to do the binding.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Iis-Schema-Usag
WiX has a Group element in the Util Extension that can find an existing
Windows group, but can't create one of any kind. Its User element can create
a user, but I'm not sure if it works with AD. It has a Domain attribute, but
that may only be for referencing an existing AD account.
--
View this
You don't need to put an Id attribute on the Fragment, it won't be used.
The Id attributes of Directory elements are themselves, properties. You can
see the full path to your install directory be looking at the value of the
property called INSTALLDIR. You can see it in the MSI log:
msiexec /i myi
How come you're using mst files for localization and not .wxl files that are
built into WiX?
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/
Do you mean, create a file share?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Create-network-folder-tp7598287p7598356.html
Sent from the wix-users mailing list archive at Nabble.com.
If you want to install only for the current user, you should install to the
LocalAppDataFolder instead of ProgramFilesFolder. ProgramFilesFolder
requires elevated privileges since it's a machine-level folder.
LocalAppDataFolder is for current-user-only installs (Package/@InstallScope
= perUser)
Try posting this on the wix-devs forum.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Latest-build-wix-3-10-visual-studio-2013-problem-tp7598342p7598353.html
Sent from the wix-users mailing list archive at Nabble.com.
---
Nope. Installing the WiX Toolset should get you all set up with VS 2013. No
other setup is required. I've tried it several times and it works for me.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Intellisense-in-Visual-Studio-2013-for-Wix-3-8-tp7
Is the install log showing anything helpful? You say it's a permissions
issue.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-DirectX9-Components-within-a-perUser-MSI-tp7597763p7597775.html
Sent from the wix-users mailing list archive a
Not sure. Now that you've moved code into a wixlib, any UIRef elements left
hanging around still pointing to the old UI? It's probably something simple
that I'm not thinking of.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FW-Correct-method-fo
Is SQL Server already set up? When you set it up you can enable Windows
authentication at that point. Otherwise, you'd have to turn it on somehow
during your installation, but could be trickier.
Are you installing SQL Server along with your website install? If so, turn
Windows authentication on th
The NetFxExtension always downloads it. To have the .NET 4.5.1 package
compressed inside your bundle, you would have to write the mark-up yourself.
You can use how the WiX team did it as a rough guide:
http://wix.codeplex.com/SourceControl/latest#src/ext/NetFxExtension/wixlib/NetFx451.wxs
omittin
Hmm...
Just to double-check:
Copied the Fragment contents of WixUI_Advanced.wxs to be local to
my installer project. Saved in separate wxs file
2. Renamed the UI, made the modifications I needed
--->* Did you change the Id on the UI element?*
3. Copied the InstallScopeDlg.wx
I didn't read carefully enough. You only want to display the message on
uninstall. Because ARP suppresses the UI, the dialog won't be shown on
uninstall.
I was so close to having this work by simply adding something like that to
Burn's License UI theme. Alas, even though, with Burn, that Exit dia
I don't think the Exit dialog is going to be shown, in most cases, during an
uninstall because Add/Remove Programs (Programs and Features) suppresses the
UI when the user uninstalls from there. So, setting the property directly
may be enough.
I can't recall of the top of my head what that property
Did you update your UIRef element to point to your new UI_Custom?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FW-Correct-method-for-modifying-a-built-in-UI-tp7597759p7597765.html
Sent from the wix-users mailing list archive at Nabble.com.
What are you wanting to uninstall? Is it an upgrade scenario? Are you trying
to replace an older version of your software with a newer version?
Or are you trying to remove some other software when yours is installed?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687
Thank Rob. Now I've tried the following:
However, the database is still removed during an uninstall-rollback. The log
indicates that the rollback of the SqlDatabase element happens after the
rollback of the SqlString:
Executing op: CustomActionSchedule(Action=RollbackExecuteSqlStrings ...
E
This may be a weird case, but here goes...
I have the following SqlDatabase element, from the SqlExtension:
Steps I took:
1. Install the MSI --> database is created
2. Open an elevated command prompt
3. Uninstall using WIXFAILWHENDEFERRED=1:
msiexec /x MyInstaller.msi WIXFAILWHENDEFERRED=1
Thanks Jacob, that sounds like really good work on your part. I will follow
the link to learn more about it, and it will be nice to eventually see that
in the standard BA.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-state-of-Update-Location
Can anyone say what the current state of the Update element that goes into a
Bundle is?
http://wixtoolset.org/documentation/manual/v3/xsd/wix/update.html
Does it work, currently, with the standard BA? Or would someone have to
write their own to take advantage of detecting an updating MSI package
Jeremiahf wrote
> Sorry, Thought you were trying to remove the user from the group on
> uninstall.
Yep. That's what I'm trying to do. The LocalGroupMember element from the
Community MSI Extensions does what I need. Not sure whether I should say
it's a bug in the Util extension that it lacks this f
No need to make my own custom action. I've found that the WiX extension from
the Community MSI Extensions project has an element for adding an existing
user to a group that works for me.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/On-uninstall-
I was afraid that setting RemoveOnUninstall to "yes" or not putting it there
at all would have the effect of removing the existing user from the system.
Thankfully, that does not happen. However, it also doesn't affect the user's
group membership. The user is left unchanged after uninstall, still
b
I have the following markup to add an existing user to a group:
When I run this installer, the existing user is updated so that it is now a
member of the Administrators group. However, on uninstall, the m
Thanks Rob. For me, this is a thought experiment in which I was trying to
learn more about rollback CAs. So, my scenario is (similar to editing an XML
file with XmlFile), I wanted to install a JSON file and edit it at
install-time. If the installation failed, I would rollback the file to what
it wa
I wasn't able to find a way to pass data from a deferred CA to a rollback CA.
Nor could I access the session's database, which prevented me from storing
the data in a custom table.
The only way I found that worked was to store the original file in the TEMP
directory and, in the rollback, restore t
The result returned by a rollback CA can be Success or Failure. But should
that response be ignored by the installer? If I check it, and it is a
Failure, will that prevent the installer from rolling back?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble
In a deferred custom action, I am changing some text in a file. I want to be
able to undo those changes in a rollback custom action. So, I'm attempting
to store the original contents of the file and then set the file back to
that data in the rollback CA.
The place where I've tried to store the ori
A very old post, but in case anyone was wondering, to get the Change
permission on a file share, use the following properties on
FileSharePermission:
GenericWrite="yes"
Traverse="yes"
Delete="yes"
GenericRead="yes"
--
View this message in context:
http://windows-installer-xml-wix-toolset.6
I tried it again tonight and it's working just fine. The WIX variable is
there. I'm not sure what happened before. But I won't worry about it. I had
installed Visual Studio Express just before installing WiX (knowing that it
doesn't work on Express, but wanting to make sure that it /still /doesn't
After installing WiX 3.8 on Windows 8.1, I saw that the system environment
variable WIX, which is normally installed as part of the install (and still
is on Windows 7), isn't set. Has anyone noticed this?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble
Well then that is weird then because when I look at the Digital Signatures
tab of the MSI, it says it's been signed by Oracle America, Inc. and that
"This digital signature is OK". Maybe Windows 8.1 has a different way of
seeing things. Or maybe it couldn't find its certificate chain. But I guess
s
When installing the MySQL Installer MSI (it's an MSI that's trying to be a
bootstrapper, but that's not the big problem at the moment with it). I'm
getting the following errors:
Failed authenticode verification of payload:
C:\Users\Nicholas\AppData\Local\Package
Cache\.unverified\mysql_installer_c
Ah, I found it and it was a simple solution. I was missing the Win64
attribute on RegistrySearch, since the value is stored in the 64-bit part of
the registry.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Root-ignored-by-util-RegistrySearch-in-B
I am seeing the same behavior as reported in bug 4231
(http://wixtoolset.org/issues/4231/), using WiX 3.8. The Root element of
RegistrySearch is ignored. I have:
And in the uninstall log, where it should detect SQL Server, it doesn't, so
SQL Server is not removed.
Okay, I was wrong! I guess by setting only Read permission on the folder
(using Read, GenericRead, and ReadPermission -- not sure yet which one is
the magic one), the user is able to read the files in that folder and cannot
change/modify them. I guess it works even though the checkboxes for Read an
The util:FileSharePermission element has many attributes for setting ACLs on
a file share, but none of them seem to work except for GenericAll. For
example, the following code will not give the user the specified
permissions:
I am install
The original version was 6.0.0.0 and the new one was 6.0.0.1
Sent with AquaMail for Android
http://www.aqua-mail.com
On July 7, 2014 11:13:07 AM John Cooper wrote:
> Well, the log indicates that Burn is uninstalling. What are the version
> numbers for the initial and upgrade installs?
>
> --
This .wxl file is an oddball, being the only one that I see that uses these
UI elements to resize controls from a localization file. Bob Arnson wrote a
blog about it here:
http://www.joyofsetup.com/2012/07/14/localizing-more-than-strings-in-wix-v3-6/
And the bug that led to adding the UI element
I don't understand. The $(var.MyProject.TargetMachine) is only used while
compiling the installer and not while using the installer. After compiling
the solution you should get one MSI file. You only need to deploy the MSI
file to the machine where you want to install.
--
View this message in co
For code suggestions, you can post to the wix-devs mailing list.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594616.html
Sent from the wix-users mailing list archive at Nabble.co
Is it getting hung up on something? When you uninstall with logging, does the
log show anything happening that takes a long time around where it calls
RemoveFiles?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RemoveFolderEx-really-slow-on-large-
As far as I know, a transform file is a file used during the patch-making
process, but can't be used directly to perform a transform. It needs to be
joined with a patch file. The patch file has the knowledge of what the
transform applies to. Without it, I don't think Windows would know what to
do w
Can you show what markup you're using now? That would make it easier to
troubleshoot.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Permission-PermissionEx-Append-tp7594590p7594613.html
Sent from the wix-users mailing list archive at Nabble.com.
So the components in FeatureC can be installed as a standalone feature, but
those same components are needed by Features A and B?
I'd just include the components in all three features. And don't nest
Feature C inside Feature A or B.
--
View this message in context:
http://windows-installer-xml
This is just a guess: when you referenced one component, you created a link
between the fragment and the main project. Now the linker will yell at you
if it finds anything orphaned in that fragment. On the other hand, when you
didn't link anything from the fragment to the project, the linker didn't
You can use a VolumeSelectCombo UI control.
1
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Drive-selection-tp7594443p7594537.html
Sent from the wix-users mailing list archive at Nabble.com.
---
Sorry, but I'm going to ask a few followup questions:
1. Does your custom action alter the user's computer at all?
2. I see the name "NewServerInstance". Is this by any chance creating a
website in IIS?
3. Is it necessary to create a custom table over using properties?
--
View this message
Upgrades are used to find and replace previously installed files. But if
there's nothing to replace, there's nothing to say the install can't
continue as a fresh install. If you need to not run the installer at all if
a previous install isn't there then try using a launch condition
(http://wixtools
Is your installer installing at least one thing, such as a dummy text file?
The install won't run otherwise.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Noob-creating-a-Custom-Action-in-Wix-3-8-tp7593140p7593249.html
Sent from the wix-users mai
Are you wanting to create a major upgrade scenario /just /to change the value
of that property? If so, that's not necessary. You can dynamically update
the property's value at install time, based on data your customers enter
into the installer's UI or enter on the command line to run the installer.
I wonder if the UpgradeCode on the bundle isn't being set properly. Does
hardcoding it for the time being help?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bootstrapper-is-not-removing-older-version-from-Control-Panel-Uninstall-Program-tp75
Ah, I was reading your code wrong. I was seeing an == when you have a != when
checking the .NET Framework Package ID. Well, in any case, it's clearly not
detecting your previous install. I'm not too sure what that could be other
than that the UpgradeCode on the bundle needs to stay the same. Are yo
Maybe try adding another if statement where you detect a package with
PackageId of "MyApplication1"
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bootstrapper-is-not-removing-older-version-from-Control-Panel-Uninstall-Program-tp7593116p759320
Doesn't appear to be detecting your previous install:
[186C:1C04][2014-03-07T14:57:34]i101: Detected package: MyApplication1,
state: Absent, cached: None
[186C:1C04][2014-03-07T14:57:34]i101: Detected package: MyApplication2,
state: Absent, cached: None
It says that its current state is "Absent
It's a WiX thing, but a good thing. By adding a reference to the build DLL,
you get the following added in the setup project's wixproj file:
AwesomeExtension.dll
AwesomeExtension
Adding the project itself does not add this. Adding a project has uses for
/other/ things.
Hmm, I don't recall having to do anything special in the custom bootstrapper
to handle what gets displayed in Add/Remove Programs. I mean, you have to
implement handlers for the Detec, Plan, Apply events...but if you're
successfully installing and uninstalling you must be doing that. I think the
pr
Eh, you don't have to copy it there. For me, I just don't like Browse-ing
very far. So I put it somewhere I want. You can browse to wherever you would
like to store your assembly.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Noob-creating-a-Cust
You'll need to create all the dialogs you need, and then show them
dyanmically. You can put the logic for which to show in the "Next" button of
your dialog (using the NewDialog event with conditional logic). This logic
can evaluate properties that you've set with a radio button.
--
View this mes
I think that's how it work unless you update the Version attribute on the
Bundle element and also the Version attribute on the Product element in the
MSI.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bootstrapper-is-not-removing-older-versio
Welcome! New user of Burn. Eh, I'm not sure that there's a command line that
you can use to bundle everything up. But the markup for Burn can be written
pretty quickly. So I guess it's more in line with how installer in WiX work
-- it's XML based instead of command-line based.
If you post the code
If I'm understanding correctly, you're referring to that you see Visual
Studio calling candle and light when it compiles your WiX setup project?
At that time, it's calling those tools on your setup project, but your
custom extension project has already been compiled. By adding a reference to
it
Changing ProductCode and Version, but keeping UpgradeCode the same denotes a
major upgrade of the same product.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-an-MSI-twice-tp7593163p7593173.html
Sent from the wix-users mailing list archive
1 - 100 of 479 matches
Mail list logo
