[WiX-users] [Personal note: goodbye to Wix-Users, and thanks]

2008-03-25 Thread Daryn Mitchell

I'm changing jobs in two weeks, and with the change in responsibility
I'll be leaving the Wix-users community. I subscribed to the list last
year and was able to successfully - and relatively painlessly - change
our products from InstallShield to Wix. Almost all of that invaluable
knowledge came from the 9000 messages (not including spam) from the list
in the past year, with assistance from the list archives too.

I just wanted to say thanks to the list contributors for all your
helpful help on Wix and Windows Installer.

Daryn.

-
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] Get Target machine name

2008-03-13 Thread Daryn Mitchell
[EMAIL PROTECTED] wrote:
  For the machine name, use the ComputerName property. 

Tris Hodges wrote:
 I assume you meant like the following.. $(sys.COMPUTERNAME)? I 
 believe this is set at compilation […]

No, Calin meant the Windows Installer property ComputerName, see the Windows
Installer Property Reference,
http://msdn2.microsoft.com/en-us/library/aa370905(VS.85).aspx


For domain name, I'm pretty sure it needs a custom action, e.g. your own C++
DLL. Or, a quick search shows that Matthew Rowan posted a simple VBScript
custom action to do it to this list previously:
http://www.nabble.com/domain-name-to9381200.html#a9381200
... and InstallSite has a CA DLL that provides it as well:
http://www.installsite.org/pages/en/isp_svc.htm

Daryn.






-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] SecureCustomProperties from Merge Module

2008-03-12 Thread Daryn Mitchell
Daryn Mitchell originally wrote:

  ... merge module's ... SecureCustomProperties ... how should the 

  merge module get the result of its file search during Vista repair?

 

Bob Arnson wrote:

 The only thing I can think of is a custom action that adds your property

 to the SecureCustomProperties property. You'd have to play around with

 the sequencing to find the right timing.

 

Thanks for the suggestion, Bob. I saw the same suggestion made
http://forum.installsite.net/index.php?showtopic=15935  by Stefan. I
wasn't able to get it working, though.

 

I tried using a type 51 custom action during the UI sequence to append the
property (the full merge module property name, including the MSM suffix) to
SecureCustomProperties. I couldn't find any information on when to schedule
it, so I ran it as the first item in the UI sequence. While the MSI's
SecureCustomProperties property was correctly updated, it didn't seem to
have any effect on the merge module's public property being disallowed.
Since it works if the property is added to SecureCustomProperties in the MSI
directly (using Orca), I'm assuming that it's too late once the installation
has started?

 

Anyway, my conclusion: I couldn't get it to work, so I changed the merge
module authoring to remove the FileSearch. Should work fine for our needs,
but I'm glad it's nothing more complex, because I think the same issue would
affect RegistrySearch, which is pretty essential MSI stuff!

 

Daryn.

 

p.s. For what it's worth, two other points of interest if anyone else looks
into this problem:

-Running the repair using the original MSI in a different folder
causes the UAC prompt, which allows the public properties get passed to the
execute sequence.

-There's a
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2941031SiteID=1
discussion on the MDSN forums about trusted repairs/changes -- behaviour
that surprised me -- in which one MSFT commenter referred to marking a
product ARPSYSTEMCOMPONENT and creating your own custom legacy UNINSTALL key
reference that points to your boostrapper (that could require elevation).
Too complex a workaround for me, but I thought it was interesting.

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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


[WiX-users] SecureCustomProperties from Merge Module

2008-03-07 Thread Daryn Mitchell
Hi,

Looking for your Windows Installer / WiX knowledge about
SecureCustomProperties behaviour with merge modules:

Setup:
 - Wix 2.0.5325
 - My WiX product FOO.msi merges in a merge module BAR.msm (using
Feature/MergeRef and Directory/Merge).
 - The BAR.msm has a property BAR_SEARCH_RESULT in its
SecureCustomProperties propery
 - (I am the author of the merge module, so I can fix it, but I can't
use WiX fragments because the customers of the MSM aren't all using
WiX.)4

Problem:
 - FOO.msi is not authored with the merged property
BAR_SEARCH_RESULT.ABC132...MSM_GUID in its own SecureCustomProperties
property
 - Therefore, when a repair is run on Vista with full UI, the merge
