[WiX-users] Managed Custom Actions
Hi - We have managed custom actions in our setup. And now that we are getting ready to ship - I have realised that we need to sign the managed dll and pack that inside the native CA.dll. So far I have not had luck modifying the wix.ca.targets file to split the build process into two parts to give me time to binplace correct signed managed dll's. Anyone else do this or have any other ideas as to how we can accomplish this. -- Regards Deepa -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Actions
I'm wondering where this requirement comes from. If the Native CA is signed, why does it matter in an assembly that is stored inside of it is signed or not? You can't tamper with the managed assembly without invalidating the signature of the signed native assembly. Either way, if you can't think of a way to inject this into the wix.ca.targets ( I haven't looked myself ) then you can simpy choose not to use wix.ca.targets. After all, it's just some automation to call makesfxca.exe. You can switch back to standard charp.targets and then wire in your own postbuild events to sign the assembly and call makesfxca manually to create the native CA dll. From: "Deepa Choundappan" Sent: Saturday, November 05, 2011 11:53 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Actions Hi - We have managed custom actions in our setup. And now that we are getting ready to ship - I have realised that we need to sign the managed dll and pack that inside the native CA.dll. So far I have not had luck modifying the wix.ca.targets file to split the build process into two parts to give me time to binplace correct signed managed dll's. Anyone else do this or have any other ideas as to how we can accomplish this. -- Regards Deepa -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dependencies between components
If two components must be always be installed/removed together, I don't see why they can't be in all the same features. If one of the components depends on another but the dependency is not mutual, you could make a hidden feature that also contains the dependent component and use a custom action to enable that feature based on the depending component's action state. -Blair > Date: Fri, 4 Nov 2011 13:10:57 +0100 > From: steffen@googlemail.com > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Dependencies between components > > Hi, > > I would like to define that one component can't be installed without the > other, without them being in the same feature. Is there any possibility to > define dependencies between components or component groups? > > or ist there any other approach to realise such a dependency? > > thanks in advance > > Steffen > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Antwort: Re: What happend to minor upgrade using wix
Actually, the only difference between minor upgrades and small updates is patch/transform applicability. UpgradeCode, the Upgrade table, the FindRelatedProducts and RemoveExistingProducts actions are all ignored/suppressed, and as a result ProductVersion is also ignored (except for "assigning" the last-used ProductVersion to be the product's version if the transaction is successful). You were possibly using a bootstrapper of some sort with InstallShield. Otherwise double-clicking your MSI will always produce the "This product is already installed" error message if any package with the same ProductCode is already installed. If that wasn't the case with your InstallShield MSIs then you were not using what Windows Installer calls "minor upgrade" after all. The above is the reason that small update packages can produce broken downgrades (depending on the value of REINSTALLMODE) . That is one possible reason that minor upgrades require explicitly setting the REINSTALL and REINSTALMODE properties (so you will be forced bootstrap it to make sure what you intend to happen will happen). Don't let the words "major" and "minor" wrt Windows Installer fool you. In my experience major upgrades tend to always be the simplest kinds of upgrades to do. If you are worried about it you can minimize the work that the upgrade performs by always following the component rules and always conditioning your custom actions' activities on component states, coupled with "late" scheduling of RemoveExistingProducts. And since UpgradeCode is never used in a non-major upgrade, I don't understand what can ever go wrong by supplying one. -Blair > To: wix-users@lists.sourceforge.net > From: thomas.debo...@rohde-schwarz.com > Date: Fri, 4 Nov 2011 16:30:51 +0100 > Subject: [WiX-users] Antwort: Re: What happend to minor upgrade using wix > > Hi Mat, > > thanks for the hint with the tree version numbers. I will try by changing > the third number. > Just to clarify. I had used in InstallShield pure MSI packages. > > Cheers, > Thomas > > > > Von:"Skildum, Mathew" > An: "General discussion for Windows Installer XML toolset." > > Datum: 04.11.2011 15:28 > Betreff:Re: [WiX-users] What happend to minor upgrade using wix > > > > The main problem I see here is your versioning scheme. MSI only supports > the first three places in the version number (X.X.X) and ignores the > fourth position. Any version changes need to take place in the first > three positions for MSI to recognize a version change. For more > information please refer to the MSI, and Microsoft, documentation on > versions and use of versioning. > > You cannot compare what you do in legacy InstallShield (InstallScript) and > MSI as they are two different install engines. InstallScript based > installs use all four places in the version when it does version compares. > When moving from InstallScript to MSI (WIX), or any install engine for > that matter, you must be aware of the behavior differences and adjust your > development rules accordingly. > > Mat Skildum > > > > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best strategy for optional file removal on uninstall
As I understand it, within a transaction you can only manipulate database columns and rows that are marked "temporary" (because they don't exist in the MSI itself) [see http://msdn.microsoft.com/library/aa367457.aspx]. So, instead of removing rows, you will need to add them in the cases where you don't want to leave them behind. The easiest way to do that from my perspective is to create a table of your own with the same schema as the RemoveFile table, maybe adding a condition column, and then use a custom action to "copy" rows from your table to the RemoveFile table (based on the condition?) in the manner described in the dynamic combo box idea.Alternately, you can assign the files you may not want to remove to one or more components that you force to an action state of "unknown" (thereby preventing their "removal") when you uninstall via your custom action when you wish to suppress their removal (which will allow you to avoid parallel tables).Blair > Date: Thu, 3 Nov 2011 21:34:40 +0100 > From: trent.stens...@gmail.com > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Best strategy for optional file removal on uninstall > > During my products lifetime there are a lot of files that will have been > created in my applications bin folder, for example .config files. I > currently just remove them at uninstall by having entries in the RemoveFile > table. > > I would on occasion like to be able to leave the files behind on uninstall > and I first thought I'd stop using the RemoveFile table and instead delete > the files from a Custom Action (which I could have a condition on). > > After Googeling for a while, I found this thread about dynamically > populating a ComboBox. Can I use a similar trick on uninstall (i.e. > deleting one or more entries in the RemoveFile table). > > Not 100% sure how the syntax would be, so though I'd ask first in case this > isn't possible. > > Regards > Trent > PS > Sorry to those of you that are members of the WiX-devs, didn't notice that > I'd signed up to the wrong group before I posted it there. > -- > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcuts in the All Users Start Menu
Has no-one else had this problem that users can't click on shortcuts placed in the start menu when the ALLUSERS property is set to 1? Maybe it is relevant but this is happening on Windows 7 32-bit, I don't have an oppertunity to test how this works on other platforms. Kjartan Frá: Kjartan Þór Kjartansson [kjartan.thor.kjartans...@islandsbanki.is] Sent: 3. nóvember 2011 09:18 Viðtakandi: General discussion for Windows Installer XML toolset. Efni: Re: [WiX-users] Shortcuts in the All Users Start Menu Not being able to modify the shortcut is what I expected but no permissions at all, i.e. not being able to see it as a shortcut only as a file that the user can't double click to start or even have permissions to see it's icon, that is not what I expected. Kjartan -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 3. nóvember 2011 01:19 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Shortcuts in the All Users Start Menu On 02-Nov-11 09:10, Kjartan Þór Kjartansson wrote: > I have a wix project that places a shortcut in a subfolder in the users start > menu, when I change the source to set the ALLUSERS property to 1 I get the > shortcut in the correct place but the permissions of the shortcut are > incorrect resulting in users not having access to the shortcut. Only system > and the installer service account have permissions for the shortcut. That's expected: It's in a per-machine location so normal users can't modify them. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
