Re: [WiX-users] How to hide a file in WXS configuration file ?

[Michael Turner]

Fabrice,

I think you may be confusing *build-time* source paths (on your machine)
with *run-time* destination paths (potentially on a different machine).  The
only mention of "app\resources" that I see in your code snippet is here:

   

This means that when your installer is built, it takes the file from
app\resources\_dt.xsl on your machine (or the machine where the installer is
built), and puts it in the MSI package.  The "app\resources\_dt.xls" path
tells the WiX toolset where to find this file, to embed it into the MSI
package at "build time", but that is the end of that path's involvement.

Then, when the MSI package is installed (at "run time"), it takes the
_dt.xsl file that is now stored in the MSI package's embedded "CAB", and
installs it to the directory specified by APPLICATIONFOLDER, because that is
the Directory of MyFileId's Component.  The MSI package does not know about
the original "app\resources" source path at this point, as its involvement
ended when the MSI package was built.

Next, MyFileCopyId says to take the same _dt.xsl that it previously
installed to APPLICATIONFOLDER, and install another copy of it to
DestinationDirectory="APPLICATIONFOLDER".  But the MSI runtime detects that
those paths are the same (it is saying to copy the file to *itself*), so it
does nothing.

Now, in the scenario where you build the MSI package and install it *on the
same machine*, the end result (on a superficial level) looks the same as if
you had copied the file from your "app\resources" source path to the
"APPLICATIONFOLDER" destination path, but that is not precisely what
happens:  this is not a *direct* copy-and-paste from the source folder to
the destination folder.  Rather, the file is read from the source path,
embedded in a package, (at this point the package could be distributed to a
different machine), read from the package, and installed to a destination
folder -- and there is a great deal more going on behind the scenes,
including the support for the "resiliency repair" that Phil mentioned.


So unless you have defined an "app\resources" *destination* folder structure
(i.e., with Directory elements in the WiX markup) that you didn't show in
your code snippet, or unless you are trying to copy and/or move an
app\resources\_dt.xsl file that *already existed* on the destination machine
(instead of packaging and delivering your own _dt.xsl), then I don't quite
follow you.

Regards,
Mike


Fabrice MAUPIN wrote
> Hi,
> 
> The file is not copied in the same location !
> 
> The file is copied from "app/resources" to the root of APPLICATION FOLDER.
> 
> The structure of the package after the install :
> 
> APPLICATION FOLDER
>   | APP
>   | Resources
>   My file
>   | RUNTIME
> 
> " Also, if "the folder which contains this file can be deleted." means
> that you are going to remove the files and folder that were installed
> directly by the install (not the copyfile) then you have an issue there
> because MSI resiliency repair will attempt to restore it."
> 
> It means that it is not possible to remove files or folders (installing by
> MSI) after install (else restore them by MSI)  ?
> 
> -
> Fabrice
> 
> -Message d'origine-
> De : Phil Wilson [mailto:

> phildgwilson@

> ] 
> Envoyé : vendredi 10 octobre 2014 18:33
> À : General discussion about the WiX toolset.
> Objet : Re: [WiX-users] How to hide a file in WXS configuration file ?
> 
> I think the point Michael is making is that during the install you are
> copying a file to APPLICATIONFOLDER as part of the "normal" MSI install
> process, and then you're doing a separate copyfile of that same file to
> the same location with the same name. This can't be right, so maybe you've
> just made a typo error, but in any case the WiX docs say that a copyfile
> of the same file to the same location with the same name doesn't do
> anything. So presumably you want to copy it to some other location?
> 
> Also, if "the folder which contains this file can be deleted." means that
> you are going to remove the files and folder that were installed directly
> by the install (not the copyfile) then you have an issue there because MSI
> resiliency repair will attempt to restore it.
> ---
> Phil Wilson
> 
> 
> On Fri, Oct 10, 2014 at 12:19 AM, Fabrice MAUPIN <

> fmaupin@

> > wrote:
>> Hi,
>>
>> For information, I use WiX 3.8.
>>
>> "...copying a file that you're already installing, but I've never 
>> found a good reason to use it in this way"
>>
>> Yes I've a 

Re: [WiX-users] How to hide a file in WXS configuration file ?

[Michael Turner]

Fabrice,

