How is the MajorUpgrade element scheduled in your MSI? By default it is
"afterInstallValidate", which does not bring back the old version if there
is a rollback. See the documentation at
http://wix.sourceforge.net/manual-wix3/wix_xsd_majorupgrade.htm.
--
View this message in context:
http://w
I'm still not grasping what's happening. Do I have this right?
* You have a dependency on .NET 4
* You used the WiX .NET extension in your Burn bootstrapper to install .NET
if it isn't already installed
* For the portion of the install (after .NET is installed) that applies to
your own software, y
Burn caches MSIs that are in the bundle in the Package Cache, so having the
original media, I wouldn't /think/ would be a problem. When one MSI in the
bootstrapper chain fails, all preceding MSIs should be rolled back.
--
View this message in context:
http://windows-installer-xml-wix-toolset.68
That makes sense then. I wonder if adding the *-cultures:en-us* flag or
*-cultures:fr-fr* to the Linker tool settings in the bootstrapper's
properties would do the trick?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers
The MajorUpgrade schedule is important for the MSI that failed. If an MSI
will be rolled back, having the original MSI reinstalled is dependent on the
MajorUpgrade element. On the other hand, the first MSI, which installed
fully, will not roll back. At best, when the Chain fails, it will probably
j
In the bootstrapper project's Visual Studio properties, go to Tool Settings
and enter the command-line args into the Linker text box.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers-Duplicated-tp7586776p7586899.html
Se
I think you're right. This other thread seems to agree:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installl-upgrade-several-MSIs-in-one-single-transaction-td7495903.html
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapp
Are you installing some sort of suite of different products? Maybe the
Visible flag on the MsiPackage element will get you closer to what you want.
Or there might be a way to build a custom BA that would present a screen to
remove particular products.
--
View this message in context:
http://wi
Microsoft Office 2007 has a single entry in ARP that can be used to
modify/remove the installed products. I wonder if they are using Burn to do
that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-separate-entries-in-Add-Remove-for-each-M
You should be able to download the example for that chapter at the Packt
publishers (packtpub.com) site. On the page that shows the details about the
book, click the tab that says "Support" and there ought to be a "Code
Downloads" link.
--
View this message in context:
http://windows-installer-
I added an MSI project to check it, and it compiles ok for me. I link the
projects together as:
* The wixlib project needs to pull in the custom actions from the CA
project. Two ways to do that are
1. Use a build events in Visual Studio to copy the CA.dll file to the
wixlib project's directory
Okay, I maybe wasn't fully understanding the problem. :) So, you're saying
that you want to use your extension in another WIXLIB (unrelated to the
WIXLIB you used to build your extension)...but when you try that, but don't
reference the extension in your Setup project too, you get the error "Cannot
I don't think you want that check. You want Burn to register the package for
each bootstrapper that installs it. In other words, you want to install it
everytime, even if it's already installed. Burn should detect that the
package is already installed and just skip over it. That way, when one
bundl
The Property attribute should be the same on both elements. It ties them
together in that way.
According to the MSI documention for the ComboList property:
"If the ComboList Control bit is set on a combo box, the edit field is
replaced by a static text field. This prevents a user from entering a
Are you just starting your journey with WiX? If you are, you might take a
step back from WPF user interfaces for a few days and dig into writing an
MSI file. Once you've got that, I'd read up on how to use Burn by itself,
using the UI that comes with the toolset. Here, I'm talking about just
writin
Things to try:
1. Did you replace/remove the old Publish elements that were directing the
user elsewhere? Looks like in the WixUI_Advanced.wxs, there are there
Publish elements, each taking the user somewhere else depending on a
condition.
2. Does your Publish element have an Order property? If n
Some things to try:
* Is the MSI failing? There ought to be separate MSI log files in the same
directory, so check those for any errors.
* Check the bootstrapper's log file to see how far it gets, may give you a
clue about where it's failing
* If you want to step into your managed BA, put a threa
You might have to save the users's choice (Machine or User) somewhere and
feed it back in as a command line arg upon uninstall.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dual-purpose-package-won-t-uninstall-when-uninstalling-bundle-tp7590376p
It's hard to say what's causing the problem. Can you post the code from your
bundle.wxs file? Maybe the problem is there.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dual-purpose-package-won-t-uninstall-when-uninstalling-bundle-tp7590376p759039
I think the problem is what Jacob said (and what the post said) -- an issue
with choosing perMachine/perUser at runtime. It's what I meant to say, but
had the other things in my head and said that instead accidentally. :)
--
View this message in context:
http://windows-installer-xml-wix-toolset
According to this post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-amp-per-user-or-per-machine-td7579453.html#a7579508
It sounds like Burn may not support a mixed 64/32-bit setup.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.na
You can dynamically set an install directory with the SetDirectory element.
The WebVirtualDir element, in the IIS extension, uses the Directory property
to point to a Directory element. So if you set up your Directory element,
point to it with WebVirtualDir, and use SetDirectory to change its targe
I think the easiest way to use Prism is to pull in the dependency using
NuGet. The command is:
Install-Package Prism
You can download NuGet for Visual Studio 2010. It's an extension to Visual
Studio.
http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c
I think that
You can create a custom bootstrapper application (such as by using WPF) and
have that do just about anything you need. Burn has extension points for
this. Curious, how come the logic needs to live on a website? Did you not
want to base the language off of the user's language settings on their PC?
Hello everyone,
I wonder if anyone can help with this. I'm using the WebAddress element to
set the address for my website:
IP="*"
Port="443"
Header="[ASMX_WEBSITE_DNS_NAME]"
Secure="yes" />
The only problem is that in IIS7, the
Thanks Wyrdfish,
It looks like it is working now -- even though, the asterisk doesn't show up
where the IP would be in the IIS manager. I had been waiting for our systems
guys to create a DNS entry for the website and once I had it, it seems to
work. Must be a false alarm. It is interesting though
In our development environment, we are installing to an existing website
hosted in IIS 7 (Server 2008). However, in our QA environment, we are
installing to an existing site hosted in IIS 6 (Server 2003). I've found
that in IIS 6, the existing website can't be found unless we add the
SiteId="*" att
We've had quite a bit of hands on experience with this sort of thing lately.
In one project, we bound a certificate to a port during the install so that
we could use SSL (the same as if you were to go into IIS and set the binding
and choose a certificate). In another case, we used ws-security in th
I'm not sure if you ever got this figured out. If not, can you show us the
markup for the custom action?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Executing-a-Batch-File-during-Install-tp6579146p6646053.html
Sent from the wix-users mailing list
Could you show the markup you're using for the controls?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-RadioButtonGroup-controls-in-the-same-dialog-tp6644681p6646096.html
Sent from the wix-users mailing list archive at Nabble.com.
---
For sure, I wouldn't mind getting involved in making some sort of extension.
That project doesn't seem to have much activity though.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-https-WCF-Webservices-tp6641855p6648697.html
Sent from th
olSet\services\testsvc
SUCCESS
--
Nick Ramirez
--
View this message in context:
http://n2.nabble.com/MSI-5-0-ServiceConfigFailureActions-fails-during-InstallExecuteSequence-t
s (admins don't get that by default
> IIRC). It's interesting that the failing ones would cause a reboot, and
> that might also be a missing right like SE_SHUTDOWN_NAME.
>
> Phil Wilson
>
> -Original Message-
> From: Nick Ramirez [mailto:nickra...@h
Is this a per-user or per-machine install? The reason I ask is that
sometimes, by not setting the ALLUSERS property to something before you call
FindRelatedProducts, you run into trouble.
Nick Number wrote:
>
> Hello all. I've just joined the list in hopes of solving a specific
> problem.
>
Take a look at the description for ICE30:
http://msdn.microsoft.com/en-us/library/aa368954(VS.85).aspx
What I gather from it (and a preliminary test confirms it) is that if you
have two files being installed to the same directory, then the only way to
avoid an error is to add elements to both c
Have you tried using the fully qualified name for the NetworkService user?
Such as "NT AUTHORITY\NetworkService"?
--
View this message in context:
http://n2.nabble.com/install-service-tp4716985p4718779.html
Sent from the wix-users mailing list archive at Nabble.com.
Are your properties public, meaning are their Ids uppercase? If they're not,
they won't pass from the UI to the Execute phase.
example:
And do you see the property being set in the install log? Like...
MSI (c) (98:F0) [12:04:32:046]: PROPERTY CHANGE: Adding CHECKBOX_PROPERTY
property. Its va
Add the ComboList="yes" attribute to the control. Also, you may want to add
Sorted="yes". Hope that helps.
--
View this message in context:
http://n2.nabble.com/Combobox-Display-Question-Problem-tp4677659p4719093.html
Sent from the wix-users mailing list archive at Nabble.com.
---
I've experimented with this and have found that the symbols really seem to
mean this:
# - Can be any number
& - Can be any letter
? - Can be a number or letter
^ - Can be any letter, but it will always be converted to uppercase
@ - Creates a random number.
< - Beginning of visible part of mask
>
When, during the uninstall process, are you getting the error? Is it
happening during the RemoveFiles action? If so, you might try adding the
Wait="yes" attribute to your ServiceControl so that it waits for it to stop
the service before moving on to remove files. It may be that the SCM is
taking t
In Visual Studio, you can set a Build Order for your projects (assuming that
they're all in the same solution). That way, your custom actions will be
built before your WiX files, assuring you that they're always up to date.
You can't, as far as I know, directly reference a custom action project in
I've seen the same thing. Although in my case I'm just trying to speed up
localization, not make a patch. It seems to be caused by the -bf flag.
Without it (in which case you'll need to make sure that your WixVariables or
-d flags are referencing the bitmaps and icons correctly in relation to the
Hello, I'm trying to figure out what the EndDialog event does when given a
Value of "Retry". According to the Windows Installer documentation, it does:
"The wizard sequence is closed and the control returns to the installer with
the Suspend value."
I have the following control:
1
Clicki
Okay. Maybe the code 1604 isn't so weird. I found another site that said it
means:
"1604 - Installation suspended, incomplete. - ERROR_INSTALL_SUSPEND"
So, then it worked, right? So, then how to I resume it from its suspended
state? If that's what has happened?
--
View this message in context:
Can anyone tell me more about the actions that Light does? For example, does
linking happen before binding? When is the .wixout or .wixpdb file created?
When are unreal tables used and is it okay to drop them with the -dut flag?
We'd like to optimize our calls to Light and any info about the order
We're trying to make it faster. We're currently using a wixout file to get us
halfway through the process. Yet, it still takes a while since we are
localizing for eight languages. Our latest idea is to stop reusing the
wixout in such a synchronous way. By that I mean that we use a batch file
that
Hello,
The Property element's Secure attribute is supposed to be necessary to pass
a property from the UI to the Execute sequence. However, I've never been
able to create a situation where it was necessary. For me, just making the
property uppercase has always done the trick.
I've tried the foll
I needed this specifically to get a
> property from a registry key to pass to a custom action during uninstall.
>
>
> Matt Johnson MCPD, MCTS, MCSD, MCDBA
> Director of Application Development
> Time America, Inc.
> ma...@timeamerica.com | www.timeamerica.com
>
>
>
Okay. It took quite a while to get some results, but I've finally managed to
get the properties to not pass from the UI sequence to the Execute sequence.
The key factor seems to be whether or not you're prompted to elevate your
privileges during the install.
On Vista, you're almost always prompte
How are you scheduling your custom actions in the InstallExecuteSequence
table? With the InstallExecuteSequence element?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Actions-Missing-in-InstallExecuteSequence-tp5039683p5043350.html
Sent fro
You don't need to have an immediate custom action. Here are some pointers.
1. The progress bar appears and is incremented during the deferred stage, so
any custom actions that run during this phase can update the bar. It's nice
to see some text that says what's happning when you control the progr
Is SERVICEACCOUNT a local user, not a domain user? If so, it might help to
prefix it with ".\" to denote that it's a user on the local computer. Also,
local users often don't have the rights to handle services unless the
Interactive attribute on ServiceInstall is set to "no" and Type is
"ownProces
You could get the WixUI_Minimal.wxs file from the WiX source code, save it to
your project under a different name, like "CustomWixUI_Minimal.wxs". Open it
up and change the UI element's Id to "CustomWixUI_Minimal".
Add a UIRef element to your main .wxs file with an Id that matches.
Is it possible that the child process (the batch file) is picking up the same
environment as the MSI (parent process?) and in order for it to pick up the
new environment variable it would have to somehow refresh its environment?
I'm not sure how to do that.
--
View this message in context:
http
Does this thread help?
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-Service-not-removed-on-Uninstall-td710002.html
What is the "Action" of the component with your service, from the uninstall
log?
--
View this message in context:
http://windows-installer-xml-wix-toolset
The action state of a featre is supposedly set after CostFinalize. Trying it
out, it seems that checking the action state in the condition of a
component, as you've done here, evaluates to -1, "unknown".
I would have thought that it would always evaluate to 3, "local", since the
INSTALLLEVEL pro
Okay. I think I understand this a bit more now. I think that the action state
of components and features are figured out during the FileCost phase, but
not set in stone and made available until after CostFinalize. Also, I
believe that conditions on components and features are evaluated at the same
If I understand your question, you want to increment the progress bar for
more than one custom action? You'd just need to reuse the code in those
custom actions too, either by duplicating it or putting it in some central
assembly. If you didn't want to reset the progress bar each time, you could
s
You can remove the Sleep from the example. I used it to show the progress bar
with several pauses. In a real application, your function would call the
"DisplayActionData" function at times when you decide to show a message and
increment the bar. Now that I think about it, my DisplayActionData func
Here's how I understand it:
For an MSI package (unlike an MSM package) you only specify one LCID for the
Package element's Languages attribute. If you omit it, it will be considered
a language neutral package. This is stored in the Template Summary property
of the MSI, which you can see by openin
We've found that if we've already installed our MSI, but then try to install
it again (from the command line) and supply the ADDLOCAL property, it takes
us to the ResumeDlg (this seems to happen for any MSI using a WiX dialog
set). What we really want is for it to take us to the MaintenanceWelcome
I think this:
Installed AND
Preselected
fixed my problem, but I'm still curious about how MaintenanceWelcomeDlg is
included. Anyone know?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-schedule-MaintenanceWelcomeDlg-tp5155582p51557
You probably don't want to use TARGETDIR in this way. TARGETDIR points to the
root directorty (C:\ for example) of where your files will be installed to.
It's not typically where you put components.
See this link about TARGETDIR:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372064(
Seems to be Burn specific and sets a Burn variable while the other
RegistrySearch that's not in the UtilExtension sets a Property.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-RegistrySearch-tp7581620p7581624.html
Sent from the wix-users m
This is not a big issue, really just something I stumbled on and am curious
about. If I use a localization variable in a component's GUID, like this:
/
/
And then add a .wxl file:
/
http://schemas.microsoft.com/wix/2006/localization";>
*{872EAAB7-BDE1-4EF4-89C6-97664705CB0F}*
/
I've notic
Oh, glad I asked then. The way that I've done localizable text in software
has been to use a satellite assembly. In that case, I think that each set of
localized strings gets its own assembly (if I am remembering that
correctly). Maybe best practice is to include all of these assemblies in the
inst
Does the install log show that it is detecting the old version?
At one point I thought that I had to schedule InstallExecute after
RemoveExistingProducts, but last I tried it that didn't seem to be the case.
Is it possible to switch to use the new MajorUpgrade element? It seems to
make life easi
I used to have problems with projects not loading. It seems like it had
something to do with having to copy some Version file or something into
another directory.
I tried the whole thing again and it works for me:
1. Cloned the repository (don't check certificate):
hg clone --verbose --inse
That's the error message you get for pretty much any reason. It's like a
catch-all error message. Try changing the service's account in the services
console and see if it starts. Maybe try to debug into it while it's
starting. I've done that before after putting it to sleep for a few seconds
to giv
Check the %TEMP% directory for the log of the Votive.msi install (which gets
installed by the setup). It will have a long name like:
/WiX_Toolset_v3.6.3303.1_20120915144821_4_votive.msi.log/
It tries to detect VS based on a registry key:
/HKEY_LOCAL_MACHINE32\SOFTWARE\Microsoft\VisualStudio\8.0\
I wasn't able to find much information about this. Does Burn handle package
ref counting automatically? Is there nothing we need to do? Or should we be
using the DependencyExtension in some way? Do install devs need to handle
adding to the package ref count and subtracting?
Thanks.
--
View this
Would you say that the Requires element is not needed? I thought that
Requires might be placed inside of an MsiPackage or ExePackage, for
instance, to reference the Provides. But apparently the schema doesn't
support that. It can only be placed under a Bundle, Fragment or Provides. Is
it not used/n
This is probably a naive question, but why is it required to read the file at
install time? Could you get the information you need during development and
hardcode it into a component?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-get-conte
I believe that adding an XmlFile element inside of a Component will add an
action to the install sequence that will do the XML writing. That would
happen during the installation, not at the end. Is it a hard requirement
that this only be performed at the end? All actions that change the state of
th
If I understand, the new MSI will have a single file that can be used on any
OS? And the other OS-specific files will be removed/replaced?
A major upgrade should work well. It will uninstall the old files and then
install the new files. (Not necessarily in that order). So you'll
essentially be wo
Have you tried making the name of the property all uppercase? SERVICE_URL?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-XmlFile-using-old-property-value-tp7581739p7581838.html
Sent from the wix-users mailing list archive at Nabble.com.
---
Are you using the MajorUpgrade element? And what do you have for the
Product's Id? An asterisk? If it's the same Product ID, version and
UpgradeCode, I am surprised you are not seeing the Repair/Modify dialog when
the second MSI is run.
--
View this message in context:
http://windows-installer-
I'm curious about your setup. What is it about it that make having two MSIs
worthwhile? Did you not want to have two Features in a single MSI?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Editing-files-from-the-Bootstrapper-Application-tp7582014
WiX is a layer on top of Windows Installer, which has a certain look that
can't be changed. You could customize the look by adding a bootstrapper
project and writing a custom BA using WPF or WinForms, but that would be
some extra work on your part for such a small requirement.
--
View this messa
Just a few questions to help clarify:
What do you mean when you say it's not working?
Where are you putting the PermissionEx elements? Inside of a RegistryKey
element?
In your code sample you're using curly braces: {username}. Is that how you
have it for real?
--
View this message in context:
Using a custom action is something I hadn't considered. Here's a past posting
where someone was doing that:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/OpeFileDialog-C-Custom-Action-td5860149.html
--
View this message in context:
http://windows-installer-xml-wix-toolset.68755
StartType on the ServiceInstall table is not listed as a "Formatted" type.
Only formatted types can accept Windows Installer properties. I don't think
it's possible to do what you want with WiX markup. Possibly a custom action
could be made to handle it.
--
View this message in context:
http://
What language is the base MSI using? Meaning the MSI that you're embedding
transforms inside of? If the end user's language doesn't have a
corresponding transform, no transform will be applied and the MSI will use
the language it would have without any transform.
Are you using a Chinese installe
You cannot use the Message method to write to the install log when the custom
action is called using the DoAction control event. This is a limitation of
MSI.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Output-a-message-to-the-log-from-a-Custom-
Could you provide the steps you're using to create the installer? With
command line arguments?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Falling-back-to-default-language-if-locale-is-not-present-tp7582282p7582309.html
Sent from the wix-users
I'm more of a .NET guy, where the session.Message method in the DTF library
can't be called from within a DoAction custom action. It calls the
MsiProcessMessage behind the scenes. So the Message method you're talking
about may be different.
It seems to be a part of something called the Automation
Several people from the WiX community lent a hand getting the update to the
WiX book into shape. The end result covers more ground than the last
version, including, of course, Burn. All in all, I'm very pleased with the
end result! It's available for the Kindle on Amazon's site at:
http://www.amaz
Does it work if, instead of using the ServiceConfigFailureActions and Failure
elements, you use the util:ServiceConfig element? It has
FirstFailureActionType, SecondFailureActionType and ThirdFailureActionType
attributes that you can set to "restart", "runcommand" or "reboot".
--
View this messa
Could you attach the part of the log into the email message? Attachments
don't show up in the forum for me. It could be a couple of things really.
Might help to post some of your WiX markup too.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/odd-b
I don't see your MSI in the bundle's chain. Only the python and .NET ones. Is
this the code you wanted to show to the forum?
I've gotten that error message once before. It went away after I recompiled
through.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.
In your Bundle.wxs, if you have:
...
then you also need, after the BootstrapperApplicationRef:
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WixMbaPrereqPackageId-variable-not-visible-from-Fragment-element-tp7582403p7582421.html
That's a syntax I've not seen before: using the Property and VBScriptCall
attributes to trigger an embedded VBScript custom action. Try taking that
out and putting your script inside the CustomAction element.
It's acceptable to include the same components (your Java components) in two
different features.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-feature-dependency-tp7583348p7583384.html
Sent from the wix-users mailing list archive at Nabbl
It is MSI's default behavior to choose the disk with the most space. Try
capitalizing the property to TARGETDIR.
TARGETDIR=E:\
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-is-not-creating-in-the-Drive-tp7583373p7583385.html
Sent from the wi
You could try to hardcode "false" in the app.config. Then, put a conditional
statement inside the Component element that has the XmlFile in it so that
the component will only be installed (and the app.config written to) if the
property exists.
When the box is deselected, the property should be de
Have you read through the various documentation: manual, tutorial, book at
http://wixtoolset.org/? I would start by learning the basic of building a
WiX project before jumping into installing a website. Installing a website
is an advanced topic. To do so, you will need to use the WiX IIS extension.
Are you able to start/stop the service manually? Just to make sure there's
nothing wrong with the service itself. What is the exact error message
you're seeing? Is there anything in the Windows event log? Such as a
permission issue?
--
View this message in context:
http://windows-installer-xml-
That's good that you can start the service manually. That means that there
isn't something wrong with the service itself. Also, the error message
you're seeing is a generic message, not necessarily related to permissions.
The first thing I'd try is adding the Wait attribute to your ServiceControl,
This is an interesting circumstance. Chocolatey is a new way of deploying
software packages, sort of like apt-get on Linux. Ordinarily, upgrading
software that was previously installed via an MSI is easy. You just author a
major upgrade into the next MSI or you create a patch. I'm not familiar with
That sounds right to me. Use a MajorUpgrade element to handle the upgrade.
That will replace the obsolete version and replace it with the new one.
You'll just need to manually change the Product's Id (and Product version)
in updated versions of the MSI.
--
View this message in context:
http://w
1 - 100 of 302 matches
Mail list logo
