Re: [WiX-users] RegistrySearch problem

2014-07-23 Thread Bevan Weiss
Is this a 64/32bit registry type issue?
And is the burn package being run with elevated privileges? (just to rule
out issues with registry permissions)


Regards,
Bevan

Date: Wed, 23 Jul 2014 00:38:22 -0700 (PDT)
From: vorsichtdiekurve mp.mateusz.polan...@gmail.com
Subject: [WiX-users] RegistrySearch problem

Hi,
I'm trying to determine what if a version of PostgreSQL is installed on a
windows 8.1 64 bit machine, using the following code:
*util:RegistrySearch Root=HKLM Id=PostgreSearch Win64=yes
Key=SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3 Value=Version
Variable=PostgreVersion /*
But when running the bootstrapper, i get this in the install log:
*Registry key not found. Key =
'SOFTWARE\PostgreSQL\Installations\posgresql-x64-9.3'*
Actually the key exists, it can be found using regedit.
Thank you in advance for any answer.
Mateusz

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Testing Wix FirewallException element logging question.

2014-05-02 Thread Bevan Weiss
It might be worth looking in the FirewallException CA code, or just testing
it, but perhaps it would accept a comma-separated list of which Zones it
should be active in.
So you might be able to put domain,public to get the desired single entry
with both tick boxes set.

I haven't tried this myself, but just throwing out an idea.

Bevan

Date: Fri, 2 May 2014 08:52:01 -0700 (PDT)
From: TimM timmay...@smarttech.com
Subject: Re: [WiX-users] Testing Wix FirewallException element logging
question.
To: wix-users@lists.sourceforge.net

Okay I changed the Name entries and it finally worked

So this works, but it would have been nice to be able to use the same Name
as we let the app run without the firewall entries and it prompts for
firewall exception then it will create the entry using the app name and
therefore there is only one.

This way we have 2 Name entries, one for Domain and one for Private. And if
the app is ran before hand it will create a 3rd entry...

It would have been nice if the FirewallException CA could have used the
same Name and therefore just created one line in the exception list with
Domain and Private checkbox checked... If you use the 'all' flag for
Profile then it correctly has one line with all check boxes checked...

Maybe someone should look at updating that custom action to either allow
same Name or under Profile allow multiple entries so that it all goes under
the same Name entry...

Anyways thanks Phill as this update will get me going for now.


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue

2014-03-26 Thread Bevan Weiss
Have you verified that your XSLT is performing its job properly?  If it's
setting the permanent attribute on every harvested component this would
obviously be the problem.

How are the registry entries a requirement?
If you are installing a 32bit application it can't see the 64-bit registry
hive, so you shouldn't put things into the 64-bit hive.

Have you set the component for the registry entry you want to keep to be
permanent?

Why do you not have the preferences file nested under a directory?
It should be under the ProgramData directory (well a subdirectory under
this).

Have you tried it on a fresh install of Windows?  One in which you haven't
installed anything else?
You should be using VMs to do testing.. since you will need to build up and
tear down lots of different machines during the course of proper testing.

Are you ever performing a Minor Upgrade, or are you performing manual
uninstall then re-install actions with each test?


--
Date: Wed, 26 Mar 2014 12:45:27 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
Subject: Re: [WiX-users] (Gentle Reminder)Creating directory under
C:\Programdata same as what the user specified in the UI dialogue
To: wix-users@lists.sourceforge.net

Hi Bevan,

As suggested I did the following:

  * Replaced all the manually generated GUID's with * except the
component preferences file as light was giving error for the same
saying it is not allowed because the component is not nested under a
directory.
  * Regarding the registry entries, it is as per the requirement.
  * I have performed the installation on a different machine, i have
tried installing to a different path altogether as well. For
instance i have tried doing the installation to C:\Energy Solutions
International\PipelineOptimizer 6.0.0 and also to C:\Energy
Solutions International\PipelineOptimizer 6.0.0 Test as is my
requirement.

Below are the observations:

  * All the folders data,db,gui,engine,security still are not removed.
As per my requirement only the data folder should have stayed as i
had set the permanent attributes for the component to yes using
XSLT transform while harvesting.
  * All the registry entries got deleted, the registry entry for the
data directory should have stayed.
  * Also commented out the registry entries then tried to see if there
is any change, but still the same results
  * Also getting the same message in the log file: Disallowing
uninstallation of component.

Has it something to do with the remembering of the installation folder as
suggested by Phil Hogland?

Regards,
Suvra Jyoti

--
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] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue

2014-03-25 Thread Bevan Weiss
I would suggest the following:
Replace all manually generated GUIDs with '*' wherever possible.  WiX can
autogenerate GUIDs for you in most situations (where you have a source file
I believe, it possibly works with RegistryKeys as well.. I can't remember).

You've also got duplicated RegistryKey entries.. you have two entries, each
with the same name and path, but just with Win64 set differently.
Since any one particular .MSI can only be EITHER 32bit/64bit you shouldn't
really have both like that.

I believe most people are even moving away from labelling individual
components Win64, and are just using the appropriate arch flag to the WiX
tools at compile-time.
I tend to just use the higher package level setting (which again I can't
remember off the top of my head).

You will need to perform an installation on a completely fresh machine.  If
this works, then it's not a problem with the installer, but with your
machines configuration.
Perhaps you changed around components etc resulting in a component having
been installed at a previous time and not removed (if you ever did a minor
upgrade, where the UPGRADE code stays the same, but the PRODUCT code changes
and you haven't indicated that MajorUpgrades are to be performed).

Try the fresh VM / PC install and uninstall and let us know the results.


Bevan


=
Date: Tue, 25 Mar 2014 20:09:19 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
Subject: Re: [WiX-users] (Gentle Reminder)Creating directory under
C:\Programdata same as what the user specified in the UI dialogue
To: wix-users@lists.sourceforge.net

Hi Bevan,

I have modified my source file as below. In the custom dialogs that i am
using i have disabled the edit control that shows C:\Energy Solution
International path(that part is not attached here). That's the way i thought
of restricting the user and in the next dialog i am allowing the user to
change the folder that is mapped to [MYFOLDER] property.

Product Id=* Name=$(var.pgmName) Language=1033 
Version=$(var.SvnVersionBuild) Manufacturer='$(var.ManufacturerName)' 
UpgradeCode=C54B7D5D-0E66-43E8-A770-C9750693F057
 Package Id=* Keywords=Installer Description=Installer 1.0 
Comments='Installer' InstallerVersion='300' Languages='1033' 
Compressed='yes' SummaryCodepage='1252' InstallScope='perMachine' 
Platform='x64'/

 WixVariable Id=WixUILicenseRtf Value=$(var.LicensePath) /

 Media Id='1' Cabinet='Tort.cab' EmbedCab='yes' DiskPrompt=CD-ROM
#1/
 Property Id='DiskPrompt' Value=Tort Installation [1] /

 Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id =DESTINATIONDIR Name=.
   /Directory
 Directory Id='ENERGYSOLUTIONS'
 Directory Id='TORT' Name='.'
   Component Id=x86RegEntPLODbPath 
Guid=A407D5B4-61F5-4CD6-8E76-3BD1C3949FE9 Win64=no
 RegistryValue Id=x86DbPathRegValue Root=HKLM 
Key=SOFTWARE\$(var.RegKeyEntry) Name=$(var.dbRegName) 
Value=[TORT]$(var.DBFolder) Type=string /
   /Component
   Component Id=x64RegEntPLODbPath 
Guid=56AE5376-4855-4C06-BB85-F669BB0C83F4 Win64=yes
 RegistryValue Id=x64DbPathRegValue Root=HKLM 
Key=SOFTWARE\$(var.RegKeyEntry) Name=$(var.dbRegName) 
Value=[TORT]$(var.DBFolder) Type=string /
   /Component
   Component Id=x86RegEntPLODataPath 
Guid=97403372-06ED-468A-9EB6-CC34FF2279A0 Win64=no
 RegistryValue Id=x86DataPathRegValue Root=HKLM 
Key=SOFTWARE\$(var.RegKeyEntry) Name=$(var.dataRegName) 
Value=[TORT]$(var.DataFolder) Type=string /
   /Component
   Component Id=x64RegEntPLODataPath 
Guid=877F685E-97C1-4E9E-A7E0-F7342CA01BB9 Win64=yes
 RegistryValue Id=x64DataPathRegValue Root=HKLM 
Key=SOFTWARE\$(var.RegKeyEntry) Name=$(var.dataRegName) 
Value=[TORT]$(var.DataFolder) Type=string /
   /Component
 /Directory
   /Directory
 /Directory

 Component Id=PreferencesFile 
Guid={A4E1FFCE-1534-43BF-AA2B-CDFD39381720} Directory=TARGETDIR
   File Id='preferences' 
Source='$(var.GuiPath)\screens\preferences.xml' KeyPath='yes'
 CopyFile Id='Copy_Prefs' DestinationProperty='DESTINATIONDIR'/
   /File
 /Component

 SetDirectory Id=ENERGYSOLUTIONS 
Value=[WindowsVolume]$(var.rootFolder)/

 Feature Id='Complete' Title='Tort Installer' Description='Tort
Installer' Level='1'
   ComponentGroupRef Id='db'/
   ComponentGroupRef Id='data'/
   ComponentGroupRef Id='engine'/
   ComponentGroupRef Id='security'/
   ComponentGroupRef Id='gui'/
   ComponentRef Id=x86RegEntPLODbPath/
   ComponentRef Id=x64RegEntPLODbPath /
   ComponentRef Id=x86RegEntPLODataPath/
   ComponentRef Id=x64RegEntPLODataPath /
   ComponentRef Id=PreferencesFile /
 /Feature

 Property Id=WIXUI_INSTALLDIR Value=ENERGYSOLUTIONS/
 Property 

Re: [WiX-users] Avoid .net 3.5 requirement

2014-03-20 Thread Bevan Weiss
If you check the versions of all your Custom Action project references, they
should all be 4.00..
Are there any additional dependencies that you have for your Custom Action,
like 3rd party DLLs?  Perhaps they have a requirement for .NET 3.5

It might be worth using Orca or something similar to just break open your
created MSI and check the customactions.config file to make sure that it's
not modified from what your project settings have.


Regards,
Bevan Weiss

Date: Thu, 20 Mar 2014 13:06:19 -0400
From: Kevin Delafield kevindelafi...@hotmail.com
Subject: Re: [WiX-users] Avoid .net 3.5 requirement

I have this for my customactions.config

?xml version=1.0 encoding=utf-8 ?
configuration
  startup useLegacyV2RuntimeActivationPolicy=true
supportedRuntime version=v2.0.50727/
supportedRuntime version=v4.0 /
  /startup
/configuration

still doesn't seem to do the trick.


--
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] Heat.exe harvesting case sensitive vb6 dll's

2014-03-19 Thread Bevan Weiss
Hi Ravi,
Heat creates its unique file/component references based on the source name
of the file.
So if you change the name, or the relative location of the source file, then
the file reference may well change.
I believe there is a way to force it to not generate new references, however
I've found that generally it's not a problem since it's really not so common
to be modifying the filename anyway.

It's probably very important to note however that if you allow WiX to
dynamically create your component IDs that you shouldn't be renaming /
moving the source files for these components unless you will be forcing a
major upgrade.  Since changing component IDs on a minor upgrade is getting
into dangerous territory.


Regards,
Bevan Weiss
SAGE Automation

Date: Wed, 19 Mar 2014 10:11:38 +0530
From: Ravishankar ravishankar.krishnasw...@idsfortune.com
Subject: [WiX-users] Heat.exe harvesting case sensitive vb6 dll's

Hi,
Am facing a strange issue, i have a dll(VB6 created) with name =
LITA300.dll and when i extract using Heat.exe it generates a set of
Component ID and FileID Now if i change my dll name = lita300.dll , the
heat.exe is generating a different set of Component ID and FileID

C:\Program Files (x86)\WiX Toolset v3.6\bin\heat.exe dir C:\Temp -dr
INSTALLLOCATION -cg FORTUNEFilesGroup -gg -g1 -sfrag -scom -srd -svb6 -var
var.SourceItemsDir -out C:\Temp\Components.wxs

i have placed my dll under C:\Temp  folder

Can anyone please help me, is extracting dll files using Heat.exe is case
sensitive?, i mean should the filenames be case-sensitive?

Thanks and Regards
Ravi Shankar

--
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] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue

2014-03-19 Thread Bevan Weiss
Suvrajyoti,

If you allow the INSTALLDIR to be changed, then the whole thing could be
different...
For instance if someone changed the INSTALLDIR to be C:\, then what do you
consider that the C:\ProgramData.. folder should be named?

I believe that you shouldn't allow the user to select any directory they
like.
Instead you should give them the option (via a customised gui page) of
adding on a suffix to the installer directory that you have already
hardcoded.
Then you can just have your two folders be:
C:\Program Files ()\{Manufacturer}\{Product Name} 06.00.00 {whatever user
suffix they want}
And
C:\ProgramData\{Manufacturer}\{Product Name} 06.00.00 {whatever user suffix
they want}

This is possibly do-able by just having a formatted string as the folder
names for these two items.
If that doesn't work due to a WiX limitation, then you should be able to
perform a custom action to modify the MSI in memory database early on to get
the tables right for the actual installer operation.


Regards,
Bevan Weiss


Date: Wed, 19 Mar 2014 13:57:28 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
Subject: Re: [WiX-users] (Gentle Reminder)Creating directory under
C:\Programdata same as what the user specified in the UI dialogue

Thanks for the elaborate explanation, it made things clearer. But the
current structure that i am trying to follow is something that has been
decided upon.

How would i parse the INSTALLDIR value after it's been changed in the UI and
isolate out the part that has changed, i mean is there some sample code that
you could provide me?

On 18-03-2014 22:12, Phil Wilson wrote:
 If you look at the tutorial and my previous example there are just a 
 couple of principles here that you can use to figure out directories 
 in general:

 1. The default installation folder must be a folder derived from 
 standard system folder properties such as [ProgramFilesFolder]. Not 
 only is that the correct default location, it is not hardcoded, it is 
 resolved at install time to the actual values, These folder properties 
 are automatically the right location, the right name for non-English 
 systems, and the right location for 32 or 64-bit systems. So if you 
 actually wanted to have some of your files in ProgramData you would 
 use [LocalAppDataFolder] as the root of the property you use to 
 construct your folder. The key here is that you use standard 
 properties to construct a property name that describes your actual 
 folder. Typically the default name for the main app folder is 
 INSTALLDIR, constructed from [ProgramFilesFolder] [Manufacturer] 
 [ProductName] and stick {ProductVersion] at the end if you like.
 Similarly your ProgramData location could be called MYDATAFOLDER 
 constructed from [LocalAppDataFolder] {Manufacturer] [ProductName].
 That also means, by the way, that your [ProductName] should be 
 Pipeline Optimizer and your [Manufacturer] property should be Energy 
 Solutions, so you don't need to specify the hardcoded values 
 everywhere. See Name and Manufacturer in the Product element.

 2. When the actual paths are constructed from properties, they are 
 automatically changed to reflect the user's choioce (if any) and the 
 actual paths on the system. That means that for your copyfile you 
 always do the copy from (for example) [SourceDir] to [INSTALLDIR] and 
 it will always be correct. Or it could be from [SourceDir] to 
 [MYDATAFOLDER] and it will always be correct. The main install folder 
 [INSTALLDIR]  (that can be altered) is nothing to do with the 
 LocalAppDataFolder location, which is usually a fixed directory with 
 your manufacturer and product name in it.

 Having said that, and assuming I understand what you're trying to do, 
 I know of no built-in way to construct a custom ProgramData location 
 based on a UI change of INSTALLDIR. You would need to write code to 
 parse the INSTALLDIR value after it's been changed in the UI and 
 isolate out the part that has changed, and then set the property 
 MYDATAFOLDER to be [LocallAppDataFolder] plus whatever you parsed out 
 from INSTALLDIR. Your copyfile is still [SourceDir] to [MYDATAFOLDER].

 If it's the app that requires the unusual install folder and the 
 variable preferences file location, it's rather unusual, that's why 
 it's making your setup require a bunch of extra work. If you've 
 invented some of this, you should reconsider.

 ---
 Phil Wilson


 On Tue, Mar 18, 2014 at 5:54 AM, Suvrajyoti Panda 
 suvrajyo...@contata.co.in wrote:
 Thanks Walter for the response.

 I too understand that this is not conventional and may be not right 
 but when i am installing the tha pplication it creates a directory 
 C:\Energy Solutions International\PipelineOptimizer 06.00.00\gui  
 that has an application mosquito.exe that requires this 
 preferences.xml file under the C:\ProgramData\Energy Solutions 
 International itself else it is showing the error Preferences.xml 
 not found. Thats the reason i am using

Re: [WiX-users] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue

2014-03-19 Thread Bevan Weiss

http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_
a_file.html

Try this..
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=APPLICATIONROOTDIRECTORY Name=[YOUR SILLY PROGRAM
FILES PATH]/
/Directory
   Directory Id=LocalAppDataFolder
Directory Id=DATAROOTDIRECTORY Name=[YOUR SILLY PROGRAM DATA
PATH]/
/Directory
/Directory

I've never tried providing a formatted string, so it might not work.
If it doesn't then you'll need to essentially do the same thing but using
some custom action to modify the runtime database.

If this doesn't work, then my suggestion would be that you give up.
If it's really that important then eventually they will hire someone that
will make it work ;)


Regards,
Bevan

Date: Wed, 19 Mar 2014 20:04:41 +0530
From: Suvrajyoti Panda suvrajyo...@contata.co.in
Subject: Re: [WiX-users] (Gentle Reminder)Creating directory under
   C:\Programdata same as what the user specified in the UI dialogue

Hi Bevan,

Could you please provide some sample code on how to have a formatted string
as the folder names for these two items or the custom action thing.

Regards,
Suvra Jyoti
On 19-03-2014 17:37, Bevan Weiss wrote: 
 Suvrajyoti,

 If you allow the INSTALLDIR to be changed, then the whole thing could 
 be different...
 For instance if someone changed the INSTALLDIR to be C:\, then what do 
 you consider that the C:\ProgramData.. folder should be named?

 I believe that you shouldn't allow the user to select any directory 
 they like.
 Instead you should give them the option (via a customised gui page) of 
 adding on a suffix to the installer directory that you have already 
 hardcoded.
 Then you can just have your two folders be:
 C:\Program Files ()\{Manufacturer}\{Product Name} 06.00.00 {whatever 
 user suffix they want} And C:\ProgramData\{Manufacturer}\{Product 
 Name} 06.00.00 {whatever user suffix they want}

 This is possibly do-able by just having a formatted string as the 
 folder names for these two items.
 If that doesn't work due to a WiX limitation, then you should be able 
 to perform a custom action to modify the MSI in memory database early 
 on to get the tables right for the actual installer operation.


 Regards,
 Bevan Weiss


 Date: Wed, 19 Mar 2014 13:57:28 +0530
 From: Suvrajyoti Panda suvrajyo...@contata.co.in
 Subject: Re: [WiX-users] (Gentle Reminder)Creating directory under
  C:\Programdata same as what the user specified in the UI dialogue

 Thanks for the elaborate explanation, it made things clearer. But the 
 current structure that i am trying to follow is something that has 
 been decided upon.

 How would i parse the INSTALLDIR value after it's been changed in the 
 UI and isolate out the part that has changed, i mean is there some 
 sample code that you could provide me?

 On 18-03-2014 22:12, Phil Wilson wrote:
 If you look at the tutorial and my previous example there are just a 
 couple of principles here that you can use to figure out directories 
 in general:

 1. The default installation folder must be a folder derived from 
 standard system folder properties such as [ProgramFilesFolder]. Not 
 only is that the correct default location, it is not hardcoded, it is 
 resolved at install time to the actual values, These folder 
 properties are automatically the right location, the right name for 
 non-English systems, and the right location for 32 or 64-bit systems. 
 So if you actually wanted to have some of your files in ProgramData 
 you would use [LocalAppDataFolder] as the root of the property you 
 use to construct your folder. The key here is that you use standard 
 properties to construct a property name that describes your actual 
 folder. Typically the default name for the main app folder is 
 INSTALLDIR, constructed from [ProgramFilesFolder] [Manufacturer] 
 [ProductName] and stick {ProductVersion] at the end if you like.
 Similarly your ProgramData location could be called MYDATAFOLDER 
 constructed from [LocalAppDataFolder] {Manufacturer] [ProductName].
 That also means, by the way, that your [ProductName] should be 
 Pipeline Optimizer and your [Manufacturer] property should be Energy 
 Solutions, so you don't need to specify the hardcoded values 
 everywhere. See Name and Manufacturer in the Product element.

 2. When the actual paths are constructed from properties, they are 
 automatically changed to reflect the user's choioce (if any) and the 
 actual paths on the system. That means that for your copyfile you 
 always do the copy from (for example) [SourceDir] to [INSTALLDIR] and 
 it will always be correct. Or it could be from [SourceDir] to 
 [MYDATAFOLDER] and it will always be correct. The main install folder 
 [INSTALLDIR]  (that can be altered) is nothing to do with the 
 LocalAppDataFolder location, which is usually a fixed directory with 
 your manufacturer and product name in it.

 Having said that, and assuming I understand what you're

Re: [WiX-users] R: How to install VSTO Excel add-in that use dll with COM-visible objects?

2014-03-16 Thread Bevan Weiss
Artem,
As mentioned previously this list will not accept any form of attachments.

You should just link to your wxs files that Heat has created, and your base
wxs file for your installer.
That will give us more information on what you are doing wrong.

http://pastebin.com/
is a good location to use to paste your wxs files, then you can reply and
include in the link from the site.

You mentioned that you had heat parse the registry.
You mean that you had heat process the DLL / OCX (ETC) files to generate the
COM entries right?
If the DLL (etc) files aren't created quite right, or they do a bit of crazy
stuff when registered this can cause problems with Heat.
I believe there is also an outstanding bug that Heat can sometimes fail to
process 64-bit DLLs.. not sure what the status of this is (perhaps it's
resolved now).

Have you read the top 5 google results?
http://blogs.msdn.com/b/gsmyth/archive/2013/01/27/wix-installer-for-vsto-pro
jects.aspx
http://stackoverflow.com/questions/532447/how-do-you-use-wix-to-deploy-vsto-
3-0-addins
http://www.add-in-express.com/creating-addins-blog/2012/11/13/wix-installati
on-vsto-office-addin/
http://blog.deploymentengineering.com/2010/10/vsto-4-2010-lessons-learned.ht
ml
http://mgrowan.wordpress.com/2008/01/09/wix-installation-for-excel-add-in/


Regards,
Bevan Weiss

--
Date: Sun, 16 Mar 2014 06:44:02 +
From: Verbuk, Artem artem.ver...@intel.com
Subject: Re: [WiX-users] R: How to install VSTO Excel add-in that use
dll withCOM-visible objects?

Attached is the file with changed extension, change it to zip.
Zipped folder that contains:
1   ExcelAddin.wixproj - WIX setup project file
2   PreBuildEventsOfWixProject.txt - text file, that contains pre build
event of the setup project (you can find those in project file also)
3   All *.wxs and .xslt files of the project

Notice that the following files are result of heat.exe work:
RegistryKeysForCOM1.wxs
RegistryKeysForCOM2.wxs
AddinFiles.wxs

And I want to clarify my question once again. 
I want to know what is the exact list of things that I have to
do/umplement/unclude in my WIX setup, in order to deploy VSTO add-in for
Excel 2007/2010/2013. And it is important to add that my add-in is working
with external applications(explained in initial question), since this fact
adds a lot to deployment...

You see, if you will tell me to change some A in my .wxs file to B I
will be happy to deploy the add-in, but I will probably have problems with
making another setup for next version later. So, I want to understand the
why part first, and then be able to do the how part.

Many thanks,
Artem

--
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] WiX-users Digest, Vol 93, Issue 64

2014-02-20 Thread Bevan Weiss
I would only suggest trying a complete uninstall and reinstall of this
particular WiX version.
If this doesn't resolve it, you could try building against a different
version of WiX (as a test).


Bevan


=
Date: Wed, 19 Feb 2014 09:13:49 +0100
From: Ilir Bekteshi ilir...@gmail.com
Subject: Re: [WiX-users] Heat.exe Exception with MSBuild and
   HeatDirectory

Yes E: drive is local not a network share.

The location of the heat.exe is correct, when i copy the full path i get
from the error and run heat.exe from there it works i.e. the path is
correct.

I have built the project with MSBuild without any problems the issue came
when introducing HeatDirectory i.e. putting heat.exe to use.




On Tue, Feb 18, 2014 at 7:57 PM, Bevan Weiss kaize...@hotmail.com wrote:


 Is E:\ local?
 I suspect it might be a network share.

 If the MSBuild process is using elevated privileges then all network 
 shares (created when non-elevated) disappear.  This only occurs with 
 WindowsServer
 2008R2 and above I believe (and I'm not sure if it's in Windows 7, but 
 it's definitely in Windows 8 and above)

 Is v3.7.1224.0 the version that you are expecting?


 Bevan

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Heat.exe Exception with MSBuild and HeatDirectory

2014-02-18 Thread Bevan Weiss

Is E:\ local?
I suspect it might be a network share.

If the MSBuild process is using elevated privileges then all network shares
(created when non-elevated) disappear.  This only occurs with WindowsServer
2008R2 and above I believe (and I'm not sure if it's in Windows 7, but it's
definitely in Windows 8 and above)

Is v3.7.1224.0 the version that you are expecting?


Bevan

-Original Message-
Date: Tue, 18 Feb 2014 16:43:27 +0100
From: Ilir Bekteshi ilir...@gmail.com
Subject: [WiX-users] Heat.exe Exception with MSBuild and HeatDirectory

I have a HeatDirectory in wixproj and it works fine when i build from VS
but when i try to build with MSbuild it crashes with the error below. Does
any one have any idea why is this happening?


Unhandled Exception: System.BadImageFormatException: Could not load file or
assembly 'file:///E:\TFS\\tools\wix\3.7.1224.0\bin\Heat.exe' or one of its
dependencies. An attempt was made to load a program with an incorrect
format.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName,
String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at
System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly,
StackCrawlMark stackMark, IntPtr pPrivHostBinder, Boolean
throwOnFileNotFound, Boolean forIntrospection, Boolean
suppressSecurityChecks)
   at
System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly,
StackCrawlMark stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadFrom(String
assemblyFile, Evidence securityEvidence, Byte[] hashValue,
AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean
suppressSecurityChecks, StackCrawlMark stackMark)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at
Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThre
ad(Object
parameters)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart(Object obj)

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to select ASP.NET version

2014-02-14 Thread Bevan Weiss
The virtual directory doesn't care about what version ASP.NET you are
running, since it's not actually responsible for running any processes.
It's only the Application Pool that runs processes and thus cares about
whether you are .NET v2 or .NET v4 etc.. or even if you are 64-bit vs
32-bit.

When you use WiX to create an application pool (which you should be doing if
you are creating any Web Application... unless there's a good reason not to
create a dedicated App Pool for your application), then WiX will let you
choose which .NET Framework to target.  I believe this is just a version
number entry (ie 2.0 or 4.0)

All information can be found here:
http://wixtoolset.org/documentation/manual/v3/xsd/iis/webapppool.html

In regards to the 1603 error that you are seeing.  What kind of install are
you performing 'per-user' or 'per-machine'?
And what privileges does the installing user have?
Are you running with UAC or without?

What directory are you trying to create the WebApplication in?  What are
your user permissions for this directory?

To get a verbose(ish) log run the following (substituting in the appropriate
path to your msi).  This will generate a LogFile.txt which will contain the
verbose install log.
Msiexec /L*v LogFile.txt /I [PATH TO MSI]


Regards,
Bevan Weiss
SAGE Automation

=
Date: Fri, 14 Feb 2014 16:17:45 +0530
From: Kiran Somisetty mr.svski...@gmail.com

Is there a way to provide the ASP.NET version while creating Web virtual
directory in wix installer. I have created a installer that creates a web
virtual directory, but I see the ASP.NET version is pointed to 2.0. I want
to set it to 4.0, rather than manually changing it.

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Windows Service windows 7

2014-02-12 Thread Bevan Weiss
There's quite a few things missing from this...
Where is your ServiceInstall element?
Where is your File element?
Why are you setting LocalSystem permissions on a RegistryKey? (LocalSystem
already has Administrator type registry access)

WiX won't be trying to write into the EventLog that you have 'created'.  The
Service will still be responsible for that.
I suspect that you haven't configured the user properly in your WiX
ServiceInstall, and that is why it isn't starting, because it's not running
as
someone that is allowed to write into the EventLog, throwing an exception
because of this, and probably in your catch{} block you log the error
to the EventLog (which throws an exception aborting the service).

Please provide the full information.

I have created a Windows Service, it is installed by WiX, along with its own
EventLog source, and it happily writes to this EventLog without fail.
It runs as LocalSystem (just because I'm lazy, and don't want to create
individual folder permissions for a custom user)...


Regards,
Bevan Weiss


=

Date: Wed, 12 Feb 2014 11:35:35 -0500
From: Steven Dyson sdyson1...@gmail.com
Subject: [WiX-users] Windows Service windows 7

I created a dummy windows service for my first wix project.
Ive added
 Component Id=RegKeyPermissionComponent
Guid=A4FA2F01-DC4A-4CA7-995F-56947018EFCE KeyPath=yes
RegistryKey Id=ApplicationEventLogAccess  Root=HKLM
Key=SYSTEM\CurrentControlSet\Services\Eventlog\Application
Action=create

  util:PermissionEx GenericAll=yes Read=yes Write=yes
User=LocalSystem/
/RegistryKey

and

   Package InstallerVersion=300 Compressed=yes
InstallScope=perMachine InstallPrivileges=elevated

The service writes an entry to the eventlog.

If i install the service with a .bat file it works fine. If i use the wix
installer it installs but does not start. If i remove the event log write,
it will start.

What else can i do?


-- 

Steven Dyson

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] ListView Creation

2013-12-27 Thread Bevan Weiss
I don't think what you want is achievable using *just* WiX authoring.
You would need to use a custom UI handler for this, which is something that
I don't have any experience with, and from what I do know about it is that
it is quite a bit of work.

Perhaps you need to ask yourself if it's really so important to have it like
this.

Or you could try going back to SharpSetup and asking them to help.


Bevan

-Original Message-
Date: Fri, 27 Dec 2013 16:23:23 +0530
From: ak m wixak...@gmail.com
Subject: Re: [WiX-users] ListView Creation

Hi Bevan Weiss,

Thank you for the information.

My UI looks as in the link


 
ListViewDlg.JPGhttps://docs.google.com/file/d/0Bx3lIuciPpX5anZzRkJUckFPUlU/
edit?usp=drive_web

Please help me to create this...


On Thu, Dec 26, 2013 at 8:34 AM, Bevan Weiss kaize...@hotmail.com wrote:

 Instantiating the ListView is easy

 Control Id=ListView1 Property=ListViewProperty Type=ListView
 X=SomeX Y=WhyNot? Width=wide Height=short Sorted=yes
   ListView Property=ListViewProperty
 !-- If we will be populating this dynamically nothing to put here..
 --
   /ListView
 /Control

 EnsureTable Id=ListView /

 We use the EnsureTable since otherwise it might not be included in the MSI
 if it doesn't contain anything... but we need it to exist so that we can
 update it dynamically later.
 Might not actually be needed (since it's referenced with the Control), but
 it doesn't hurt to include it.


 Then the custom action would be something like... (in C# because it's my
 current favourite language)
 ... do stuff to get the thingsYouWant
 Microsoft.Deployment.WindowsInstaller.View lView =
 session.Database.OpenView(SELECT * FROM ListView);
 lView.Execute();
 int iOrder = 1;
 foreach(Thing thing in thingsYouWant)
 {
   try
   {
 Record lRecord = session.Database.CreateRecord(5);
 lRecord.SetString(1, ListViewProperty);
 lRecord.SetInteger(2, iOrder);
 lRecord.SetString(3, thing.HashCode()); // we use the hashcode,
because
 then we can easily find what they selected... use something else if it's
 more appropriate
 lRecord.SetString(4, thing. ToString()); // or thing.Name +  -  +
 thing.No +  -  + thing.pincode
 // lRecord.SetXXX(5) we leave this as null, unless we have put some
 icons into the binary table.. then we would populate this with the binary
 table identifier
 iOrder++;

 lView.Modify(ViewModifyMode.InsertTemporary, lRecord);
   }
   catch
   {
 continue;
   }
 }

 This is how to add items to the ListView controls dynamically.
 Hopefully it's helpful for someone...

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] ListView Creation

2013-12-25 Thread Bevan Weiss
Instantiating the ListView is easy

Control Id=ListView1 Property=ListViewProperty Type=ListView
X=SomeX Y=WhyNot? Width=wide Height=short Sorted=yes
  ListView Property=ListViewProperty
!-- If we will be populating this dynamically nothing to put here..
--
  /ListView
/Control

EnsureTable Id=ListView /

We use the EnsureTable since otherwise it might not be included in the MSI
if it doesn't contain anything... but we need it to exist so that we can
update it dynamically later.
Might not actually be needed (since it's referenced with the Control), but
it doesn't hurt to include it.


Then the custom action would be something like... (in C# because it's my
current favourite language)
... do stuff to get the thingsYouWant
Microsoft.Deployment.WindowsInstaller.View lView =
session.Database.OpenView(SELECT * FROM ListView);
lView.Execute();
int iOrder = 1;
foreach(Thing thing in thingsYouWant)
{
  try
  {
Record lRecord = session.Database.CreateRecord(5);
lRecord.SetString(1, ListViewProperty);
lRecord.SetInteger(2, iOrder);
lRecord.SetString(3, thing.HashCode()); // we use the hashcode, because
then we can easily find what they selected... use something else if it's
more appropriate
lRecord.SetString(4, thing. ToString()); // or thing.Name +  -  +
thing.No +  -  + thing.pincode
// lRecord.SetXXX(5) we leave this as null, unless we have put some
icons into the binary table.. then we would populate this with the binary
table identifier
iOrder++;

lView.Modify(ViewModifyMode.InsertTemporary, lRecord);
  }
  catch
  {
continue;
  }
}

This is how to add items to the ListView controls dynamically.
Hopefully it's helpful for someone...


-Original Message-
Date: Tue, 24 Dec 2013 16:59:31 +0530
From: ak m wixak...@gmail.com
Subject: Re: [WiX-users] ListView Creation

Thank you for the information..

Could you please provide any example on how to create the columns on Wix UI
and add values at run time?

I need to have 3 columns with Name, No, pincode,

Thanks in Advance...


On Tue, Dec 24, 2013 at 4:47 PM, Bevan Weiss kaize...@hotmail.com wrote:

 Attachments get stripped from this list, you will need to provide a 
 URL or some other such link to a hosted image.

 A ListView only really has two particular pieces of useful information 
 for each 'row', that being a Value, and an item of Display.
 If you want more columns then perhaps you need to rethink the way 
 you're going about the data.

 You could create your own custom table in the MSI and have a unique ID 
 as one of the fields.
 This unique ID is then the 'Value' from the ListView to allow the 
 selection of an entire row of data from your custom table.

 If you want to display all the columns to the user, then what you 
 probably want to do is concatenate the various fields together and 
 call this the 'item of Display'.


 Both options can be done using WiX, the first will likely require a 
 custom action however, to retrieve the data from the custom table.
 If the second is using some dynamic data source then it will probably 
 also require a custom action.  If the data will always be static, then 
 it is just dependent on what you type into the XML for the ListView 
 table.


 Regards,
 Bevan

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] ListView Creation

2013-12-24 Thread Bevan Weiss
Attachments get stripped from this list, you will need to provide a URL or
some other such link to a hosted image.

A ListView only really has two particular pieces of useful information for
each 'row', that being a Value, and an item of Display.
If you want more columns then perhaps you need to rethink the way you're
going about the data.

You could create your own custom table in the MSI and have a unique ID as
one of the fields.
This unique ID is then the 'Value' from the ListView to allow the selection
of an entire row of data from your custom table.

If you want to display all the columns to the user, then what you probably
want to do is concatenate the various fields together and call this the
'item of Display'.


Both options can be done using WiX, the first will likely require a custom
action however, to retrieve the data from the custom table.
If the second is using some dynamic data source then it will probably also
require a custom action.  If the data will always be static, then it is just
dependent on what you type into the XML for the ListView table.


Regards,
Bevan


-Original Message-
Date: Tue, 24 Dec 2013 14:44:53 +0530
From: ak m wixak...@gmail.com
Subject: Re: [WiX-users] ListView Creation

Blair,

Please find the attachment.
My requirement is to create the similar dialog in WIX .

Note:  My req. is to create the setup.msi file with ListView control.

On Tue, Dec 24, 2013 at 2:02 PM, Blair Murri os...@live.com wrote:
 You can do whatever UI you want with a BA in a bundle, or to a certain 
 extend with an EmbeddedUI.

  Date: Tue, 24 Dec 2013 11:37:26 +0530
  From: wixak...@gmail.com
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] ListView Creation
 
  Dear All,
 
  I want to create a Wix UI with ListView .
  ListView should contain the following: Name, No, pincode
 
  Any one please help me on this?
 
  Thanks in Advance...
 
  Anil
 

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Progress Bar

2013-12-17 Thread Bevan Weiss
So you are creating a custom UI?
What Custom Actions are you using?
Have you created your custom actions to return data regarding how much time
they will take to perform?
You need to provide more information than just the UI control code.  You've
mentioned that they show on the UI, this is about all these particular
control blocks are responsible for.
So the problem lies elsewhere.


Bevan

Date: Tue, 17 Dec 2013 16:08:21 +0530
From: Ravishankar ravishankar.krishnasw...@idsfortune.com

Hi,
My installer with 6000+ files(nearly 4500 dll's) and the total registry
entries after i extract using heat.exe is nearly 600,000+ lines.
I have split the Component.wxs into 6 smaller files

When running the installer, the progress bar is not properly displayed,
either the time remaining will show 0 seconds and the progress block will
be maximum or minimum I have included the below code in Progressdlg.wxs
file

/Control Id=ProgressBar Type=ProgressBar X=20 Y=115 Width=330 
Height=20 ProgressBlocks=yes Text=!(loc.ProgressDlgProgressBar)//
//  Subscribe Event=SetProgress Attribute=Progress / //
///Control//
//
//Control Id=TimeRemaining Type=Text X=20 Y=140 
Width=330 Height=15//
//  Subscribe Event=TimeRemaining Attribute=TimeRemaining /
//
///Control//
//
//Control Id=InfoText Type=Text X=20 Y=160 Width=330 
Height=10 NoWrap=yes //
//  Subscribe Event=ActionData Attribute=Text ///
///Control/

Please let me know where the issue and what is the resolution

Thanks and Regards
Ravi Shankar


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Multiple Database installation

2013-12-17 Thread Bevan Weiss
You should find the custom table that the SqlDatabase Custom Action uses,
and then write a Custom Action yourself which will occur before the
SqlDatabase one which populates the custom table with the appropriate data.
If you open the generated MSI with Orca or similar you might find the custom
table already included (although I suspect this table will only be created
at runtime).

If the user will need to input data about the particular databases then this
will need some Custom Action to perform the UI behaviour anyway.. you could
have it populate the SqlDatase custom table at the same time.

Regards,
Bevan

Date: Tue, 17 Dec 2013 19:21:45 +0530
From: Ravishankar ravishankar.krishnasw...@idsfortune.com

Hi,
I have a requirement to install multiple databases with a single installer.
As of now am able to install only 1 Database.

Am using the sql:SqlDatabase Id=TEST/sql:SqlDatabase method of
creating Database.

Please let me know how i can create multiple DB's dynamically(during
installation the user will Input the count)

Thanks and Regards
Ravi Shankar

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX-users Digest, Vol 91, Issue 51

2013-12-14 Thread Bevan Weiss
On 12/13/2013 11:21 PM, Bevan Weiss wrote:
 I would suggest using two separate components for it.
 Each Shortcut is really a file..
 Then each would get its own HKCU registry entry.

 Is your installer PerUser or PerMachine?
 The HKCU entry might not be so appropriate for a PerMachine install.

As I stated below my snippet, I already tried it with a separate component
(complete with another dummy registry entry), but Windows Installer still
does not create the second shortcut.

Maybe the problem is that both Shortcuts actually piggyback on
myapplication.exe in some way - I'm getting one warning when I create my
installer:

  warning LGHT1076 : ICE69: Mismatched component reference. Entry
'ApplicationStartMenuShortcut' of the Shortcut table belongs to
component 'ApplicationShortcut'. However, the formatted string in
column 'Target' references file 'myapplication.exe' which belongs to
component 'myapplication.exe'. Components are in the same feature.

Thanks for pointing out the HKCU thing. The registry entry isn't used for
anything but maybe putting it in HKLM is better since the install is per
machine.

Regards,
Markus Ewald

Yes, this warning is somewhat expected.
As long as the components are in the same feature, and you don't have
conditionals on the components all should be fine.

As long as the Shortcut is being installed to the 'All Users' Start Menu,
then HKLM would be more appropriate I think.

Now that you have a separate component for it, what does the verbose log
tell you about why the component isn't being installed?


Bevan

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Creating two start menu shortcuts for the same executable

2013-12-13 Thread Bevan Weiss
I would suggest using two separate components for it.
Each Shortcut is really a file..
Then each would get its own HKCU registry entry.

Is your installer PerUser or PerMachine?
The HKCU entry might not be so appropriate for a PerMachine install.


Bevan

2013/12/13 Markus Ewald cy...@nuclex.org:
 Hi!

 I'm trying to add a second start menu shortcut to my installer, but it 
 just doesn't add the second shortcut. I can't find any message 
 indicating why in msiexec's install log either.

 DirectoryRef Id=ApplicationProgramsFolder

Component Id=ApplicationShortcut Guid=my-guid

  Shortcut
Id=ApplicationStartMenuShortcut
Name=My Application
Description=My Application Description
Target=[#myapplication.exe]
WorkingDirectory=APPLICATIONROOTDIRECTORY
  /

  Shortcut
Id=ApplicationStartMenuShortcut2
Name=My Application (OpenGL)
Description=My Application Description
Target=[#myapplication.exe]
Arguments=-force-opengl
WorkingDirectory=APPLICATIONROOTDIRECTORY
  /

  RemoveFolder Id=ApplicationProgramsFolder On=uninstall /
  RegistryValue
Root=HKCU Key=Software\Microsoft\MyApplicationName
Name=installed Type=integer Value=1
KeyPath=yes
  /

/Component

 /DirectoryRef

 I've tried creating two components (but for some reason WiX then wants 
 a second registry entry, too, but insists on only a single 
 RemoveFolder /), no success either.

 How can I get my second shortcut to appear in the start menu?

 Regards,
 Markus Ewald

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Getting XmlFile 'Components' to be re-triggered when executing a Change 'install'

2013-11-24 Thread Bevan Weiss
Thanks Blair

The verbose log says that the component is already installed, so it won't
perform any action.
I guess I have to explicitly modify the install action for the appropriate
components?
Is there a WiX standard CA to perform this?  I assume it'd just need to look
at the WiX_InstallState property (I'm sure I've got the naming of that
wrong.. but it has 'Change' when performing a Change install action)

Bevan

Date: Sun, 24 Nov 2013 10:16:43 -0800
From: Blair Murri os...@live.com
Subject: Re: [WiX-users] Getting XmlFile 'Components' to be
re-triggered when executing a Change 'install'

In your verbose log what does MSI's plan say about what it intends to do
with your XmlFile components? What about the features that contain those
components? What are you triggering for repair when you select Change?
 
-Blair
 
 From: kaize...@hotmail.com
 To: wix-users@lists.sourceforge.net
 Date: Sat, 23 Nov 2013 22:52:37 +1100
 Subject: [WiX-users] Getting XmlFile 'Components' to be re-triggered when
executing a Change 'install'
 
 Hi again,
 
 I've got another problem I'd like some help with...
 I need to make some modifications to a web.config file to push in a 
 certificate to use for some Web Service stuff I've got.
 The initial installation of this works beautifully, the web.config 
 file gets modified using the XmlFile custom action under a component.
 However during a 'Change' installation, I would like for the user to 
 be able to choose an alternative certificate.
 
 How would I get the XmlFile 'Components' to be re-installed in this 
 situation, or for the XmlFile CustomAction to be re-called with the 
 appropriate properties (which are already defined in the XmlFile element).

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Calling CustomAction which requires Elevated Privileges from UI PushButton

2013-11-24 Thread Bevan Weiss
Thanks again Blair,

I do really like this idea... and would have actually gone this way, if I
hadn't now got the UI elevation working..  yeah it has the ugly black CMD
line box.. but it's only for a second, and they have asked for a new
certificate to be generated, so I'm ok with this UI imperfection.  The only
drawback I can see to performing the generation post UI is that if something
goes wrong with the generation it makes the workflow quite a lot more
complicated.

I don't have a blog or anything.. does WiX have anywhere (other than
personal blogs) to just put code examples and the such?
Perhaps people would find some of the stuff I've done for this installer
useful.. (and I'm sure there are quite a few others that have similar
deveopments)

I've created:
Certificate combobox populator, setup parameters for STORE_NAME and
STORE_LOCATION and it just does its thing (if immediate CAs could take
CustomData it would be a little cleaner)
Iis Certificate Binding, give it a STORE_NAME, STORE_LOCATION and
Certificate Thumbprint along with a Web Site Name and Port Number and it'll
bind the certificate to the website.


Regards,
Bevan

Date: Sun, 24 Nov 2013 09:55:29 -0800
From: Blair Murri os...@live.com
Subject: Re: [WiX-users] Calling CustomAction which requires Elevated
   Privileges from UI PushButton

How about this idea:
 
Let the user select a cert to use, or alternately, select to generate a
self-signed cert.
 
Then, in the execute sequence, generate the self-signed cert and use it.
 
No UI sequence elevation required.
 
It will require an immediate custom action in the execute sequence to add
the generated cert's details to the appropriate table, and thus will also
require using either the InstallExecute or InstallExecuteAgain standard
action between the cert-creation and the
cert-insertion-into-appropriate-tables actions.
 
See Bob's semi custom action blog entry for the general idea of immediate
actions adding rows to tables.
 
-Blair

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Getting XmlFile 'Components' to be re-triggered when executing a Change 'install'

2013-11-23 Thread Bevan Weiss
Hi again,

I've got another problem I'd like some help with...
I need to make some modifications to a web.config file to push in a
certificate to use for some Web Service stuff I've got.
The initial installation of this works beautifully, the web.config file gets
modified using the XmlFile custom action under a component.
However during a 'Change' installation, I would like for the user to be able
to choose an alternative certificate.

How would I get the XmlFile 'Components' to be re-installed in this
situation, or for the XmlFile CustomAction to be re-called with the
appropriate properties (which are already defined in the XmlFile element).


Regards,
Bevan Weiss

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Calling CustomAction which requires Elevated

2013-11-23 Thread Bevan Weiss
Ok.. so it seems staying in the MSI process and getting elevated privileges
just isn't possible, which explains why this doesn't work at all (since it's
using the 'immediate' execution, which runs in the MSI process)..

Next plan... I'd like to create an executable which will perform this work,
and also elevate itself if required.
I would like to get the WIX UI immediate action to execute this EXE (out of
process).  Is this possible?

Is there any way of embedding a binary exe into the MSI, so that it can be
called, without it actually getting installed?


Regards,
Bevan


Date: Sat, 23 Nov 2013 18:34:55 +1100
From: Bevan Weiss kaize...@hotmail.com

Hi all,

I'm trying to create a WIX installer which allows a user to select a
certificate to use for a Web Site SSL binding.
However, if they don't have a valid certificate installed yet (just looking
in the Local Machine, My certificate store) then I'd like them to be able to
generate a Self-Signed Certificate from within the UI.

I've got a CA which will happily generate a Self-Signed Certificate,
however I don't seem to be able to get the elevated privileges unless I
actually execute the MSI from an elevated command line.
I've tried the following:
1) Setting the ElevationShield=yes on the PushButton which calls the CA
(this looks spot on.. but doesn't appear to change anything regards actually
Elevation status)
2) Setting the Impersonate=no setting on the CustomAction (which
references the CA .dll that I've created).

Is there anything more obvious that I'm missing?
I do have InstallPrivileges=elevated set on the overall Package.. and
InstallScope=perMachine

I'm sure some of you have even done this successfully before.. would love
to know how.


Regards,
Bevan Weiss
*

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX-users Digest, Vol 90, Issue 108

2013-11-23 Thread Bevan Weiss
Thanks Phil,
It's an installer for Web Services.  So there really isn't any 'first run'
or anything at all really...
Install, and then it should just operate for eternity.

Is it possible to put elevated privileges as a package condition?  Then if
the MSI is run without them I could just error out and prompt the user to
launch 'as Administrator'.
Not the nicest solution, but it's a possible work-around.  They would need
Admin credentials to perform the install anyway...



-Original Message-
Date: Sat, 23 Nov 2013 11:19:11 -0800
From: Phil Wilson phildgwil...@gmail.com
Subject: Re: [WiX-users] Calling CustomAction which requires Elevated
Privileges from UI PushButton

The problem is that the UI sequence runs with installing user credentials,
so if elevation is required it must come at launch time. If you were to
shell execute an external process that asked for elevation it should work
but the workflow would probably be terrible.
This is one of those tasks that should be encouraged to be part of
configuration done by the app at first run, by an administrator, if that's
possible in your scenario - some things like this just aren't very easy in
the UAC world.

Phil Wilson


On Fri, Nov 22, 2013 at 11:34 PM, Bevan Weiss kaize...@hotmail.com wrote:

 Hi all,

 I'm trying to create a WIX installer which allows a user to select a 
 certificate to use for a Web Site SSL binding.
 However, if they don't have a valid certificate installed yet (just 
 looking in the Local Machine, My certificate store) then I'd like them 
 to be able to generate a Self-Signed Certificate from within the UI.

 I've got a CA which will happily generate a Self-Signed Certificate, 
 however I don't seem to be able to get the elevated privileges unless 
 I actually execute the MSI from an elevated command line.
 I've tried the following:
 1) Setting the ElevationShield=yes on the PushButton which calls the 
 CA (this looks spot on.. but doesn't appear to change anything regards 
 actually Elevation status)
 2) Setting the Impersonate=no setting on the CustomAction (which 
 references the CA .dll that I've created).

 Is there anything more obvious that I'm missing?
 I do have InstallPrivileges=elevated set on the overall Package.. 
 and InstallScope=perMachine

 I'm sure some of you have even done this successfully before.. would 
 love to know how.

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Calling CustomAction which requires Elevated Privileges from UI PushButton

2013-11-22 Thread Bevan Weiss
Hi all,

I'm trying to create a WIX installer which allows a user to select a
certificate to use for a Web Site SSL binding.
However, if they don't have a valid certificate installed yet (just looking
in the Local Machine, My certificate store) then I'd like them to be able to
generate a Self-Signed Certificate from within the UI.

I've got a CA which will happily generate a Self-Signed Certificate, however
I don't seem to be able to get the elevated privileges unless I actually
execute the MSI from an elevated command line.
I've tried the following:
1) Setting the ElevationShield=yes on the PushButton which calls the CA
(this looks spot on.. but doesn't appear to change anything regards actually
Elevation status)
2) Setting the Impersonate=no setting on the CustomAction (which
references the CA .dll that I've created).

Is there anything more obvious that I'm missing?
I do have InstallPrivileges=elevated set on the overall Package.. and
InstallScope=perMachine

I'm sure some of you have even done this successfully before.. would love to
know how.


Regards,
Bevan Weiss

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Web.config file issues when using Heat with multiple Web Application Projects

2013-09-16 Thread Bevan Weiss
To close the loop on this, I finally got it working..
I now have the following for the BeforeBuild Target

Target Name=BeforeBuild
  MSBuild Projects=%(ProjectReference.FullPath) Targets=Package 
   Properties=Configuration=$(Configuration);Platform=AnyCPU
   Condition='(ProjectReference.WebProject)'=='True' /
  ItemGroup
LinkerBindInputPaths
Condition='%(ProjectReference.WebProject)'=='True'
  
Include=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\
/
WebPackageDirs Condition='%(ProjectReference.WebProject)'=='True'
  
Include=%(ProjectReference.Name).WebPackageDir=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp
/
  /ItemGroup

  PropertyGroup
DefineConstants@(DefineConstants);@(WebPackageDirs)/DefineConstants
  /PropertyGroup
  HeatDirectory OutputFile=%(ProjectReference.Filename).wxs

Directory=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp
 DirectoryRefId=%(ProjectReference.RefTargetDir)
 ComponentGroupName=%(ProjectReference.Filename)_Project
 AutogenerateGuids=true
 SuppressCom=true
 SuppressFragments=true
 SuppressRegistry=true
 SuppressRootDirectory=true
 ToolPath=$(WixToolPath)

PreprocessorVariable=var.%(ProjectReference.Name).WebPackageDir
 Condition='%(ProjectReference.WebProject)'=='True' /
/Target

I hope this information can help someone else that might try to deploy
multiple Web Apps using WiX.


Regards,
Bevan Weiss


Thanks Blair,
That's what I'm now trying to do.  However I guess this has become a bit of
an MSBuild type issue in that I'm trying to dynamically create the Candle
defines, but struggling.

Is there any good guidance available on this?


Thanks again,
Bevan


Blair Murri-3 wrote
 The PreprocessorVariable can be set to var.MyVarForThisDir as well as
 wix.MyVarForThisDir. The former needs to be passed to candle, the later
 can be either passed to light or defined in one of your other WXS sources.
 http://stackoverflow.com/questions/1773830/wix-how-to-handle-project-references-when-using-heats-output-with-candleprovides
 a couple of tips.
 From: Bevan Weiss
 Subject: Re: [WiX-users] Web.config file issues when using Heat with
 multiple Web Application Projects
 
 Hi Blair,Thanks for the reply.My DirectoryRefId for each WebApp is
 different, and they are then located in different directories in the
 final install (this part is working ok, all the other files for the
 WebApps are installing correctly)
 After install I am getting four Web.config files installed in different
 directories, but they are all the same (whilst in the source they are all
 different).I understand this is related to the Source being set
 identically (by Heat).  But I'm not sure how to get Heat to output a
 different Source format.  Other than using the PreprocessorVariable, but
 this only seems to allow Wix Variables to be introduced, and then I'm
 struggling to find a way to get all the additional wix variables defined
 in the Candle command line (from within msbuild).
 If I change the Directory for Heat then it starts to Harvest too many
 files, and inserts extra Directory elements in the wxs that I don't want
 (and it seems wrong to have to post-process the Heat output).
 How would people normally do this?Would it be more common to do this
 deployment from individual msi files, and then running an overall msi
 which just 'bootloads' these other installers?
 
 Regards,Bevan Weiss





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Web-config-file-issues-when-using-Heat-with-multiple-Web-Application-Projects-tp7588913p7588979.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Web.config file issues when using Heat with multiple Web Application Projects

2013-09-15 Thread Bevan Weiss
Thanks Blair,
That's what I'm now trying to do.  However I guess this has become a bit of
an MSBuild type issue in that I'm trying to dynamically create the Candle
defines, but struggling.

Is there any good guidance available on this?


Thanks again,
Bevan


The PreprocessorVariable can be set to var.MyVarForThisDir as well as
wix.MyVarForThisDir. The former needs to be passed to candle, the later can
be either passed to light or defined in one of your other WXS sources.
http://stackoverflow.com/questions/1773830/wix-how-to-handle-project-references-when-using-heats-output-with-candleprovides
a couple of tips.
 From: Bevan Weiss
 Subject: Re: [WiX-users] Web.config file issues when using Heat with
 multiple Web Application Projects
 
 Hi Blair,Thanks for the reply.My DirectoryRefId for each WebApp is
 different, and they are then located in different directories in the final
 install (this part is working ok, all the other files for the WebApps are
 installing correctly)
 After install I am getting four Web.config files installed in different
 directories, but they are all the same (whilst in the source they are all
 different).I understand this is related to the Source being set
 identically (by Heat).  But I'm not sure how to get Heat to output a
 different Source format.  Other than using the PreprocessorVariable, but
 this only seems to allow Wix Variables to be introduced, and then I'm
 struggling to find a way to get all the additional wix variables defined
 in the Candle command line (from within msbuild).
 If I change the Directory for Heat then it starts to Harvest too many
 files, and inserts extra Directory elements in the wxs that I don't want
 (and it seems wrong to have to post-process the Heat output).
 How would people normally do this?Would it be more common to do this
 deployment from individual msi files, and then running an overall msi
 which just 'bootloads' these other installers?
 
 Regards,Bevan Weiss



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Web-config-file-issues-when-using-Heat-with-multiple-Web-Application-Projects-tp7588913p7588974.html
Sent from the wix-users mailing list archive at Nabble.com.

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Web.config file issues when using Heat with multiple Web Application Projects

2013-09-14 Thread Bevan Weiss
Hi Blair,Thanks for the reply.My DirectoryRefId for each WebApp is different, 
and they are then located in different directories in the final install (this 
part is working ok, all the other files for the WebApps are installing 
correctly)
After install I am getting four Web.config files installed in different 
directories, but they are all the same (whilst in the source they are all 
different).I understand this is related to the Source being set identically (by 
Heat).  But I'm not sure how to get Heat to output a different Source format.  
Other than using the PreprocessorVariable, but this only seems to allow Wix 
Variables to be introduced, and then I'm struggling to find a way to get all 
the additional wix variables defined in the Candle command line (from within 
msbuild).
If I change the Directory for Heat then it starts to Harvest too many files, 
and inserts extra Directory elements in the wxs that I don't want (and it seems 
wrong to have to post-process the Heat output).
How would people normally do this?Would it be more common to do this deployment 
from individual msi files, and then running an overall msi which just 
'bootloads' these other installers?

Regards,Bevan Weiss

 Date: Fri, 13 Sep 2013 19:03:58 -0700
 From: Blair Murri os...@live.com
 Subject: Re: [WiX-users] Web.config file issues when using Heat with
   multiple Web Application Projects
 
 Is your RefTargetDir different on each of your ProjectReference elements or 
 are they all the same?
 
  From: Bevan Weiss
  Subject: [WiX-users] Web.config file issues when using Heat with multiple   
  Web Application Projects
  
  Hi all,
  
  I'm currently trying to put together an installer which will deploy 4 Web
  Applications to a set of servers.
  
  This means there are 4 separate Web Application directories with 4 separate
  (and different) versions of the Web.config file.
  
  I'm using Heat to generate the .wxs files for the Web Applications, however
  it only appears to be giving each instance of the Web.config File the
  Source=SourceDir\Web.config, which I believe is resulting in only the
  first Web.config being used for each of the Web Applications (which is
  causing the other three to not work).
  
  I'm also using Visual Studio 2012, and Votive (I believe..).  So I've got
  the following at the end of my .wixproj file
  
Import Project=$(WixTargetsPath) /
  
Target Name=BeforeBuild
  
  MSBuild Projects=%(ProjectReference.FullPath) Targets=Package
  Properties=Configuration=$(Configuration);Platform=AnyCPU
  Condition='%(ProjectReference.WebProject)'=='True' /
  
  ItemGroup
LinkerBindInputPaths
  Include=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Confi
  guration)\Package\PackageTmp\ /
  /ItemGroup
  
  PropertyGroup
DefineConstants Condition='%(ProjectReference.WebProject)'=='True'
  $(DefineConstants);%(ProjectReference.Name).PackageDir=%(ProjectReference.Ro
  otDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\
/DefineConstants 
  /PropertyGroup
  
  HeatDirectory OutputFile=%(ProjectReference.Filename).wxs
  Directory=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Con
  figuration)\Package\PackageTmp
 DirectoryRefId=%(ProjectReference.RefTargetDir)
 ComponentGroupName=%(ProjectReference.Filename)_Project
 AutogenerateGuids=true
 SuppressCom=true
 SuppressFragments=true
 SuppressRegistry=true
 SuppressRootDirectory=true
  PreprocessorVariable=wix.%(ProjectReference.Name).PackageDir=%(ProjectRefer
  ence.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\Packa
  geTmp
 ToolPath=$(WixToolPath)
 Condition='%(ProjectReference.WebProject)'=='True' /
  
/Target
  
  /Project
  
  The PreprocessorVariable stuff on the HeatDirectory action is my attempt at
  fixing the issue.  However I don't seem to be able to get the
  DefineConstants working properly (it's only ever assigning one path, not the
  remaining three).  The initial version (which I found via google searches),
  didn't have any PreprocessorVariable, and had the exact issue I mention
  above.  This new version appears better (has unique Source paths), but
  doesn't compile because of the lacking Defines.
  
  I can attach the actual .wxs file outputs if desired, however I didn't think
  they would be so beneficial to send just yet.  I would have expected others
  would have come upon this issue before..
  
  Unless it's something that a recent version of WiX has brought up.  I'm
  running v3.7.
  
  Any help would be greatly appreciated.
  
  Regards,
  
  Bevan Weiss
  
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just

[WiX-users] Web.config file issues when using Heat with multiple Web Application Projects

2013-09-12 Thread Bevan Weiss
Hi all,

 

I'm currently trying to put together an installer which will deploy 4 Web
Applications to a set of servers.

This means there are 4 separate Web Application directories with 4 separate
(and different) versions of the Web.config file.

 

I'm using Heat to generate the .wxs files for the Web Applications, however
it only appears to be giving each instance of the Web.config File the
Source=SourceDir\Web.config, which I believe is resulting in only the
first Web.config being used for each of the Web Applications (which is
causing the other three to not work).

 

I'm also using Visual Studio 2012, and Votive (I believe..).  So I've got
the following at the end of my .wixproj file

.

  Import Project=$(WixTargetsPath) /

  Target Name=BeforeBuild

MSBuild Projects=%(ProjectReference.FullPath) Targets=Package
Properties=Configuration=$(Configuration);Platform=AnyCPU
Condition='%(ProjectReference.WebProject)'=='True' /

ItemGroup

  LinkerBindInputPaths
Include=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Confi
guration)\Package\PackageTmp\ /

/ItemGroup

PropertyGroup

  DefineConstants Condition='%(ProjectReference.WebProject)'=='True'

$(DefineConstants);%(ProjectReference.Name).PackageDir=%(ProjectReference.Ro
otDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\

  /DefineConstants 

/PropertyGroup

 

HeatDirectory OutputFile=%(ProjectReference.Filename).wxs

 
Directory=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Con
figuration)\Package\PackageTmp

   DirectoryRefId=%(ProjectReference.RefTargetDir)

   ComponentGroupName=%(ProjectReference.Filename)_Project

   AutogenerateGuids=true

   SuppressCom=true

   SuppressFragments=true

   SuppressRegistry=true

   SuppressRootDirectory=true

 
PreprocessorVariable=wix.%(ProjectReference.Name).PackageDir=%(ProjectRefer
ence.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\Packa
geTmp

   ToolPath=$(WixToolPath)

   Condition='%(ProjectReference.WebProject)'=='True' /

  /Target

/Project

 

The PreprocessorVariable stuff on the HeatDirectory action is my attempt at
fixing the issue.  However I don't seem to be able to get the
DefineConstants working properly (it's only ever assigning one path, not the
remaining three).  The initial version (which I found via google searches),
didn't have any PreprocessorVariable, and had the exact issue I mention
above.  This new version appears better (has unique Source paths), but
doesn't compile because of the lacking Defines.

 

I can attach the actual .wxs file outputs if desired, however I didn't think
they would be so beneficial to send just yet.  I would have expected others
would have come upon this issue before..

Unless it's something that a recent version of WiX has brought up.  I'm
running v3.7.

 

Any help would be greatly appreciated.

 

 

Regards,

Bevan Weiss

 

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users