The CopyFile element is kind of an oddball, particularly in the use-case
where it points to another File in the same installer.  Sure, the CopyFile
element exists, and it supports copying a file that you're already
installing, but I've never found a good reason to use it in this way; it
might be useful for copying a file that's already on the destination machine
(i.e., the syntax where you specify one or more Source* attributes), but
that's about it.  When you use the FileId="..." syntax, the way that it
binds one component to another has some weird consequences.  But if you're
just trying to save space by not having to store the same file twice in the
MSI, you can do that without CopyFile.  As of WiX 3.5 (I think?), the WiX
Linker does "smart cabbing":  if it detects that two File elements are using
the same physical source file, then it stores the file just once and then
has both File elements point to it.
http://robmensching.com/blog/posts/2007/6/1/quotsmart-cabbingquot-added-to-wix-toolset/

Anyway, if I understand you, you want to install the same file to two
different places, with the Hidden flag set in one place but not in the
other?  (However, your code snippet is specifying APPLICATIONFOLDER twice,
so maybe I misunderstand you.)  This is one of the many things you can't do
with CopyFile; you can't change file attributes during the copy.  But thanks
to "smart cabbing", you can just use two File elements, and as long as
you're using WiX 3.5 or later, this won't make your MSI any larger.

E.g.,



(In my example, I am leaving off unnecessary attributes, per
http://www.joyofsetup.com/2009/12/31/simplifying-wix-component-authoring/ .)

Regards,
Mike


Fabrice MAUPIN wrote
> Hello everybody,
> 
> This is an extract of my WXS configuration file :
> 
>  
> 
> 
>  
> 
>  
>  Source="app\resources\_dt.xsl" KeyPath="yes" />
> 
> 
> 
> 
> 
>  DestinationDirectory="APPLICATIONFOLDER" />
>  
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>  
> 
> 
> 
> 
> I would like to hide the  "_dt.xsl" file which was copied : is it possible
> ?
> 
> If yes, how ?
> 
> Thanks you.
> Fabrice





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-hide-a-file-in-WXS-configuration-file-tp7597186p7597195.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch doesn't find Key

[Michael Turner]

Try adding Secure="yes" on the Property.  This means that "the Property can
be passed to the server side when doing a managed installation with elevated
privileges".  I don't fully understand what "the server side" is, but I
think it has something to do with the "transactional" part of the
installation, and I think it's where deferred custom actions happen.

If you turn on logging, you'll see it list out property values with "(c)",
which is "the client side", and later with "(s)", which is "the server
side".  If you see that this property has the correct value with a "(c)" and
has no value with "(s)", then you need to mark it as "secure".

Related:
-
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Property-Secure-when-to-use-td4982590.html
-
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Simple-question-about-properties-tp4974905p4980963.html


Another possibility is that you are looking for the wrong thing. 
[HKLM\Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER] does
not normally have a value named "test" on it.  If you are looking for a SQL
Server 2008 R2 SSRS installation path, that's usually on the key
[HKLM\Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Setup]
on the value "SQLPath" or "SqlProgramDir".

Regards,
Mike


-Original Message-
From: Brett Faurot [mailto:Brett.Faurot@]
Sent: Tuesday, June 10, 2014 12:51 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

Thank you Phil and Pavan,
I have tried explicitly calling out 64-bit and specifying type="directory"
but it still fails to find it. The only difference I can tell between this
use and others in the installer are the . and _ in the key. I was wondering
if that was throwing the registrysearch off.  It's frustrating when such a
simple thing causes a dead stop in work.

-Original Message-
From: Phil Wilson [mailto:phildgwilson@] 
Sent: Saturday, June 07, 2014 1:56 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] RegistrySearch doesn't find Key

..and also don't forget there are 64-bit and 32-bit registries so you may
need to explicitly choose one.
---
Phil Wilson


On Fri, Jun 6, 2014 at 12:43 PM, Pavan Konduru  wrote:
> Try putting type ="directory"
>
> -Original Message-
> From: Brett Faurot [mailto:Brett.Faurot@]
> Sent: Friday, June 06, 2014 12:32 PM
> To: wix-users@.sourceforge
> Subject: [WiX-users] RegistrySearch doesn't find Key
>
> I'm having problems using a registrysearch. I'm trying to get the install
> location of MS SQL Reporting Services by checking the registry; but, my
> installer is failing the find the key.
> 
> Key="Software\Microsoft\Microsoft SQL Server\MSRS10_50.MSSQLSERVER" 
> Name="test" Type="raw" /> 
>
> This same method is used successfully many other times in this installer. 
> Also, I can successfully populate the property looking for a value when
> the Key="Software\Microsoft\Microsoft SQL Server". It seems to be only
> once I introduce MSRS10_50.MSSQLSERVER that the registrysearch fails and
> the property fails to populate.  Any ideas?
>
> Thanks,
> Brett




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistrySearch-doesn-t-find-Key-tp7595091p7595175.html
Sent from the wix-users mailing list archive at Nabble.com.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange Beahaviour while installing previous Version

