Re: [WiX-users] RegistrySearch problem
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 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: ** 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.
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 >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
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 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
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
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.
I am now able to create the structure under the programdata folder as i
desired. But however while i am uninstalling the folders that get created on
install such as db, gui,security, do not get removed although the registry
keys get removed. On inspecting the log file i could find the below error.
Action start 14:29:08: CostFinalize.
MSI (s) (88:78) [14:29:08:578]: Disallowing uninstallation of component:
{A5A114B9-ECE4-4EFE-8DE7-DA07E024554A} since another client exists
I however could not find any other installation on my system. Could you or
someone please help on this. Its urgent.
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] Avoid .net 3.5 requirement
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" >Subject: Re: [WiX-users] Avoid .net 3.5 requirement > >I have this for my customactions.config > > > > > > > > > >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] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_
a_file.html
Try this..
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
>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
>> 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
>
Re: [WiX-users] (Gentle Reminder)Creating directory under C:\Programdata same as what the user specified in the UI dialogue
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
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
> 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\Pipeli
Re: [WiX-users] Heat.exe harvesting case sensitive vb6 dll's
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 >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] R: How to install VSTO Excel add-in that use dll with COM-visible objects?
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" 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
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 >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 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=121054471&iu=/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
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 >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=121054471&iu=/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
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 > >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=124407151&iu=/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
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
>Subject: [WiX-users] Windows Service windows 7
>
>I created a dummy windows service for my first wix project.
>Ive added
> Guid="A4FA2F01-DC4A-4CA7-995F-56947018EFCE" KeyPath="yes">
>Key="SYSTEM\CurrentControlSet\Services\Eventlog\Application"
>Action="create">
>
> User="LocalSystem"/>
>
>
>and
>
> 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=124407151&iu=/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
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
Subject: Re: [WiX-users] ListView Creation
Hi Bevan Weiss,
Thank you for the information.
My UI looks as in the link
ListViewDlg.JPG<https://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 wrote:
> Instantiating the ListView is easy
>
> X="SomeX" Y="WhyNot?" Width="wide" Height="short" Sorted="yes">
>
>
>
>
>
>
>
> 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=84349831&iu=/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
Instantiating the ListView is easy
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
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 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=84349831&iu=/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
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 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 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=84349831&iu=/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
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 > >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 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=84349831&iu=/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
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 > >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 > >/Height="20" ProgressBlocks="yes" Text="!(loc.ProgressDlgProgressBar)">// >// // >//// >// >//Width="330" Height="15">// >// // >//// >// >//Height="10" NoWrap="yes" >// >// // >/// > >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=84349831&iu=/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
>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=84349831&iu=/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
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 : > 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. > > > > > > Id="ApplicationStartMenuShortcut" >Name="My Application" >Description="My Application Description" >Target="[#myapplication.exe]" >WorkingDirectory="APPLICATIONROOTDIRECTORY" > /> > > Id="ApplicationStartMenuShortcut2" >Name="My Application (OpenGL)" >Description="My Application Description" >Target="[#myapplication.exe]" >Arguments="-force-opengl" >WorkingDirectory="APPLICATIONROOTDIRECTORY" > /> > > > Root="HKCU" Key="Software\Microsoft\MyApplicationName" >Name="installed" Type="integer" Value="1" >KeyPath="yes" > /> > > > > > > I've tried creating two components (but for some reason WiX then wants > a second registry entry, too, but insists on only a single > ), 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=84349831&iu=/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
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 >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=63431311&iu=/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'
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 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=63431311&iu=/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
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 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 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=63431311&iu=/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
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 > >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=63431311&iu=/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'
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=63431311&iu=/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
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=63431311&iu=/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
To close the loop on this, I finally got it working.. I now have the following for the BeforeBuild Target @(DefineConstants);@(WebPackageDirs) 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=58041151&iu=/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
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=64545871&iu=/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
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 > 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 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 > > > > > > > > > > > > > Properties="Configuration=$(Configuration);Platform=AnyCPU" > > Condition="'%(ProjectReference.WebProject)'=='True'" /> > > > > > >> Include="%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Confi > > guration)\Package\PackageTmp\" /> > > > > > > > > > > $(DefineConstants);%(ProjectReference.Name).PackageDir=%(ProjectReference.Ro > > otDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\ > > > > > > > > > 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'" /> > > > > > > > > > > > > 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 act
[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 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 . $(DefineConstants);%(ProjectReference.Name).PackageDir=%(ProjectReference.Ro otDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\ 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=5127&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