module's BAR_SEARCH_RESULT property is not passed to the execute
sequence (log Ignoring disallowed property...), which causes an error
with a repair CA.

Question:
 - Should a merge module's Secure Custom Properties be automatically put
into the consuming MSI's own SecureCustomProperties automatically when
it incorporates the merge module? (i.e. is Wix not doing something it
should be doing? Much more likely that I don't know best practices here,
but I had to ask.)
 - If not, how should the merge module get the result of its file search
during Vista repair?

Thanks,
Daryn Mitchell

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Custom action sequencing problem

2008-02-27 Thread Daryn Mitchell

 -Original Message-
 From: wix-users On Behalf Of Boris Krivonog
...
 Attached is a simple VS 2005 project which locates a process by name and
 sends it a WM_CLOSE. 

That's really generous of you, Boris. Thanks for sharing that with the
community.

Daryn.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Multilingual Support

2008-02-01 Thread Daryn Mitchell
 

 

 -Original Message-

 Yes, I know the short answer is 'no'

 ... installers that can make a single multilingual install package

 ... isn't there some creative work-around for this?

 

Multi-Language MSI Packages without Setup.exe Launcher

http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm

 

I haven't tried this yet but it sounds ideal. It's undocumented and
therefore officially not supported. But if it works, hey, why not?

By the way, if you try it, could you post back to the list to let us know if
it was successful or not? Thanks.

 

Daryn.

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] condition expression syntax (ICE79)

2008-02-01 Thread Daryn Mitchell

 -Original Message-
 I have a feature with the ID=SomeFeature.

 Custom Action=MyAction After=InstallFinalize$SomeFeature/Custom
 This throws an ICE79 error.
 
 However, changing the $ to a ! is fine.

$ is for components,  and ! are for features.

(Conditional Statement Syntax
http://msdn2.microsoft.com/en-us/library/aa368012(VS.85).aspx)


Daryn.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Custom Action Rollback Implementation

2008-01-18 Thread Daryn Mitchell
 -Original Message-
 From: Sneha Gharpure
 
 the WriteToRegistry action is called only during the 
 installation and therefore the condition  Not Installed.
 I am not sure about the condition for WriteToRegistry_Rollback.
 I have tried both- Installed and Not Installed
 
 Custom Action=WriteToRegistry  Sequence=6402
Not Installed
 /Custom
 Custom Action=WriteToRegistry_Rollback Before=WriteToRegistry
Installed
 /Custom

Richard is right that your primary issue to that your CA has to be deferred
if you want your rollback action to get written to the rollback script.

I wanted to add that the condition for your rollback action should be the
same as the deferred action that you want to roll back.
I.e. if WriteToRegistry's condition is 'Not Installed', then you want to use
'Not Installed' for WriteToRegistry_Rollback too. When you get to the action
and the condition 'Not Installed' is true, the rollback custom action
doesn't fire right away, it gets written to the rollback script. It will
then be executed if the install rolls back.

For a helpful overview see Installation Phases and In-Script Execution
Options for Custom Actions in Windows Installer on Stefan Krueger's site.
http://www.installsite.org/pages/en/isnews/200108/index.htm

Daryn.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] Service started stoped but Not removed from Servcies.msc

2008-01-17 Thread Daryn Mitchell
 -Original Message-
 I have one service related binary(guardsvc.exe)
 
 It is started properly while installing and stoped while uninstalling.
 
 The problem is it is not deleted the corresponding registry
 key(HKL\SYSTEM\ControlSet001\Services\guardsvc.exe) and because of 
 this registry key it is visible in  Services.msc

It might be something other than a WiX problem.

 1) Don't look at ControlSet001, look at CurrentControlSet
 2) Is the service marked for deletion?
 3) If so, then your service won't be removed until reboot. I've seen that
happen recently where QueryServiceStatus was called on a service, but
CloseServiceHandle was not subsequently called to release the handle, so the
service control manager would only mark the service for deletion, not
actually remove it.

Daryn.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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


[WiX-users] Shared components and ?Comp1 Component State condition

2008-01-04 Thread Daryn Mitchell

I've got a component that's installed by two products, via a merge module.
There's also some custom actions, conditioned something like this:
  Install_Ensure, Condition: $Comp1 = 3
  InstallRollback_Remove, Condition: $Comp1=3 AND NOT ?Comp1=3
  Uninstall_Remove, Condition: $Comp1 = 2 AND NOT UPGRADINGCODE
  (UninstallRollback_Ensure)