[Michael Turner]

Chris,

Well, it looks like you've found a workaround for now:  just uninstall the
old version before installing the new one.  It isn't pretty, but it seems to
be working for you.  Sometimes, that's just what you have to do when you're
migrating from one toolset to another.

But if you want to keep digging and see if there is something we can do in
the new version to get the old version to play nice in a Major Upgrade,
you'll need to decompile the old installer with WiX's "Dark" tool (I
recommend the -sct and -sui options to reduce the "noise"), to get to the
details I asked for earlier:

- the CustomAction element that describes what the custom action does
- all *Sequence/Custom and/or UI/Publish element(s) that schedule the action
and specify the conditions under which it should run

I'll also need to know when the RemoveExistingProducts action is scheduled
in your new installer, since some of the "later" scheduling options could be
problematic.

Now that I know that this is a VS Installer and may be using some
VS-supplied custom action DLLs, it is possible that the old version is
making some assumptions that its future version will be a VS Installer too,
but we won't know until we see its source code.

Regards,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-Beahaviour-while-installing-previous-Version-tp7594117p7594156.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Create MSI package with out installing Wix on Target machine

[Michael Turner]

Dileep,

Theoretically, there are other ways to utilize the WiX Toolset without
formally installing it on a machine, but none of them work very well with
Visual Studio Integration.  If you're using Visual Studio Integration and
you only need to work with one version of the WiX Toolset at a time, then
installing it is the way to go.  Think of it as an add-on for Visual Studio
(even though there's much more to it than just that):  Visual Studio won't
know what to do with a .wixproj unless you install it.  In this respect,
it's no different than any other VS add-on that uses a specialized .*proj
type:  if you're gonna build it, you gotta install it.

Regards,
Mike


dileep s wrote
> Suppose 4 users needs to create MSI package on their machines. Everyone
> should install WIX toolset to create MSI package. So, for time being is it
> possible to create MSI package without installing WIX toolset?





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Create-MSI-package-with-out-installing-Wix-on-Target-machine-tp7593359p7594154.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange Beahaviour while installing previous Version

[Michael Turner]

Chris,

Is your new version a "Major Upgrade"
(http://msdn.microsoft.com/en-US/library/aa369786.aspx), as opposed to a
"Small Update" or "Minor Upgrade"
(http://msdn.microsoft.com/en-us/library/aa370579.aspx)?  Also, if it is a
Major Upgrade, then when is your RemoveExistingProducts action scheduled?
(http://msdn.microsoft.com/en-us/library/aa371197.aspx;
http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html)

Could you also please provide XML snippets of the custom action in the
source code for the *previous* version of the installer?  What I'm looking
for is both the CustomAction element that describes what the custom action
does, as well as all *Sequence/Custom and/or UI/Publish element(s) that
schedule the action and specify the conditions under which it should run.

Regards,
Mike


Arthur, Christopher wrote
> Thx for the answer. The uninstallation of the previous Version is working
> fine. The error is ocuring only during Upgrade within the wix installer.
> 
> The strange thing the CustomAction.dll is searched within the default
> targetdir of the wix installer and Not within the targetdir of the already
> installed Application.





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-Beahaviour-while-installing-previous-Version-tp7594117p7594142.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with adding new elements using XMLConfig

[Michael Turner]

Uma,

Apologies for the delayed response.  If you haven't figured it out already,
you only need to remove the parent 'SnippetDir' node, and all of its
children will be removed with it.  However, you will need to be clever with
your XPath to make sure you select the correct 'SnippetDir' node for removal
-- e.g., reference something unique from the "More Stuff" part.

For example, something like this:

\snippetsindex.xml"
Node="element" ElementPath="//SnippetCollection//Language"
VerifyPath="SnippetDir[\[]MoreStuff/@Foo='bar'[\]]" />

You should replace the MoreStuff/@Foo='bar' qualifier with something that
uniquely describes the SnippetDir that you're adding on installation. 
Remember that you need to use the "[\[]" and "[\]]" to escape the square
brackets that would otherwise be interpreted as MSI's "[PropertyName]"
syntax.

The XmlConfig Element documentation is not very clear on this point, but in
my experience, for a "delete element" action, ElementPath points to the
parent of the element you want to delete (so the same ElementPath you used
when creating it as Node="document"), VerifyPath is interpreted relative to
the ElementPath, and VerifyPath specifies what you want to delete.

(I didn't repeat the xmlns:util namespace declaration on the above example;
you should put this on a higher-level element in your file so that you don't
have to keep repeating it.)

Regards,
Mike


uharano wrote
> Hi Mike,
> I got the installation to work using the Node="document" method. The xml
> content is now correctly written during install mode.
> To remove the xml content during uninstall, I need to specify each node in
> a sequence (working from the child elements to outer elements), correct? I
> cannot use the Node="document" and pass the entire xml snippet?
> 
> Thanks!
> Uma





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Help-with-adding-new-elements-using-XMLConfig-tp7593764p7594140.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Service Start Too Early - Can I delay on install?

[Michael Turner]

>From http://msdn.microsoft.com/en-us/library/aa371634.aspx

"Note: Services that rely on the presence of an assembly in the Global
Assembly Cache (GAC) cannot be installed or started using the ServiceInstall
and ServiceControl tables. If you need to start a service that depends on an
assembly in the GAC, you must use a custom action sequenced after the
InstallFinalize action or a commit custom action. For information about
installing assemblies to the GAC see Installation of Assemblies to the
Global Assembly Cache."

In short, don't put your service assembly and its dependencies in the GAC,
if you can help it.  Put them in a "real" folder instead.  The .NET "private
deployment" model may seem inefficient to you, but it will save you a good
deal of maintenance burden in the long run if you don't have to deal with
writing a custom action (or have to deal with publisher policies and version
redirection, etc.).

My $.02,
Mike



Marc wrote
> Hello All,
> 
> I have a service that is dependent on a DLL that gets installed from
> within
> the same MSI.  This DLL gets registered with the GAC on install.
> 
> My service hangs on install.  If I modify my install not the start the
> service on installation through service control, and manually start it
> once
> the package is installed then everything works fine.
> 
> Is there a way to delay the ServiceControl start action, to make sure the
> DLL that gets registered with the GAC is properly installed.
> 
> 
> Thanks for the advice,
> Marc





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Service-Start-Too-Early-Can-I-delay-on-install-tp7594131p7594135.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange Beahaviour while installing previous Version

[Michael Turner]

Small correction:  I meant to say, "we are going to ... create a dummy
installer whose sole purpose is ... to prevent [the custom action DLL] from
being removed when you UNINSTALL the first product."  I.e., to make sure
that it is still around when the post-RemoveFiles custom action tries to use
it.

Also, theoretically you COULD try doing an in-place upgrade to the new
version instead of uninstalling the old version and installing the new
version as separate steps.  But in the case of a defective previous-version
installer and a clever workaround like this, I'd recommend keeping it simple
and doing things one step at a time.

It is possible that your custom action DLL may have additional dependencies
on other installed files, in which case you will need to copy-and-paste
their components into the dummy installer as you did before.  If you need to
do this, then you may need to make further adjustments to the custom action
DLL to ensure that it is fully self-contained for use in subsequent versions
(e.g., if it's a C# or VB.NET DLL, make sure you're using the one whose name
ends with ".CA.dll").

Regards,
Mike


Michael Turner wrote
> If you are in this situation, here's a workaround you can try.  What we
> are going to do is create a dummy installer whose sole purpose is to
> increment the reference count of the MSI Component that contains the
> custom action DLL, to prevent it from being removed when you install the
> first product.





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-Beahaviour-while-installing-previous-Version-tp7594117p7594132.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange Beahaviour while installing previous Version

[Michael Turner]

Chris,

This looks like a bad design choice in the previous version.  Most of the
time, you're going to want to embed your custom action DLL as a Binary in
the MSI package rather than installing it on the target machine as a File in
a Component.  I.e., put the custom action DLL on a Binary rather than File
element, and use the BinaryKey rather than the FileKey attribute on the
CustomAction element.  If you are able, you should definitely change this in
subsequent versions, although it's too late to change this for previous
versions that you've already delivered or installed somewhere.

The most likely problem is that the uninstall custom action is scheduled to
run after the RemoveFiles standard action, so it is failing because by the
time it tries to use the custom action DLL during uninstallation, the DLL
has already been removed.  Unfortunately, you can't change the
uninstallation behavior (or anything in the MSI database or embedded CAB) of
an MSI package that is already installed, so it's always a good idea to test
uninstall and upgrade behavior BEFORE you ship.  Since you can't change the
old installation now, you'll have to outsmart it instead.

If you are in this situation, here's a workaround you can try.  What we are
going to do is create a dummy installer whose sole purpose is to increment
the reference count of the MSI Component that contains the custom action
DLL, to prevent it from being removed when you install the first product.

1. Start with the source code of the original product installer, and make a
duplicate copy.
2. In the duplicate copy, generate a new Product ID (GUID) and a new
UpgradeCode (GUID).  The Package ID (GUID) should be omitted or set to "*"
if it isn't already (i.e., anything but hard-coded).  Also give it a new
Product Name and Output File Name, at your discretion.  (And if you really
want to be thorough, you should edit the .wixproj file as XML and give it a
new ProjectGuid as well.)
3. Strip away everything except the Component that contains the custom
action DLL, the Directory structure that contains it, and a single Feature
to reference it.  When you're done, these should be all you have left (plus
enough bare-bones UI for it to run).  I.e., no launch conditions, no custom
actions, no merges, no other components.
4. Make sure that you have the exact same target path (key path) and the
exact same Component GUID as the original -- this is vital, because the
Component GUID needs to match in order for the reference count to be
incremented properly.  If you are using auto-generated Component GUIDs per
the recommended practice, then it should be enough to ensure that the target
path (key path) stays the same.  (If the Component contains something more
than just the custom action DLL's File, you'll need to duplicate that as
well, since you want it to be the exact same Component in every way.)
5. Build and install the new "dummy installer".
6. Try uninstalling the original product.
7. If that worked, then uninstall the "dummy installer".

If this works out, then you should distribute this dummy installer to anyone
who has the previous version installed, and instruct them to (1) install
dummy, (2) uninstall old main product, (3) uninstall dummy, and (4) install
new version of main product, in that order.

Hope this helps,
Mike



Arthur, Christopher wrote
> One of our custom Installer has got an CustomAction during Uninstall.
> When I try to Update this installer the Custom Action is called, but it
> fails. The CustomAction.dll could not be found.
> 
> While searching within the Installation.log I've found an entry which trys
> to find the CustimAction.dll of the previous Installer at the default
> TragetDir of new one.
> How can I fix this ?





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-Beahaviour-while-installing-previous-Version-tp7594117p7594129.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] problem with installer

[Michael Turner]

Have you tried running the application without going through the shortcuts? 
It is possible that the application may be crashing, and your machine may be
configured to go straight to the debugger when a crash occurs.  Usually when
this happens, something is logged in the Application Event Log, so you
should start by looking there.

Regards,
Mike



Илья Циликов wrote
> After its installation the shortcuts (both) start debugging of the
> application but not only the application itself. I've met such situation
> for
> the first time and longtime already I can't understand what's wrong, why
> the
> debugger starts instead of the application. By the way it occurs both for
> debug and release configurations.





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/problem-with-installer-tp7593969p7594007.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] path to framework SDK $(FrameworkSDKDir)

