Re: [WiX-users] Inherit permissions on a folder in WiX 3

2007-12-19 Thread Strele Franz
The Permission Extended=yes ... from WiX v2 has been replaced by the
PermissionEx element in WiX v3. Have a look in the Wix.chm for all the
details.

Hth,
Franz



Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Maxim
Vyazovsky
Gesendet: Mittwoch, 19. Dezember 2007 13:33
An: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] Inherit permissions on a folder in WiX 3

any updates? ; )
On Dec 18, 2007 2:09 PM, Maxim Vyazovsky [EMAIL PROTECTED] wrote:
Hi all,
does wix3 support permissions inheritting or it's only the feature of
wix 2 (Extend=yes)? 
If anybody know how to inherit permission in wix 3, please share the
solution.
i searched in maillists but found nothing about wix3.
-- 
Thanks,
Max 



-- 
Thanks,
Max 

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Inherit permissions on a folder in WiX 3

2007-12-19 Thread Strele Franz
My understanding is that PermissionEx is inheriting by default.

For Modify I would use following attributes:

Execute (or Traverse)
Read
ReadAttributes
ReadExtendedAttributes
CreateFile
CreateChild
WriteAttributes
WriteExtendedAttributes
Delete
ReadPermissions


Hth,
Franz



Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Maxim Vyazovsky
Gesendet: Mittwoch, 19. Dezember 2007 14:13
An: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] Inherit permissions on a folder in WiX 3

thank you Franz,
 
but I comapared these elements, and found only next differences:
 
ServiceChangeConfig
ServiceEnumerateDependents
ServiceInterrogate
ServicePauseContinue
ServiceQueryConfig
ServiceQueryStatus
ServiceStart
ServiceStop
ServiceUserDefinedControl
 
but it's nothing about inheritting.
or this element by default inherit permissions?
 
and one more question - what equal attribute in Permission or PermissionEx 
elements for Modify permission ?

-- 
Thanks,
Max 

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] wix 2.0 to 3.0 - COM registration

2007-10-24 Thread Strele Franz
Using registry keys is the recommended way of registering .NET Assemblies for 
COM Interop.

http://msdn2.microsoft.com/en-us/library/aa367520.aspx

Use the Registry table instead of the Class table when you register COM 
Interop for an assembly.


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Karim MacDonald
 Gesendet: Mittwoch, 24. Oktober 2007 16:26
 An: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration
 
 
 
 Nitin Chaudhari wrote:
 
  All my DLL's are .net assembly but they can be registered as COM.
 
 Sorry, I should've looked more closely at your registry entries. FWIW,
 here's my take on the problem:
 
 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-
 generated-registry-data-tf2815472.html#a13239912
 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-
 generated-registry-data-tf2815472.html#a13239912
 
 I think that the problem is shared between heat.exe and candle.exe, and
 came
 to the conclusion that unless WiX is tweaked to specifically consider
 COM-registerable .NET assemblies then large numbers of registry keys
 end up
 being the cleanest solution.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] wix 2.0 to 3.0 - COM registration

2007-10-24 Thread Strele Franz
You can use the 'undocumented' -scom switch with heat.exe to generate only 
RegistryKey/RegistryValue-entries (instead of Class/ProgId/...).



 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Strele Franz
 Gesendet: Mittwoch, 24. Oktober 2007 16:48
 An: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration
 
 Using registry keys is the recommended way of registering .NET
 Assemblies for COM Interop.
 
 http://msdn2.microsoft.com/en-us/library/aa367520.aspx
 
 Use the Registry table instead of the Class table when you register
 COM Interop for an assembly.
 
 
  -Ursprüngliche Nachricht-
  Von: [EMAIL PROTECTED] [mailto:wix-users-
  [EMAIL PROTECTED] Im Auftrag von Karim MacDonald
  Gesendet: Mittwoch, 24. Oktober 2007 16:26
  An: wix-users@lists.sourceforge.net
  Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration
 
 
 
  Nitin Chaudhari wrote:
  
   All my DLL's are .net assembly but they can be registered as COM.
  
  Sorry, I should've looked more closely at your registry entries.
 FWIW,
  here's my take on the problem:
 
  http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-
 on-
  generated-registry-data-tf2815472.html#a13239912
  http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-
 on-
  generated-registry-data-tf2815472.html#a13239912
 
  I think that the problem is shared between heat.exe and candle.exe,
 and
  came
  to the conclusion that unless WiX is tweaked to specifically consider
  COM-registerable .NET assemblies then large numbers of registry keys
  end up
  being the cleanest solution.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] NOT PRIVILEDGED Condition