The Product2 uninstall works fine: the log shows that it gets Installed:
Local;  Request: Absent;  Action: Null, so the shared component is --
correctly -- not removed until Product1 is uninstalled.

However, there's a problem with the Product2 install rollback condition.
During install the component state shows Installed: Absent;  Request:
Local;  Action: Local. I was expecting Installed to be Local, not Absent! I
thought my AND NOT ?Comp1=3 condition would mean the rollback remove would
only run when the component was not already installed, i.e. not run during
Prodcut2 install. But the rollback runs.

After searching, I found a confirmation in the docs at the bottom of
'Conditional Statement Syntax' that this behaviour is expected by Windows
Installer, Note that you should not depend upon the condition $Component1=3
to check whether Component1 is locally installed on the computer...

Question:
So what is the correct way for the Product2 install to know that the shared
component is already installed locally by Prodcut1?

Thanks for any suggestions

Daryn Mitchell,
Software Developer, Faronics Corporation


Note: I haven't tried SharedDllRefCount; from my reading of the docs it
didn't seem like it would solve this, except if I used it to support a hack
like manually checking the refcount in the registry at install time?





-
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] Re Post: Msi Logging

2007-12-19 Thread Daryn Mitchell

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:wix-users-
 Subject: Re: [WiX-users] Re Post: Msi Logging

 I dont have idea about bootstrapper.
 
 Could you tell me in detail or send me the url

http://www.nabble.com/forum/Search.jtp?forum=4468local=yquery=bootstrapper



-
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] show progress text for custom action

2007-12-04 Thread Daryn Mitchell
Adam Langley wrote:
 ...
 the Progress Text in the dialog shows Removing Backup Files 
 during the execution of my slow custom action, it never 
 renders my text
 ...
CustomAction ... Execute='commit' ... /


My guess: You should make your action be deferred instead of commit.

a) Wix ProgressText maps to Windows Installer ActionText table (Wix.chm)

b) Action text is only displayed for actions that run within the
installation script. Therefore, action text is only displayed for actions
that are sequenced between the InstallInitialize and InstallFinalize
actions (Windows Installer docs for ActionText Table)

c) Your action is a Commit CA. Commit custom actions run after
InstallFinalize is finished. (Windows Installer docs for Commit Custom
Actions).

Therefore I figure the progress is not showing because you've made it a
Commit action.

Your symptom may have been useful because it raises the question, why is
your CA a commit action, rather than deferred?
 - The purpose of commit actions is to remove any backup information that
had been created by a custom action. (Installsite,
http://www.installsite.org/pages/en/isnews/200108/index.htm)
 - That's exactly what you saw the WiX UI choose for the progress text
during the commit phase, Removing Backup Files.

So... would it be more appropriate for your CA to be a deferred action
instead? If so, then you'll have solved your progress text too.

Daryn.





-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Problems in running vbscript during install

2007-11-23 Thread Daryn Mitchell
Your CustomAction needs to be defined differently.
Instead of ExeCommand, use VBScriptCall='' (value = blank to just run the
script, or put the name of the VBScript function). ExeCommand attribute
tries to execute an EXE, not run VBScript.

Also I'm pretty sure that deferred custom actions have to be scheduled
between InstallInitialize and InstallFinalize, which would mean you need to
schedule yours earlier or make it an immediate action.
(As found in Deferred CA description,
http://msdn2.microsoft.com/en-us/library/aa368268.aspx)

Daryn.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of chandan
Koushik
Sent: Friday, November 23, 2007 12:03 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problems in running vbscript during install


snip
I am unable to ... call a vbscript file 

Binary Id=vbscript SourceFile=SetDirectoryPermissions.vbs/

CustomAction Id=SetAnonPerm BinaryKey=vbscript Execute=deferred
  ExeCommand=quot;C:\fontsquot; Return=check /

!--Installexecutesequence --
Custom Action=SetAnonPerm After=InstallFinalizeNOT Installed/Custom



-
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] Custom Action type 1042 and 18

2007-11-23 Thread Daryn Mitchell

Here's a couple of possibilities:

1) If you've got an existing MSI you're converting to Wix, use the Wix tools
(Dark) to decompile it into Wix markup.