[Michael Turner]

I'm not sure what you are expecting $(FrameworkSDKDir) to point to in a
.wixproj.  Which version of the framework?  There is no clear answer to this
question within the context of a WiX project, because WiX projects do not
target .NET Framework versions and do not use the .NET Framework SDK. 
Rather, they use the WiX toolset.

If you are looking for a .NET Framework SDK path, I would recommend looking
in a project type that uses the .NET Framework, such as a C# project.

Also, if you are trying to use a tool from the $(FrameworkSDKDir) path on
the output of a WiX project, you are probably on the wrong track, because
the output of a WiX project will be either a Windows Installer database
(.msi or .msm) or a WiX library (.wixlib), not a .NET assembly.  Perhaps
your post-build event would make more sense elsewhere?

Regards,
Mike



wixon wrote
> I need a path to SDK framework in post-build event.
> Standard VisualStudio projects support $(FrameworkSDKDir) macro but WiX
> 3.7 does not.
> Does WiX 3.8 bring support for this macro ?
> If not, what's the best way to get that path (aside from hard-coding) ?





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/path-to-framework-SDK-FrameworkSDKDir-tp7594004p7594006.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Some but not all files being removed on uninstall

[Michael Turner]

Scott,

Is your product using conditional Features?  One way that components can get
"orphaned" is if they belong to a Feature whose Level is 0 at time of
uninstall.  Usually this happens when the intent is to install the feature
only if a certain prerequisite software is present, and if the prerequisite
is uninstalled before the product.  I've found it's best to follow this
pattern:



...


The "orphaning" happens if you forget to include the "REMOVE OR " part. 
(There are other alternatives that involve checking whether the feature is
currently installed, but this is the simplest way.)

Otherwise, it's possible that the Component GUID-based reference counts are
out of whack, which could happen from "orphaning" in the past.  It looks
like this tracking might be stored in the following registry path, but I
definitely would not advise editing or deleting anything unless you really
know what you are doing and have made a full system backup first:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\{YourSID}\Components\

And I think the keys under this are encoded in a way that is not as simple
as just removing the braces and dashes from the GUID, so I would suggest
searching for the target path instead.  Then you'll at least know whether
leftover reference counts are the problem.  Just make sure that they don't
legitimately belong to another product that is installed. =)

Regards,
Mike


Scott Moyer wrote
> I do not see anything suspect in the install log.
> 
> Components that get removed say 'Action: Absent' in the uninstall log.
> 
> Components not getting removed have 'Action:  Null' in the uninstall log.
> 
> 
> Also Registry entries are not being removed ('Action:  Null'), even when
> using 
> 
> 
> SharedDllRefCounts are all 0.
> 
> I am using Guid="*" for all components.
> 
> I am using the same model/code for all files so why some files getting
> removed and some not? The files not getting removed are exes and dlls.
> 
> 
> I am running as Administrator.
> 
> What could be making it so some files and all registry entries do not get
> removed on uninstall?
> 
> 
> Could there be some sort of registration stuck from a prior install? If so
> how do I remove that?
> 
> Thanks.





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Some-but-not-all-files-being-removed-on-uninstall-tp7593743p7593777.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help with adding new elements using XMLConfig