2007-10-16 Thread Strele Franz
Properties are case sensitive (and you have a spelling error too). You need to 
use NOT Privileged.

Condition Message=You need to be Administrator to install this add-in.NOT 
Privileged/Condition


Hth,
Franz



Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Nitin Chaudhari
Gesendet: Dienstag, 16. Oktober 2007 14:36
An: wix-users@lists.sourceforge.net
Betreff: [WiX-users] NOT PRIVILEDGED Condition

Hi,

I created a default Limited user account in windows XP and my wxs has 
Condition Message=You need to be Administrator to install this add-in.NOT 
PRIVILEDGED/Condition
Inspite of this, when I start installing, it does not prompt, and then when my 
the msi tried to access HKCR it throws error

Msiexec log is as follows :

MSI (s) (20:60) [18:00:52:378]: Skipping AppSearch action: already done on 
client side
Action ended 18:00:52: AppSearch. Return value 0.
MSI (s) (20:60) [18:00:52:378]: Doing action: LaunchConditions
MSI (s) (20:60) [18:00:52:378]: Note: 1: 2205 2:  3: ActionText 
Action start 18:00:52: LaunchConditions.
Action ended 18:00:52: LaunchConditions. Return value 1.
MSI (s) (20:60) [18:00:52:378]: Doing action: FindRelatedProducts

Am I missing something here?

- Nitin
DISCLAIMER == This e-mail may contain privileged and confidential 
information which is the property of Persistent Systems Ltd. It is intended 
only for the use of the individual or entity to which it is addressed. If you 
are not the intended recipient, you are not authorized to read, retain, copy, 
print, distribute or use this message. If you have received this communication 
in error, please notify the sender and delete all copies of this message. 
Persistent Systems Ltd. does not accept any liability for virus infected mails. 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] NOT PRIVILEDGED Condition

2007-10-16 Thread Strele Franz
Correction: the expression must evaluate to True for installation to begin. So 
you need to use Privileged instead of NOT Privileged, like this:

Condition Message=You need to be Administrator to install this 
add-in.Privileged/Condition

Hth,
Franz



 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Strele Franz
 Gesendet: Dienstag, 16. Oktober 2007 14:58
 An: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] NOT PRIVILEDGED Condition
 
 Properties are case sensitive (and you have a spelling error too). You
 need to use NOT Privileged.
 
 Condition Message=You need to be Administrator to install this add-
 in.NOT Privileged/Condition
 
 
 Hth,
 Franz
 
 
 
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Nitin Chaudhari
 Gesendet: Dienstag, 16. Oktober 2007 14:36
 An: wix-users@lists.sourceforge.net
 Betreff: [WiX-users] NOT PRIVILEDGED Condition
 
 Hi,
 
 I created a default Limited user account in windows XP and my wxs has
 Condition Message=You need to be Administrator to install this add-
 in.NOT PRIVILEDGED/Condition
 Inspite of this, when I start installing, it does not prompt, and then
 when my the msi tried to access HKCR it throws error
 
 Msiexec log is as follows :
 
 MSI (s) (20:60) [18:00:52:378]: Skipping AppSearch action: already done
 on client side
 Action ended 18:00:52: AppSearch. Return value 0.
 MSI (s) (20:60) [18:00:52:378]: Doing action: LaunchConditions
 MSI (s) (20:60) [18:00:52:378]: Note: 1: 2205 2:  3: ActionText
 Action start 18:00:52: LaunchConditions.
 Action ended 18:00:52: LaunchConditions. Return value 1.
 MSI (s) (20:60) [18:00:52:378]: Doing action: FindRelatedProducts
 
 Am I missing something here?
 
 - Nitin
 DISCLAIMER == This e-mail may contain privileged and
 confidential information which is the property of Persistent Systems
 Ltd. It is intended only for the use of the individual or entity to
 which it is addressed. If you are not the intended recipient, you are
 not authorized to read, retain, copy, print, distribute or use this
 message. If you have received this communication in error, please
 notify the sender and delete all copies of this message. Persistent
 Systems Ltd. does not accept any liability for virus infected mails.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX Permission Element