2) Very handy Custom Action Type Calculator on the InstallShield web site
makes the guess and test go much quicker. (Needs IE, doesn't work in Firefox
for me.)
http://helpnet.installshield.com/robo/projects/helplibdevstudio9/IHelpDLLFun
ctionCalcType.htm

3) The Custom Action Reference on MSDN provides the real info on the flag
values.
(http://msdn2.microsoft.com/en-us/library/aa368070.aspx)
You break your known type into its component pieces. Note that you seem to
have to step through a bunch pages to find everything you're looking for
(types, scheduling options, etc.) - maybe there's a page somewhere that has
them all on one page?


Daryn.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of SaiTeja
Sent: Thursday, November 22, 2007 10:14 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom Action type 1042 and 18

Now I need Type as 1554. ...

Return= ??
Execute=deferred
Impersonate=??
HideTarget=??

... is there a way to find out the same or it is just trail and error




-
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] What do I do with per-user data when I uninstall?

2007-09-18 Thread Daryn Mitchell

Rob Hamflett wrote:
 The general advice is usually to offer the option of deleting
 files/settings for the current user.

I like this, but as a beginner setup guy I'm unclear on where exactly I'm
supposed to offer that option.
My natural inclination is to put it in the UI during the uninstall step...
but from Add/Remove programs there's only the minimal UI when the user click
'Remove'. If there's a way to change the default UI level then I guess
that's the answer I need.

Where do you give the user the option to delete?

Daryn.



-
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] Directory in user profile but not in RemoveFile table

2007-09-14 Thread Daryn Mitchell
 From: Jeff Hunsaker
 Sent: Friday, June 08, 2007 1:55 PM
 
 I'm adding a program menu which should be created if it's not there.
 Other programs install to this menu so I do not want to delete it 
 at uninstall. My XML looks like this: 
[...]
 error LGHT0204 : ICE64: The directory scmworkbench is in the 
 user profile but is not listed in the RemoveFile table.

I'm doing the same thing right now and I saw this entry when doing my
wix-users search.
Just for the record (as far as I understand), it's safe to have the
RemoveFile for your Program Menu folder that shared with other products,
because the action only removes folders that are empty, i.e. when there are
no other shortcuts left in it.

Daryn.



-
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] Problem with registering COM dll

2007-08-06 Thread Daryn Mitchell
I see that the use of [INSTALLDIR] in the registry entry - perhaps edited by
hand? - does not match the the TARGETDIR DirectoryRef.

This is not guaranteed to be an error, e.g. if you've ensured that the two
properties are equal, but it seems fragile.

You can check the installed registry entries to see if they have the full
path to WelcomeCOM.dll, or just the filename alone, to know if this is
causing an error.

 

Daryn.

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ahn Ahn Liu
Sent: Monday, August 06, 2007 3:34 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with registering COM dll

 

I'm trying to register a COM component and followed the instruction on the
tutorial - running tallow -c WelcomeCOM.dll.

 

However, it does not appear to be successfully registering the object.

 

The tallow outputs:

 

Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;

  Fragment

DirectoryRef Id=TARGETDIR

  Component Id=component0 DiskId=1
Guid=A8D11ADD-9C2B-48ca-B666-B930D9F932E0

File Id=file0 Name=WELCOM_1.DLL LongName=WelcomeCOM.dll
Source=WelcomeCOM.dll /

...

Registry Root=HKCR
Key=CLSID\{20D0E68E-393C-11DC-8314-0800200C9A66}\InprocServer32
Name=CodeBase Value=[INSTALLDIR]WelcomeCOM.dll Type=string /

...

Registry Root=HKCR
Key=CLSID\{20D0E68E-393C-11DC-8314-0800200C9A66}\InprocServer32\1.0.0.0
Name=CodeBase Value=[INSTALLDIR]WelcomeCOM.dll Type=string /

...

  /Component

/DirectoryRef

  /Fragment

/Wix

 

 

Any suggestion?

-
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] Problem writing registry values

2007-07-26 Thread Daryn Mitchell
Anidil,

Does it help if you pass Value='1' instead of Value='#0x0001(1)'?

Daryn.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anidil [...]
Now that i don't get permission denied message after prefexing # for all the
DWORD types as follows :