[Michael Turner]

Uma,

First of all, I don't think you can insert XML before a given node using
XmlConfig; you can only append a new child to a given parent node.
(http://stackoverflow.com/q/8224918)

Also, there are two nodes that match your XPath expression, and XmlConfig
only uses the first match.  Since you know that the node you have just added
will always be the last one (due to the append behavior), you should try
this XPath for your 1002 expression instead:

ElementPath="//SnippetCollection//Language/SnippetDir[\[]last()[\]]"

Notice that you must escape the square brackets per
http://msdn.microsoft.com/library/aa368609.aspx

I am not certain whether the last() function actually works on XmlConfig,
but this should get you closer.  If that does not work, then you can try
this instead:

  ;
 
Off]]>
  

If you use this, it can replace both of your XmlConfig elements, since it
combines them into a single operation.  Note the Node="document", which lets
you specify the XML content to insert, as inner-text of the XmlConfig node. 
I am not sure whether the Node="document" construct treats the inner-text as
a "Formatted String" (http://msdn.microsoft.com/library/aa368609.aspx) or
not, so if your "More Stuff" contains any square brackets or [PropertyName]
expressions, you may need to experiment to see how it behaves.

Regards,
Mike


uharano wrote
> I want to add the highlighted lines with my setup:
> 
> 
> 
> 
> 
> 
> 
> 
> Off
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On
> 
> 
> 
> true
> 
> 
> 
> 1033
> 
> 
> 
> %InstallRoot%\VC#\Snippets\%LCID%\Visual C#\
> 
> 
> 
> Visual C#
> 
> 
> 
> 
> 
> 
> In Wix these are my lines of code:
>    Id="CreateSnippetDir" Node="element"
> File="\snippetsindex.xml"
> ElementPath="//SnippetCollection//Language" Sequence="1001"
>   xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
> Name="SnippetDir"  />
>    Id="CreateOnOff" Node="element" File=" Xml>\snippetsindex.xml\snippetsindex.xml"
> ElementPath="//SnippetCollection//Language/SnippetDir" Sequence="1002"
>   xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
> Name="OnOff" Value="off" />





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Help-with-adding-new-elements-using-XMLConfig-tp7593764p7593776.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Component/@Guid error

[Michael Turner]

I have encountered this also.  This a defect in light.exe 3.0.5419, which I
confirmed by downloading the WiX 3.0.5419 source code and searching for the
error message.  (I did this a few months ago, so I can't remember the exact
location off the top of my head.)

This is what the linker does in 3.0.5419:  If you try to auto-generate a
Component GUID for any component whose key path is in the registry, it reads
through the entire Registry table (i.e., the in-memory representation
thereof), and if it finds *ANY* entries that use Property substitution, it
throws this error.  This is defective logic:  it should only be examining
the entry that is the key path of the component in question, rather than the
entire table.

If you have the option, I would recommend using WiX 3.5 or later.  As far as
I can tell, the component GUID auto-generation was still in its infancy in
3.0 and didn't really get finished or stable until 3.5.

Regards,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-Guid-error-tp7579390p7588278.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] wixlib backward compatibility in WiX 3.5, 3.6, 3.7

[Michael Turner]