2007-10-05 Thread Strele Franz
It's the other way round:

In v2 its Permission with Extended=yes:

CreateFolder
Permission Extended=yes ... /
/CreateFolder


In v3 its PermissionEx with WixUtilExtension-namespace (here util):

CreateFolder
util:PermissionEx ... /
/CreateFolder



Hth,
Franz



 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Rob Hamflett
 Gesendet: Donnerstag, 04. Oktober 2007 18:31
 An: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] WiX Permission Element
 
 So are you saying that the following should work?  Because it doesn't?
 Candle reports:
 error CNDL0005 : The CreateFolder element contains an unexpected child
 element 'PermissionEx'.
 
 Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi;
 ...
 CreateFolder
PermissionEx GenericAll=yes Read=yes ReadAttributes=yes
 CreateChild=yes Delete=yes
 DeleteChild=yes WriteAttributes=yes User=Everyone/
 /CreateFolder
 ...
 
 Do I need a particular argument to candle?
 
 Rob
 
 Bob Arnson wrote:
  Rob Hamflett wrote:
  I tried the same thing, but with util:Permission under CreateFolder,
 like I currently have with
  Permission.  Candle (2.0.5325) reports error CNDL0005 : The
 CreateFolder element contains an
  unexpected child element 'util:PermissionEx'. Changing
 util:PermissionEx to PermissionEx didn't
  help.
 
  In v3, it's Permission with the WixUtilExtension namespace (usually
  util). In v2, it's PermissionEx in the WiX namespace (because
  PermissionEx is parsed by the WiX compiler).
 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] (hresult -2147024770)

2007-09-25 Thread Strele Franz
The hresult means ERROR_MOD_NOT_FOUND (The specified module could not be 
found.) which usually happens when you are missing a dependent dll. Can you 
manually register your dll on Vista (eg. with regsvr32.exe)?

Hth,
Franz

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Craig0ss
 Gesendet: Dienstag, 25. September 2007 13:03
 An: wix-users@lists.sourceforge.net
 Betreff: [WiX-users] (hresult -2147024770)
 
 
 Hi
 
 When i install my msi on an XP machine i have no problems, however ive
 tried
 to install on a Vista machine and i get the following error the
 installer is
 trying to register a certain .dll
 
 i get
 
 Module c:\windows\system32zxscan4.dll failed to register. hresult
 -2147024770. contact your support personnel.
 
 on XP this dll registers fine
 
 Does any one have any info on this matter?
 
 What im tasked with doing now is making my installer still install this
 dll
 to both opertaing systems but only register it if XP is detected, this
 is
 not the path i would like to go down, as its a bodge fix that will have
 to
 undone at some point, id rather get this dll registering ok
 
 This dll enables my software to use scanners etc so its quite important
 
 Thank you
 --
 View this message in context: http://www.nabble.com/%28hresult--
 2147024770%29-tf4514822.html#a12877284
 Sent from the wix-users mailing list archive at Nabble.com.
 
 
 ---
 --
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] (hresult -2147024770)