Registry Id=PCPERegNotification Root=HKLM
Key=Software\Wow6432Node\Product\Notification
Registry Action=write Name=Notification Sounds Enabled
Type=integer Value=#0x0001 (1)
xmlns=http://schemas.microsoft.com/wix/2006/wi; /
  /Registry

but i see that the registry is getting updated as type REG_SZ... :(



-
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] How to call an exe

2007-07-18 Thread Daryn Mitchell
I found it very easy to debug a DLL CA with the debugger:

I figured the DLL in the binary table has to be extracted before the code
can be called, right? So the following seemed to work for me to debug an
error I was getting while developing the CA:

1)   Use a debug version of the DLL

2)   Copy the .pdb file to C:\WINDOWS\Installer (hidden/system folder) -
since it seems where the DLL gets extracted as a temp file during
installation.

3)   Attach the debugger to msiexec.exe. When I tried there were three
instances running, but since my CA had 'no impersonate' it was easy, I could
pick the one running as SYSTEM rather than as the installing user.

 

Daryn

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Stevenson
Sent: Tuesday, July 17, 2007 3:58 PM
To: srinivas nomu; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to call an exe

snip/

you can debug MSI DLLs - just not via the debugger (albeit maybe you can, as
the links below made mention of info in MSI.chm, but I believe it is meant
to be a lot of effort). 

snip/

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of srinivas nomu
Sent: Wednesday, 18 July 2007 7:33 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to call an exe

I really fed up working with .dll as there is no debug available. Now I
created an .exe with the same code. 

 

 snip 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] changing setup at runtime

2007-04-20 Thread Daryn Mitchell

Also for an concise example of using the Automation interface you might find
it helpful to look at WiRunSQL.vbs in the Installer SDK / Platform SDK.

Use of the script is described in Examples of Database Queries Using SQL
and Script
http://msdn2.microsoft.com/en-us/library/aa368562.aspx


Daryn.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan Pavlik
[...]
look for the MsiSetProperty in the MSDN
[...]



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Any interest in a beginner's tutorial?

2007-04-20 Thread Daryn Mitchell

Rennie,

I'd be very happy to see a more beginner-oriented tutorial to help with
getting started. I'm currently evaluating whether to switch from
InstallShield to WiX, and there are still things I have not yet got
running/tested in WiX.

I'm a software developers who happen to also do setup -- as opposed to a
hardcore setup guy. I think people like me who are considering WiX could
certainly benefit from a tutorial focused on guiding beginners through a
smaller set of tasks that would be found in a typical 'simple' installation.

Your mention of dialog boxes and localization touches on the area that is
causing my current pause: customizing the UI, which seems to have a steep
initial learning curve... to an InstallShield user :)

Daryn.


 
-Original Message-
From: Rennie Petersen

[...] is there really any interest in yet another WiX
tutorial? Mine is more introductory than the current official one,
covers only the basic features in WiX, but does cover a few things like
creating your own dialog boxes and localization more comprehensively.




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Sequence of Install?

2007-04-19 Thread Daryn Mitchell
Does it fix that if you schedule it after='InstallFiles' instead of
CreateFolders?

Daryn.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of JCWrs
Sent: Thursday, April 19, 2007 12:39 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Sequence of Install?


Julie, thanks!  That helped quite a bit.

I'm still having one problem, however.  When my CA runs it looks to see if
the installed files are there by looking at INSTALLDIR.  I've run the
installer with the CA commented out and the files do get installed
correctly.  The CA program also works if I manually run it post Install. 
When I run it all together and schedule the CA for After CreateFolders,
however, it errors off and says it cannot find the files.

I assume the CA is running before the files are copied over?  When is the
latest I can call this CA during the install process?




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Error in German?

2007-04-13 Thread Daryn Mitchell
Kevin Burton wrote:
 Durint installation I briefly see a German message appear during the
progress: dialog. When there is an error I see an error dialog piop up that
is entirely in German. snip/
[]
 Do you know how to change that?

I've been learning WiX this week and I saw the same behaviour after I tested
out localization. I had mistakenly left my Product tag with the wrong
language attribute. I.e. I had:
   Product Language='1031' ... (German) when it should have been:
   Product Language='1033' ... (English)

Daryn.



-
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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wix-users