Does anyone have experience using 3.5-built wixlibs with light.exe in WiX 3.6
and 3.7?  For purposes of this discussion, I'm only concerned with the
official RTMs (3.5.2519.0, 3.6.3303.0, 3.7.1224.0).

My objective is to use wixlibs for inter-project collaboration, so that one
project can produce wixlibs for reuse in other projects.

Is the wixlib format reasonably backward-compatible across these versions,
or would I be better off requiring all parties to use the same version of
the WiX toolset?

Thanks,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wixlib-backward-compatibility-in-WiX-3-5-3-6-3-7-tp7587900.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Are there any special characters I should avoid in a FeatureGroup ID?

[Michael Turner]

The syntax rules for ComponentGroup and FeatureGroup IDs seem to be fairly
liberal:  just about anything goes, including embedded spaces and
backslashes (i.e., characters that are not allowed in traditional
identifiers).  Of course, $(...) and !(...) are still special and can be
expanded (if valid) by the WiX compiler and linker, respectively.

I'm on WiX 3.5 RTM (3.5.2519.0), and I've been experimenting with
FeatureGroup IDs containing backslashes (modeling a hierarchical breakdown)
with no trouble so far.  For example
"MyProduct\FooLayer\Widget1.OptionalQualifier".

Are groups IDs like this safe to use long-term, or is there a possibility
that backslashes could take on a special meaning in future versions of WiX
(especially the .wixobj and .wixlib formats) and/or a possibility of causing
problems (or security vulnerabilities) in the linker?


Thanks,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Are-there-any-special-characters-I-should-avoid-in-a-FeatureGroup-ID-tp7584019.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using Condition Level="0" results in files being left behind after upgrade then uninstall.

[Michael Turner]

Condition Level="0" is tricky.  There's a warning about this buried in the
MSDN documentation for the  Condition Table
  : "Conditions should be
carefully chosen so that a feature is not enabled on install and then
disabled on uninstall. This will orphan the feature and the product will not
be able to be uninstalled."

I.e., you need the condition for Level 0 to be NOT "condition for enabling
the feature" AND NOT "feature is already installed".

I usually deal with this by adding a registry value to the feature
(HKLM/HKCR/HKMU as appropriate), reading it to a property via
RegistrySearch, and adding the property to the Level 0 Condition:




As for the cleanup, unfortunately there's not much you can do about a
version that's already shipped.  But this should at least make an
improvement for your next release.

Hope this helps,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Condition-Level-0-results-in-files-being-left-behind-after-upgrade-then-uninstall-tp7583950p7584017.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.6 MergeModule creation regression?

[Michael Turner]

Dirk Ziegelmeier wrote
> here is a minimal mergemodule showing the error:
> 
> 
> http://schemas.microsoft.com/wix/2006/wi";>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  KeyPath="yes" Checksum="yes" />
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> W:\tmp\CommonFiles.wxs(14) : error LGHT0231 : The component
> 'cComSTAHelper.63744358_CA08_4563_B039_4BE7181B668E' has a key file with
> path 'TARGETDIR\acme\comstahelper\comstahelper.dll'.  Since this path is
> not rooted in one of the standard directories (like ProgramFilesFolder),
> this component does not fit the criteria for having an automatically
> generated guid.  (This error may also occur if a path contains a likely
> standard directory such as nesting a directory
> with name "Common Files" under ProgramFilesFolder.)

Apologies for the necropost, but this ( Bug #3121
  ) looks similar to  Bug #2938
   that I filed in May, where I
demonstrated that this differed from the behavior in WiX 3.5.  Rob, your
response at the time was that "Auto-generated Component GUIDs were never
supported in Merge Modules unless you used
Directory@ComponentGuidGenerationSeed."

My understanding is that is that "CommonFilesFolder" must be modularized
because of the way that MSI handles merges (Directory table can't reconcile
identical primary keys from multiple sources), and after it is modularized,
it is no longer a well-known root directory.  My best guess it that WiX 3.6
changed the Component GUID auto-generation to occur after property/directory
modularization rather than before.  

Rob, could you confirm whether this is considered a regression or working as
designed?

Thanks,
Mike



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-6-MergeModule-creation-regression-tp7581302p7581787.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Password validation without CA

[Michael Turner]

Nirmalraj,