2007-09-25 Thread Strele Franz
You can use Dependency Walker and open up your dll on Vista, and it should 
tell you which files are missing.
http://www.dependencywalker.com/


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Craig0ss
 Gesendet: Dienstag, 25. September 2007 13:34
 An: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] (hresult -2147024770)
 
 
 
 no registering the dll manualy fails as well, im not sure if its a
 vista
 prob as it works fine on XP
 
 
 Strele Franz-2 wrote:
 
  The hresult means ERROR_MOD_NOT_FOUND (The specified module could
 not be
  found.) which usually happens when you are missing a dependent dll.
 Can
  you manually register your dll on Vista (eg. with regsvr32.exe)?
 
  Hth,
  Franz
 
  -Ursprüngliche Nachricht-
  Von: [EMAIL PROTECTED] [mailto:wix-users-
  [EMAIL PROTECTED] Im Auftrag von Craig0ss
  Gesendet: Dienstag, 25. September 2007 13:03
  An: wix-users@lists.sourceforge.net
  Betreff: [WiX-users] (hresult -2147024770)
 
 
  Hi
 
  When i install my msi on an XP machine i have no problems, however
 ive
  tried
  to install on a Vista machine and i get the following error the
  installer is
  trying to register a certain .dll
 
  i get
 
  Module c:\windows\system32zxscan4.dll failed to register. hresult
  -2147024770. contact your support personnel.
 
  on XP this dll registers fine
 
  Does any one have any info on this matter?
 
  What im tasked with doing now is making my installer still install
 this
  dll
  to both opertaing systems but only register it if XP is detected,
 this
  is
  not the path i would like to go down, as its a bodge fix that will
 have
  to
  undone at some point, id rather get this dll registering ok
 
  This dll enables my software to use scanners etc so its quite
 important
 
  Thank you
  --
  View this message in context: http://www.nabble.com/%28hresult--
  2147024770%29-tf4514822.html#a12877284
  Sent from the wix-users mailing list archive at Nabble.com.
 
 
  
 ---
  --
  This SF.net email is sponsored by: Microsoft
  Defy all challenges. Microsoft(R) Visual Studio 2005.
  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
  -
 
  This SF.net email is sponsored by: Microsoft
  Defy all challenges. Microsoft(R) Visual Studio 2005.
  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 --
 View this message in context: http://www.nabble.com/%28hresult--
 2147024770%29-tf4514822.html#a12877667
 Sent from the wix-users mailing list archive at Nabble.com.
 
 
 ---
 --
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Browse dialogs New folder (Localization)

2007-09-24 Thread Strele Franz
You need to define the UITextNewFolder string in a .wxl-file like this:

?xml version=1.0 encoding=utf-8?
WixLocalization Culture=de-de 
xmlns=http://schemas.microsoft.com/wix/2006/localization;
  String Id=UITextNewFolderOrdner|Neuer Ordner/String
/WixLocalization


Or in a .wxs-file like this:

UI
UIText Id=NewFolderOrdner|Neuer Ordner/UIText
/UI



 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Magus
 Gesendet: Dienstag, 25. September 2007 05:58
 An: wix-users@lists.sourceforge.net
 Betreff: [WiX-users] Browse dialogs New folder (Localization)
 
 
 I am trying to localize my installer, and I have come across an issue
 where
 my browse dialog always makes New Folder as the name for a new
 folder,
 however this should be happening on other other operating systems. Is
 there
 anyway to specify which folder name I want this to create or start out
 with.
 I am using the browse folder that is in this tutorial.
 http://www.tramontana.co.hu/wix/lesson5.php
 --
 View this message in context: http://www.nabble.com/Browse-dialogs-New-
 folder-%28Localization%29-tf4513215.html#a12872695
 Sent from the wix-users mailing list archive at Nabble.com.
 
 
 ---
 --
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] tallow.exe failing to generate fragment for unmanagedshim DLL

2007-09-05 Thread Strele Franz
Instead of the -c switch, you'll need the -s switch:

tallow -nologo -s LicensingClientShim.dll

