Re: [WiX-users] Does patch removal restore removed data files?
I think that now I understand what happened. My expectation about patching system behavior when component is transitive was wrong. During patch application, transitive component condition gets evaluated and, if it has changed from true to false, component gets deleted. However, to facilitate patch removal (which means that deleted component must be restored), the system doesn't cache the component somewhere. The patch that deletes the component cannot be removed in every case, without access to the original MSI. In one case when I had patch removal appear to restore the deleted component, it was because I have already patched the component once before its removal. So it existed in baseline cache and original MSI was not needed. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to uninstall other products during uninstallation
After i execute function
MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
i've found following lines in log related to addOnTool:
Command Line: ADDLOCAL=addOnTool CURRENTDIRECTORY=...
...
PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'addOnTool'.
...
Feature: addOnTool; Installed: Absent; Request: Null; Action: Null
...
In final Property list i've found following interesting lines:
Property(S): ProductState = 5
Property(S): ProductToBeRegistered = 1
Property(S): ADDLOCAL = StatsPlg
Property(S): ACTION = INSTALL
Property(S): INSTALLLEVEL = 1
Does it make any sense? Is there anything else i should look for?
IMHO does MsiConfigureFeature nothing. It just adds ADDLOCAL property,
but with no further effects. MSI installs mainApp product (level 1) and
leaves addOnTool untouched (level 0).
Jan
Blair wrote:
> Turn on verbose logging via the installer logging policy. What are the
> values of the feature-related properties? What happens to feature/component
> states?
>
> -Original Message-
> From: Jan Bilek [mailto:bil...@gmail.com]
> Sent: Friday, January 22, 2010 2:47 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to uninstall other products during
> uninstallation
>
> Huge thanks... this definitely seems to be a solution, but when i try
> use it, i find following problem:
>
> I've 2 features in my wix project:
>
> ...
> ...
>
> "addOnTool" does not get installed during the installation when
> conditions are not met. I use following line to install it from main
> application:
>
> MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
>
> It should install the missing feature, but all it does is to run the
> whole installation again. But, surprisingly, it does not install
> "addOnTool" feature. I tried to use different installation state
> parameters, but with no success.
>
> Do you have an idea, where could be a problem?
>
> Regards,
> Jan
>
>
>
>
>
>
> Blair wrote:
>
>> If you run that API from your main app, the entire installation
>>
> transaction
>
>> will run, but only the indicated feature (and whatever components that
>>
> were
>
>> not previously installed that are part of that feature) will be "selected"
>> for installation, meaning that only those files/registry entries/etc. will
>> actually be installed. The main app's components, since they were already
>> installed, won't be reinstalled.
>>
>> If any custom actions you have in that MSI are tied to component or
>>
> feature
>
>> states, they will be included/skipped as appropriate. If other conditions
>> control them, then what happens depends on those conditions.
>>
>> That API effectively runs the transaction engine with the ADDLOCAL
>>
> property
>
>> set to the indicated feature when the feature is not already installed.
>>
>> -Original Message-
>> From: Jan Bilek [mailto:bil...@gmail.com]
>> Sent: Thursday, January 21, 2010 9:20 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] How to uninstall other products during
>> uninstallation
>>
>> But what will happen when main app detects that .net conditions are met?
>> How will it install only the add-on tool? Is there any possibility to
>> install certain product features (not the main app again) when main
>> installation file was deleted?
>>
>> Thanks for reply.
>>
>> Jan
>>
>>
>> Blair wrote:
>>
>>
>>> My reference to the API MsiConfigureFeature() was intended to have it
>>>
>>>
>> called
>>
>>
>>> by the main application whenever it detects that the add-on isn't
>>>
>>>
>> installed
>>
>>
>>> but the framework is. End users don't have to do a thing (except run the
>>> main application).
>>>
>>> -Original Message-
>>> From: Jan Bilek [mailto:bil...@gmail.com]
>>> Sent: Wednesday, January 20, 2010 12:34 PM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] How to uninstall other products during
>>> uninstallation
>>>
>>> Good idea, but what if user decides to install the add-on later (after
>>> he updates his OS)? Wouldn't he have to reinstall main application? This
>>> solution is my last resort. It will work, but it seems to be too
>>> complicated (for me and users aswell).
>>> Isn't there any other easier way?
>>>
>>> Thanks.
>>>
>>> Jan
>>>
>>>
>>> Blair wrote:
>>>
>>>
>>>
Put both into the same MSI, but under different features.
>From your main application, add the "add-on" feature when .net 3.5 is
discovered. MsiConfigureFeature() would possibly be a good candidate.
-Original Message-
From: Jan Bilek [mailto:bil...@gmail.com]
Sent: Wednesday, January 20, 2010 7:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to uninstall other products during
>>
[WiX-users] Linked / relative files in referenced projects causing build to fail
Getting; Error 2 The Directory/@Name attribute's value, '..', is not a valid long name because it contains illegal characters. Legal long names contain no more than 260 characters and must contain at least one non-period character. Any character except for the follow may be used: \ ? | > < : / * ". D:\Projects\xxx\trunk\Source\yyy\myInstaller\obj\Debug\_zz.wxs 53 1 It seems it is from a project reference that links (not the normal Visual Studio include) to a file two folders up. This is for multiple projects to share the same AssemblyInfo file. Double clicking on the error shows a generated file with the following; Version prior to 3.5.1315 was fine with this but since then there has seems to be some extra checking going on that breaks with relative file references in referenced projects. I'll see if I can dig out my old 3.5 install now as the download links have been tidied up. Ryan -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does patch removal restore removed data files?
That does sound very much like the behavior described here: http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx On Sat, Jan 23, 2010 at 5:12 AM, Tony Juricic wrote: > I think that now I understand what happened. > My expectation about patching system behavior when component is transitive > was wrong. > During patch application, transitive component condition gets evaluated > and, if it has changed from true to false, component gets deleted. However, > to facilitate patch removal (which means that deleted component must be > restored), the system doesn't cache the component somewhere. > The patch that deletes the component cannot be removed in every case, > without access to the original MSI. > In one case when I had patch removal appear to restore the deleted > component, it was because I have already patched the component once before > its removal. So it existed in baseline cache and original MSI was not > needed. > > TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: > TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member > NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading > software and subscription company, and TradeStation Europe Limited, a United > Kingdom, FSA-authorized introducing brokerage firm. None of these companies > provides trading or investment advice, recommendations or endorsements of > any kind. The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Linked / relative files in referenced projects causing build to fail
I'm a little confused. What version of the WiX toolset are you seeing this problem in? If it is the latest build of WiX v3.5, please open a bug because heat should never generate a Directory/@Name=".." On Sat, Jan 23, 2010 at 11:24 AM, Ryan O'Neill wrote: > Getting; > > Error 2 The Directory/@Name attribute's value, '..', is > not a valid long name because it contains illegal characters. Legal long > names contain no more than 260 characters and must contain at least one > non-period character. Any character except for the follow may be used: \ ? > | > < : / * ". > D:\Projects\xxx\trunk\Source\yyy\myInstaller\obj\Debug\_zz.wxs > 53 1 > > > > It seems it is from a project reference that links (not the normal Visual > Studio include) to a file two folders up. This is for multiple projects to > share the same AssemblyInfo file. Double clicking on the error shows a > generated file with the following; > > > > > > Name=".."> > > Name="FolderName"> > > Guid="*"> > > Source="$(var.MyProject.ProjectDir)\..\AssemblyInfo.vb" /> > > > > > > > > > > > > Version prior to 3.5.1315 was fine with this but since then there has seems > to be some extra checking going on that breaks with relative file > references > in referenced projects. > > > > I'll see if I can dig out my old 3.5 install now as the download links have > been tidied up. > > > > Ryan > > > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Linked / relative files in referenced projects causing build to fail
This is build 3.5.1322.0 that it errors in, it also errors in 3.5.1315.0 but the version prior to that is fine (I found it in my recycle bin, so I can compile again now). I'll open a bug then. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 23 January 2010 20:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Linked / relative files in referenced projects causing build to fail I'm a little confused. What version of the WiX toolset are you seeing this problem in? If it is the latest build of WiX v3.5, please open a bug because heat should never generate a Directory/@Name=".." On Sat, Jan 23, 2010 at 11:24 AM, Ryan O'Neill wrote: > Getting; > > Error 2 The Directory/@Name attribute's value, '..', is > not a valid long name because it contains illegal characters. Legal long > names contain no more than 260 characters and must contain at least one > non-period character. Any character except for the follow may be used: \ ? > | > < : / * ". > D:\Projects\xxx\trunk\Source\yyy\myInstaller\obj\Debug\_zz.wxs > 53 1 > > > > It seems it is from a project reference that links (not the normal Visual > Studio include) to a file two folders up. This is for multiple projects to > share the same AssemblyInfo file. Double clicking on the error shows a > generated file with the following; > > > > > > Name=".."> > > Name="FolderName"> > > Guid="*"> > > Source="$(var.MyProject.ProjectDir)\..\AssemblyInfo.vb" /> > > > > > > > > > > > > Version prior to 3.5.1315 was fine with this but since then there has seems > to be some extra checking going on that breaks with relative file > references > in referenced projects. > > > > I'll see if I can dig out my old 3.5 install now as the download links have > been tidied up. > > > > Ryan > > > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to uninstall other products during uninstallation
I think I see what is going on. A level of "0" disables the feature. A
condition could be used to change the level, but conditions are NOT
evaluated when the ADDLOCAL (or any one of several other) property is set.
As a result, the ADDLOCAL is unable to enable that feature.
You need to change the level to some positive (non-zero) integer. You can
then use a condition on that feature to not install the add-on in your
initial transaction if the required framework was not initially installed.
MsiConfigureFeature will then be able to install the feature.
-Original Message-
From: Jan Bilek [mailto:bil...@gmail.com]
Sent: Saturday, January 23, 2010 8:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to uninstall other products during
uninstallation
After i execute function
MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
i've found following lines in log related to addOnTool:
Command Line: ADDLOCAL=addOnTool CURRENTDIRECTORY=...
...
PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'addOnTool'.
...
Feature: addOnTool; Installed: Absent; Request: Null; Action: Null
...
In final Property list i've found following interesting lines:
Property(S): ProductState = 5
Property(S): ProductToBeRegistered = 1
Property(S): ADDLOCAL = StatsPlg
Property(S): ACTION = INSTALL
Property(S): INSTALLLEVEL = 1
Does it make any sense? Is there anything else i should look for?
IMHO does MsiConfigureFeature nothing. It just adds ADDLOCAL property,
but with no further effects. MSI installs mainApp product (level 1) and
leaves addOnTool untouched (level 0).
Jan
Blair wrote:
> Turn on verbose logging via the installer logging policy. What are the
> values of the feature-related properties? What happens to
feature/component
> states?
>
> -Original Message-
> From: Jan Bilek [mailto:bil...@gmail.com]
> Sent: Friday, January 22, 2010 2:47 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to uninstall other products during
> uninstallation
>
> Huge thanks... this definitely seems to be a solution, but when i try
> use it, i find following problem:
>
> I've 2 features in my wix project:
>
> ...
> ...
>
> "addOnTool" does not get installed during the installation when
> conditions are not met. I use following line to install it from main
> application:
>
> MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
>
> It should install the missing feature, but all it does is to run the
> whole installation again. But, surprisingly, it does not install
> "addOnTool" feature. I tried to use different installation state
> parameters, but with no success.
>
> Do you have an idea, where could be a problem?
>
> Regards,
> Jan
>
>
>
>
>
>
> Blair wrote:
>
>> If you run that API from your main app, the entire installation
>>
> transaction
>
>> will run, but only the indicated feature (and whatever components that
>>
> were
>
>> not previously installed that are part of that feature) will be
"selected"
>> for installation, meaning that only those files/registry entries/etc.
will
>> actually be installed. The main app's components, since they were already
>> installed, won't be reinstalled.
>>
>> If any custom actions you have in that MSI are tied to component or
>>
> feature
>
>> states, they will be included/skipped as appropriate. If other conditions
>> control them, then what happens depends on those conditions.
>>
>> That API effectively runs the transaction engine with the ADDLOCAL
>>
> property
>
>> set to the indicated feature when the feature is not already installed.
>>
>> -Original Message-
>> From: Jan Bilek [mailto:bil...@gmail.com]
>> Sent: Thursday, January 21, 2010 9:20 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] How to uninstall other products during
>> uninstallation
>>
>> But what will happen when main app detects that .net conditions are met?
>> How will it install only the add-on tool? Is there any possibility to
>> install certain product features (not the main app again) when main
>> installation file was deleted?
>>
>> Thanks for reply.
>>
>> Jan
>>
>>
>> Blair wrote:
>>
>>
>>> My reference to the API MsiConfigureFeature() was intended to have it
>>>
>>>
>> called
>>
>>
>>> by the main application whenever it detects that the add-on isn't
>>>
>>>
>> installed
>>
>>
>>> but the framework is. End users don't have to do a thing (except run the
>>> main application).
>>>
>>> -Original Message-
>>> From: Jan Bilek [mailto:bil...@gmail.com]
>>> Sent: Wednesday, January 20, 2010 12:34 PM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] How to uninstall other products during
>>> uninstallation
>>>
>>> Good idea, but what if user decides to install the add-on later (after
>>> he up
Re: [WiX-users] How to uninstall other products during uninstallation
So that means that MsiConfigureFeature will just run the installation
again regardless of input parameters. That also means, that it will
attempt to install mainApp along with the addOn (if conditions are
met)... and that's what i don't want to. Installation of mainApp is very
complex and requires reboot.
So is there any way how to:
1) Launch the installation (use MsiConfigureFeature or simular function)
2) Don't allow to install mainApp (set any property and use condition?)
3) Allow addOn to install.
In other words... is there any MSI function, which allows me to set a
property and run the installation again? I tried to browse MSI functions
at MSDN, but didn't find anything suitable.
Thanks for great support!
Kind regards,
Jan
Blair wrote:
> I think I see what is going on. A level of "0" disables the feature. A
> condition could be used to change the level, but conditions are NOT
> evaluated when the ADDLOCAL (or any one of several other) property is set.
> As a result, the ADDLOCAL is unable to enable that feature.
>
> You need to change the level to some positive (non-zero) integer. You can
> then use a condition on that feature to not install the add-on in your
> initial transaction if the required framework was not initially installed.
> MsiConfigureFeature will then be able to install the feature.
>
> -Original Message-
> From: Jan Bilek [mailto:bil...@gmail.com]
> Sent: Saturday, January 23, 2010 8:17 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to uninstall other products during
> uninstallation
>
> After i execute function
>
> MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
>
> i've found following lines in log related to addOnTool:
>
> Command Line: ADDLOCAL=addOnTool CURRENTDIRECTORY=...
> ...
> PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'addOnTool'.
> ...
> Feature: addOnTool; Installed: Absent; Request: Null; Action: Null
> ...
>
> In final Property list i've found following interesting lines:
>
> Property(S): ProductState = 5
> Property(S): ProductToBeRegistered = 1
> Property(S): ADDLOCAL = StatsPlg
> Property(S): ACTION = INSTALL
> Property(S): INSTALLLEVEL = 1
>
>
> Does it make any sense? Is there anything else i should look for?
> IMHO does MsiConfigureFeature nothing. It just adds ADDLOCAL property,
> but with no further effects. MSI installs mainApp product (level 1) and
> leaves addOnTool untouched (level 0).
>
> Jan
>
>
> Blair wrote:
>
>> Turn on verbose logging via the installer logging policy. What are the
>> values of the feature-related properties? What happens to
>>
> feature/component
>
>> states?
>>
>> -Original Message-
>> From: Jan Bilek [mailto:bil...@gmail.com]
>> Sent: Friday, January 22, 2010 2:47 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] How to uninstall other products during
>> uninstallation
>>
>> Huge thanks... this definitely seems to be a solution, but when i try
>> use it, i find following problem:
>>
>> I've 2 features in my wix project:
>>
>> ...
>> ...
>>
>> "addOnTool" does not get installed during the installation when
>> conditions are not met. I use following line to install it from main
>> application:
>>
>> MsiConfigureFeature("PRODUCT-GUID", "addOnTool", INSTALLSTATE_LOCAL);
>>
>> It should install the missing feature, but all it does is to run the
>> whole installation again. But, surprisingly, it does not install
>> "addOnTool" feature. I tried to use different installation state
>> parameters, but with no success.
>>
>> Do you have an idea, where could be a problem?
>>
>> Regards,
>> Jan
>>
>>
>>
>>
>>
>>
>> Blair wrote:
>>
>>
>>> If you run that API from your main app, the entire installation
>>>
>>>
>> transaction
>>
>>
>>> will run, but only the indicated feature (and whatever components that
>>>
>>>
>> were
>>
>>
>>> not previously installed that are part of that feature) will be
>>>
> "selected"
>
>>> for installation, meaning that only those files/registry entries/etc.
>>>
> will
>
>>> actually be installed. The main app's components, since they were already
>>> installed, won't be reinstalled.
>>>
>>> If any custom actions you have in that MSI are tied to component or
>>>
>>>
>> feature
>>
>>
>>> states, they will be included/skipped as appropriate. If other conditions
>>> control them, then what happens depends on those conditions.
>>>
>>> That API effectively runs the transaction engine with the ADDLOCAL
>>>
>>>
>> property
>>
>>
>>> set to the indicated feature when the feature is not already installed.
>>>
>>> -Original Message-
>>> From: Jan Bilek [mailto:bil...@gmail.com]
>>> Sent: Thursday, January 21, 2010 9:20 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] How to uninstall other product
Re: [WiX-users] Msbuild/Votive Change WIX Path
On 1/20/2010 1:19 PM, Blair wrote: > Wix.targets uses the $(WixTasksPath) property, See "Integrating WiX Projects Into Daily Builds" in WiX.chm for more info. -- sig://boB http://joyofsetup.com/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing .NET 4 assemblies into the GAC using WiX 2
On 1/22/2010 7:42 PM, Jacques Eloff wrote: > I just ran into a problem. I created an MSI that contains two assemblies. > Assembly 1 targets .NET 3.5. Assembly 2 targets .NET 4. WiX v2 doesn't target CLR v4. V3.5 does. You can try adding supportedRuntime entries for the v4 runtime, but it hasn't been tested. -- sig://boB http://joyofsetup.com/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running application after install wizard leaves install wizard unclosable
On 1/21/2010 11:51 AM, Reinier Lamers wrote: > Now according to the WiX documentation the condition of Publish is > "optional", but it does not say what it defaults to when it is not > present. I assumed it would default to "1", but apparently it doesn't. > I still don't really understand what it does default to. It looks like > the event is issued only when no other 'Publish' element matches when > you don't specify a condition. > See the MSI SDK for ControlEvent documentation. -- sig://boB http://joyofsetup.com/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Confused by "File in use"
On 1/19/2010 5:23 PM, Robert Barnes wrote: > Which version is the fix in? Is there any info on the web about the bug? Sorry, I don't know. -- sig://boB http://joyofsetup.com/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PropertyRef Id="VS90_ITEMTEMPLATES_DIR"
On 1/17/2010 8:39 PM, Cody Gibson wrote: > Why does this wxs file work (i.e. the single file to install is installed at > the correct location) > Usually, people ask why things don't work. Can you clarify what you're asking? -- sig://boB http://joyofsetup.com/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