I have implemented something similar, and I ran into the same problem that
you did.  In my implementation, I created additional custom dialogs to
display messages if the "Password" and "Confirm Password" entries did not
match or if either the user name or password was empty.  Then I keep the
"Next" button enabled and use conditions on it to determine how to proceed. 
I have this in the UI file that defines the my custom dialog-set:

  
SERVICEIDENTITY And SERVICEPASSWORD And (SERVICEPASSWORD =
ServicePassword2)
  
  
Not (SERVICEIDENTITY And SERVICEPASSWORD)
  
  
 ServicePassword2)]]>
  

where InvalidIdentityDlg and MismatchedPasswordsDlg are custom dialogs that
I defined.  In my example, I am displaying a dialog to prompt for a user
name and password to assign as the Identity of a newly-created Service,
although in your case you may not need the user name prompt.  Additionally,
I require a user name to be specified (as opposed to defaulting to "Local
Service" account) and I require the account to have a password (unprotected
account not allowed).

This example is designed for WiX 3.x.  In WiX 2.x, this Publish syntax is
not supported, so you would need to add these as Conditions under the
control (as in your original example) instead.

Note that the test for inequality to empty-string can be omitted, because
empty properties always evaluate to False and non-empty properties evaluate
to True.  Also, you only need to test whether one of the password fields is
non-empty, since you are also testing the two password fields for equality.

Regards,
Mike


Nirmalraj Durai wrote
> Hi, i'm validating password (Edit) and confirm password (Edit) without
> using CA. I'm doing validation inside the "Next" button control. My
> objective is, if the passwords are not correct or if any of the edit is
> empty "Disable the Next Button" else Enable it.
> 
> In my wix file i coded the following. I have a problem in which if i use
> mouse to click the "Next" button upon validation even the "Next" couldn't
> enable but if i made focus to anoter contrl, then it enable it. But if i
> use tab, the functionality working fine. How can i achieve.
> 
> 
>  
> 
>    <>
> FDECONFIRMPWD)) ]]>
>  
> 
>   
> 
>   ""
> OR
> FDECONFIRMPWD <> ""))]]>
>   
> 





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Password-validation-without-CA-tp7581748p7581767.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ComPlusExtension (Win64) does not honor reference count during install?

[Michael Turner]

I am using WiX 3.5 RTM (3.5.2519.0).  I have several x64 products that
depend on a COM+ application, and they may be installed either concurrently
or separately, so I am using a Wixlib to include the COM+ application in
the main feature of each product.  I use a custom dialog to prompt for a
user name and password to use as the application's identity.

































(I have used Orca to confirm that the auto-generated component GUIDs are
identical in both products.)


When I install the first product that contains this, it installs fine.  When
I install a second product that contains this,
theConfigureComPlusInstall_x64 action returns



Error 28018. A COM+ application with the same name already
exists.  (0  )



This also appears in a pop-up message box, with options to Cancel, Retry,
and Ignore.  If I choose "Ignore", and if the second installer repeats the
user name and password prompts beforehand, this works fine.  If I choose
"Ignore", and if the second installer uses a FileSearch to suppress the
username/password prompt when MyApplication.dll is already installed, then
the install fails, and rolls back, and removes the COM+ application.  (The
failure appears to be because it tries to change the COM+ application’s
identity to Interactive User, and Server 2008 policy forbids this, but the
CA cannot change it back.)



I can see in the Installer\...\Components registry that it is registering
both products as clients of this Component, and the SharedDLLs registry
entry has a count of 2, so Windows Installer proper is maintaining the
correct reference count for this component.  However, the ComPlusExtension
is trying to install the application a second time when its key path
already has a reference count >= 1, and if this fails then it uninstalls
the application during rollback despite its key path having a reference
count > 1.


The one situation where reference counting works the way I expect it to is
during uninstall:  if I manage to install two products successfully,
uninstalling one of them does not remove the COM+ application, because its
reference count is still > 0.



The WiX documentation mentions the concept of a ComPlusApplication
"locator" or "locater".  I have the impression that the locator/locater
mechanism is for modifying an existing COM+ application, while a
ComPlusApplication in a Component is only supposed to create a new
application rather than modify an existing one?  That is not the behavior I
am observing, however.


I found that I can suppress the attempt to recreate the COM+ application by
setting NeverOverwrite="yes" on the Component.  I am not thrilled about
having to resort to this, but it does seem to eliminate the "COM+
application of the same name already exists" error and the need for the
user name/password prompt when MyApplication.dll is already present.



Does anyone have experience with this type of scenario -- sharing a COM+
application among multiple products?  I want to ensure that the uninstall,
repair, and maintenance behavior is robust.


(I realize the user-supplied Identity and Password adds additional
complications during repair and maintenance; I will start a separate thread
for this.)



Thanks,

Mike
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users