Hth,
Franz

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Duncan Bayne
 Gesendet: Mittwoch, 05. September 2007 13:33
 An: wix-users@lists.sourceforge.net
 Betreff: [WiX-users] tallow.exe failing to generate fragment for
 unmanagedshim DLL
 
 Hi All,
 
 First of all, I'm loving WiX, having come to it from an InstallShield
 background.  It's everything I always wished IS was ...
 
 However, I'm having a problem getting tallow.exe to generate the
 fragment to use to register a COM object.  The catch is that the COM
 object is actually an unmanaged shim for a managed DLL, which is
 consumed by Excel.
 
 When I run tallow -nologo -c LicensingClientShim.dll I get the
 following exception:
 
 ===
 Failed to load Assembly: LicensingClientShim.dll
   System.BadImageFormatException: Could not load file or assembly
 'file:///c:\temp\tallow\LicensingClientShim.dll' or one of its
 dependencies. The module was expected to contain an assembly manifest.
 File name: 'file:///c:\temp\tallow\LicensingClientShim.dll'
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String
 codeBase, Evidence assemblySecurity, Assembly locationHint,
 StackCrawlMark stackMark, Boolean throwOnFileNotFound, Boolean
 forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName
 assemblyRef, Evidence assemblySecurity, StackCrawlMark stackMark,
 Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoadFrom(String assemblyFile,
 Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm
 hashAlgorithm, Boolean forIntrospection, StackCrawlMark stackMark)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at
 Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(Strin
 g[]
 args)
 
 Assembly manager loaded from:
 C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
 Running under executable  c:\temp\tallow\tallow.exe
 --- A detailed error log follows.
 
 === Pre-bind state information ===
 LOG: User = OFFBYZERO\duncan
 LOG: Where-ref bind. Location = c:\temp\tallow\LicensingClientShim.dll
 LOG: Appbase = file:///c:/temp/tallow/
 LOG: Initial PrivatePath = NULL
 Calling assembly : (Unknown).
 ===
 LOG: This bind starts in LoadFrom load context.
 WRN: Native image will not be probed in LoadFrom context. Native image
 will only be probed in default load context, like with
 Assembly.Load().
 LOG: Using application configuration file:
 c:\temp\tallow\tallow.exe.Config
 LOG: Using machine configuration file from
 C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
 LOG: Attempting download of new URL
 file:///c:/temp/tallow/LicensingClientShim.dll.
 ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing
 terminated.
 ===
 
 If I register the DLL manually, from the same directory (which also
 contains all the WiX executables), it succeeds:
 
 ===
 DllRegisterServer in LicensingClientShim.dll succeeded.
 ===
 
 I suspect I'm missing something simple here ... anyone have any
 suggestions?
 
 Yours,
 Duncan Bayne
 
 ---
 --
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Kill Process

2007-08-29 Thread Strele Franz
From the Windows Installer Documentation:
http://msdn2.microsoft.com/en-us/library/aa372059.aspx

If you expect the installer to display a FilesInUseDialog, but it does not, 
this may be due to one of the following reasons:

The files in use are not executables. 
The installer is not actually trying to install those files. 
The process holding those files is the process invoking the installation. 
The process holding those files is one that does not have a window with a title 
associated with it.


Since your wsq95.exe is not listed in the application list, that means it 
doesn't have a window with a title associated with it. So Windows Installer 
does not detect that the file is in use...

Hth,
Franz


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Simon Topley
 Gesendet: Mittwoch, 29. August 2007 11:12
 An: Schrieken, Rene; wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] Kill Process
 
 It does seem odd that if this file is in use:
 
 File Id=file2576 Name=INFOWO_1.EXE LongName=infoworks.exe
 src=$(var.WSRedist)\infoworks.exe Vital=yes /
 
 It warns you to close it, but if this file is in use it does not:
 
 File Id=fwfile80 Name=wsq95.exe src=$(var.FWRedist)\wsq95.exe
 Vital=yes /
 
 The later runs in the system tray and is only listed in the process
 list, not the application list in the task manager, this could be
 related.
 
 *Shrugs shoulders
 
 Simon
 
 -Original Message-
 From: Schrieken, Rene [mailto:[EMAIL PROTECTED]
 Sent: 29 August 2007 09:39
 To: Simon Topley; wix-users@lists.sourceforge.net
 Subject: RE: [WiX-users] Kill Process
 
  Does anyone know why this is not the case for XP/2000/2003 ?
 
 Wild guess: Vista is Windows Installer 4.0, XP/2000/2003 is Windows
 Installer 3.0 or less?
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Simon
 Topley
 Sent: Wednesday, August 29, 2007 9:30 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Kill Process
 
 Hello all,
 
 I am still having some trouble with this process that is left running
 during the uninstallation. I haven't come up with a clean way to solve
 this yet.
 
 I notice with most other things that are left running the installer
 tells you to close them before it can proceed with the uninstallation,
 indeed under vista it does this very thing for the process in question.
 Does anyone know why this is not the case for XP/2000/2003 ? The file
 is
 set as Vital and the KeyPath for that component, I'm not sure what else
 I can do.
 
 Kind Regards
 
 Simon.
 The information contained in this e-mail is likely to be confidential
 and may be legally privileged. It is intended only for the addressee.
 If
 you have received this message in error please notify the sender
 immediately at the above address. The disclosure, copying or
 distribution of this message or its contents without the prior approval
 of Wallingford Software is strictly prohibited. Wallingford Software is
 not liable for unauthorised disclosures nor for subsequent actions or
 omissions in reliance upon them.
 
 Registered in the UK, company no: 02288719 Wallingford Software
 Limited,
 Howbery Park, Wallingford, Oxfordshire, OX10 8BA
 
 ---
 -
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 This e-mail and any attachment is for authorised use by the intended
 recipient(s) only. It may contain proprietary material, confidential
 information and/or be subject to legal privilege. It should not be
 copied, disclosed to, retained or used by, any other party. If you are
 not an intended recipient then please promptly delete this e-mail and
 any attachment and all copies and inform the sender. Thank you.
 The information contained in this e-mail is likely to be confidential
 and
 may be legally privileged. It is intended only for the addressee. If
 you
 have received this message in error please notify the sender
 immediately at
 the above address. The disclosure, copying or distribution of this
 message
 or its contents without the prior approval of Wallingford Software is
 strictly prohibited. Wallingford Software is not liable for
 unauthorised disclosures nor for subsequent actions or omissions in
 reliance
 upon them.
 
 Registered in the UK, company no: 02288719
 Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire,
 OX10 8BA
 
 ---
 --
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find 

Re: [WiX-users] Error with WIX and SQL when executing light

2007-08-20 Thread Strele Franz
I compiled (candle/light) your example with Wix 3.0.3210.0 without any problems.

Make sure your paths are correct and contain the required binaries.


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:wix-users-
 [EMAIL PROTECTED] Im Auftrag von Chris
 Gesendet: Montag, 20. August 2007 11:44
 An: Schrieken, Rene
 Cc: wix-users@lists.sourceforge.net
 Betreff: Re: [WiX-users] Error with WIX and SQL when executing light
 
 I tried it now with dll's that are not in the Wix3.x tree but nothing
 changed - same error :(
 
 Schrieken, Rene wrote:
  I'm not sure why this happens... but in Wix2.x there is also a
  scasched.dll which I can not find in the Wix3.x tree. Maybe this is
  related to the issue that not all files are included in either the
  binaries and/or the MSI.
 
  The source code still exists...
  http://wix.cvs.sourceforge.net/wix/wix/src/ca/serverca/
  not sure if it is build
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Chris
  Sent: Monday, August 20, 2007 9:58 AM
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Error with WIX and SQL when executing light
 
  Hello,
  I still have the problem with 'lighting' my wix-sql-example (see
 below).
 
  Maybe you have any ideas?
  I get following error:
 
  light WixMondoSample.wixobj -ext WixSqlExtension.dll -ext
 WixUIExtension
  Microsoft (R) Windows Installer Xml Linker version 3.0.2925.0
  Copyright (C) Microsoft Corporation 2003. All rights reserved.
 
  C:\delivery\Dev\wix\src\ext\sqlextension\wixlib\SqlExtension.wxs(27)
 :
  error LGHT0094 : Unresolved reference to symbol 'Binary:ScaSchedule'
 in
  section 'Fragment:'.
  C:\delivery\Dev\wix\src\ext\sqlextension\wixlib\SqlExtension.wxs(28)
 :
  error LGHT0094 : Unresolved reference to symbol 'Binary:ScaSchedule'
 in
  section 'Fragment:'.
  ---
 
  WXS:
 
  ?xml version=1.0 encoding=UTF-8?
  Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
   xmlns:Sql=http://schemas.microsoft.com/wix/SqlExtension;
   
  Product Id=34d0f6de-2dff-4321-8e0b-926a86e98678
  UpgradeCode=9c8fcd7b-4632-4872-99ad-18394618cc89
  Name=Acme Sample Application Language=1033 Version=1.0.0.0
  Manufacturer=Acme Software Ltd.

  Package InstallerVersion=200 Compressed=yes /
  Media Id=1 Cabinet=WixMondoSample.cab EmbedCab=yes /
 
  WixVariable Id=WixUILicenseRtf Value=license.rtf /
  WixVariable Id=WixUIDialogBmp Value=test.bmp /
  Binary Id=testsql SourceFile=.\testsql.sql /
 
  Sql:SqlDatabase Id=db1 Server=. Database=TestWixDB /
 
  Directory Id=TARGETDIR Name=SourceDir FileSource=.\
Component Id=DatabaseUpdate
  Guid=6f051579-2950-42e3-9381-2f538ae1de08
  Sql:SqlScript Id=SqlScript1
SqlDb=db1
ContinueOnError=no
ExecuteOnInstall=yes
ExecuteOnReinstall=yes
Sequence=001
BinaryKey=testsql
  /
  Sql:SqlString Id=SqlScript1
SqlDb=db1
ContinueOnError=yes
ExecuteOnUninstall=yes
Sequence=002
SQL=update customer set surname = 'Clinton' where Vorname=
  'Bill'
  /
/Component
Component Id=ProductComponent
  Guid=13b4d0a3-2d1d-4f2d-8765-bd8043aee206
  File Id=f1 Name=SampleFile.txt /
/Component
  /Directory
 
  Feature Id=ProductFeature Title=Main Feature Level=1
ComponentRef Id=DatabaseUpdate /
ComponentRef Id=ProductComponent /
  /Feature
 
  UIRef Id=WixUI_Mondo /
 
/Product
  /Wix
 
 
 
  -
 ---
  -
  This SF.net email is sponsored by: Splunk Inc.
  Still grepping through log files to find problems?  Stop.
  Now Search log events and configuration files using AJAX and a
 browser.
  Download your FREE copy of Splunk now   http://get.splunk.com/
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
  This e-mail and any attachment is for authorised use by the intended
 recipient(s) only. It may contain proprietary material, confidential
 information and/or be subject to legal privilege. It should not be
 copied, disclosed to, retained or used by, any other party. If you are
 not an intended recipient then please promptly delete this e-mail and
 any attachment and all copies and inform the sender. Thank you.
 
 
 
 
 ---
 --
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 WiX-users mailing list
 

Re: [WiX-users] Getting the MSI Package Path from a custom action

2006-11-30 Thread Strele Franz
Hi,

have a look at the OriginalDatabase or the SourceDir Windows 
Installer-property.

Hth,
Franz


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] Im Auftrag 
 von Gerald Grininger
 Gesendet: Donnerstag, 30. November 2006 09:04
 An: wix-users@lists.sourceforge.net
 Betreff: [WiX-users] Getting the MSI Package Path from a custom action
 
 Hello,
 
 I need to add licensing functionality to a MSI Package. The 
 package should be shipped  together with a license file which 
 will be evaluated by a custom action. The problem is that the 
 current directory in the custom action seems to be the 
 system32 folder. Does anybody has an idea how to access the 
 folder where the MSI package actually is situated from the 
 custom action? I want to access the license file which is in 
 the same folder as the package.
 
 Thanks in advance
 Gerald

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Internationalization - Folder name

2006-10-17 Thread Strele Franz
the browse dialog uses the DirectoryListNew control event. it looks up
the value from NewFolder-row in the UIText-table.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/set
up/directorylistnew_controlevent.asp 

in wix (2.0.4423.0) and WixUI_de-de.wxl it is not localized, but you can
use a UIText-element to add that row for yourself.


hth
franz

ps. the german version of New Folder is Neuer Ordner



Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Bahar
Shah
Gesendet: Dienstag, 17. Oktober 2006 14:44
An: wix-users@lists.sourceforge.net
Cc: Bob Arnson
Betreff: [WiX-users] Internationalization - Folder name



I have a bug where during install you can select a folder to
install and if you click New Folder  on a German OS, German installer,
it makes the folder named New Folder . 





Is it possible to have the folder name Neues Heft (German
version of 'New folder')

Do  we have control over that name.. or if this is just the way
it works from the MSI level. ?




Regards

Bahar



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] environment variable available in executed program

2006-07-04 Thread Strele Franz
hi,

have a look at the msdn-documentation for the Environment Table [1]:

Note that environment variables do not change for the installation in progress 
when either the WriteEnvironmentStrings action or RemoveEnvironmentStrings 
action are run. On Windows NT and Windows 2000, this information is stored in 
the registry and a message notifies the system of changes when the installation 
completes. A new process, or another process that checks for these messages, 
uses the new environment variables. On Windows 95 and Windows 98, this 
information is stored in the Autoexec.bat file, and do not affect the system 
until a system reboot.

you probably have a chance by sending a WM_SETTINGCHANGE (see [2]) via a custom 
action (after WriteEnvironmentStrings and RemoveEnvironmentStrings action). but 
i have not tried that and it may not work...

franz

[1] 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/environment_table.asp
[2] 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/wm_settingchange.asp

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Rob Hamflett
Gesendet: Dienstag, 04. Juli 2006 14:31
An: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] environment variable available in executed program

I had a similar thing with a new env var not being found by the program I was 
launching.  I can only conclude the following:

When you launch your MSI, it's value for PATH does not include your new folder. 
 The changes get committed to the system, but your MSI still has it's original 
set of env vars.  Since your batch file is run from the MSI, it has the same 
env vars, and so doesn't have the updated path.

Rob


Hecker, Thomas wrote:
 Hi,
  
 1) I'm adding my newly installed dir to the system path Environment 
 Id='env_entry' Name='PATH' Action='set' System='yes'
 Part='last' Permanent='no'  Value='[INSTALLDIR]share\bin' /
  
 2)  scheduled CA runs a .bat file that uses an executable from the 
 share\bin dir added to path.
  
 CustomAction Id='LaunchFile' FileKey='test.bat' 
 ExeCommand='-d [INSTALLDIR] ' Return='asyncNoWait' /
  
  InstallExecuteSequence
   Custom Action='LaunchFile' After='InstallFinalize'NOT 
 Installed/Custom  /InstallExecuteSequence
  
 3) In the up-popping console window I can see that the executable was 
 not found. But after opening a new cmd-session, it is available. Why 
 is that not in the console wix opens for me? How do I achieve this?
  
 Thank you very much,
 Thomas
 
 
 --
 --
 
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job 
 easier Download IBM WebSphere Application Server v.1.0.1 based on 
 Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=1216
 42
 
 
 --
 --
 
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier 
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users