date:20101019

Re: [WiX-users] Merge Module

2010-10-19 Thread sagar shinde

Hi,

I am using windows 7 OS,

i my merge module is somthing like this,


http://schemas.microsoft.com/wix/2006/wi";
 xmlns:difx="http://schemas.microsoft.com/wix/DifxAppExtension";>
  
  

  1


  

  


  

  


  

  

  


and more files i have included in it.Those are en-us.wxl, jr-jp.wxl,and
fr-fr.wxl,

when i build this moduled it creates three folders and msm files for each
language.

now when i tried to use these merge module in may main project which also
contain en-us.wxl, jr-jp.wxl,and fr-fr.wxl,files but it shows follwing error
when i try
to  build it.

Error 1 Unable to open merge module 'E:\U\UB\bin\Debug\en-us\U.msm'. Check
to make sure the module language is correct. 'The language of this
installation package is not supported by your system. (Exception from
HRESULT: ' E:\U\UB_Wix\Product.wxs 204 1 UBSetup_Wix
and i also tried to achive it by using if condition and foreach loop for
diffrent languages.but its showing same error.

Thankyou,
Sagar S.

On Wed, Oct 20, 2010 at 9:24 AM, Blair  wrote:

> Are you trying to build localized merge modules, or a multiple language
> merge module?
>
> What language(s) besides 1033 are you trying to use?
>
> You still haven't told me what OS you are using.
>
> -Original Message-
> From: sagar shinde [mailto:sagar.i...@gmail.com]
>  Sent: Tuesday, October 19, 2010 12:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module
>
> Thanks for reply
>
> I am using same machine for both projects the merge module as well as main
> project. There is no OS difference or any other configuration change
> if i do merge module with only language "1033"  it works properly, but when
> i tried to do it with localization
> just i tried to do the things with foreach loop but it doesn't seems
> working
> for me can you please suggest me properway to achive localization with
> merge  module
>
> Thank's
> Sagar S.
>
> 
> --
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX book available

2010-10-19 Thread Thomas Due

Got my copy yesterday, and have already devoured the first two chapters. 
So far I have learned at least one new thing I didn't know per chapter, and 
confirmed some of my practices. 

Definitely a great piece of work :)

/Thomas




--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.5 C# Custom Action Project

2010-10-19 Thread Blair

Let me amend that. I'm not sure if it is "a" or "i". Most of the time people
mention /l*vx or simply /l*v. Skipping the rest of the selections ("o", "i",
"c", "e", "w", "a", "r", "m", "u", "p") leaves a lot of logging out.

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Tuesday, October 19, 2010 9:37 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] WiX 3.5 C# Custom Action Project

Are you including verbose in your logging?

-Original Message-
From: Ryan [mailto:rgrim...@gmail.com] 
Sent: Tuesday, October 19, 2010 9:59 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 3.5 C# Custom Action Project

I ran into the same issue and also solved it by setting the
useLegacyV2RuntimeActivationPolicy attribute to true.  However, I was (and
still am) unable to see msi log entries about custom action assembly loads. 
For instance, my logs do not contain the text "Hello, I'm your xxbit
Impersonated custom action server." 

I'm logging via /lvx.  Any suggestions on how to enable the assembly load
logging? 

Thanks 
Ryan
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Cust
om-Action-Project-tp5320937p5651686.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.5 C# Custom Action Project

2010-10-19 Thread Blair

Are you including verbose in your logging?

-Original Message-
From: Ryan [mailto:rgrim...@gmail.com] 
Sent: Tuesday, October 19, 2010 9:59 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] WiX 3.5 C# Custom Action Project


I ran into the same issue and also solved it by setting the
useLegacyV2RuntimeActivationPolicy attribute to true.  However, I was (and
still am) unable to see msi log entries about custom action assembly loads. 
For instance, my logs do not contain the text "Hello, I'm your xxbit
Impersonated custom action server." 

I'm logging via /lvx.  Any suggestions on how to enable the assembly load
logging? 

Thanks 
Ryan
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Cust
om-Action-Project-tp5320937p5651686.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module

2010-10-19 Thread Blair

Are you trying to build localized merge modules, or a multiple language
merge module?

What language(s) besides 1033 are you trying to use?

You still haven't told me what OS you are using.

-Original Message-
From: sagar shinde [mailto:sagar.i...@gmail.com] 
Sent: Tuesday, October 19, 2010 12:31 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge Module

Thanks for reply

I am using same machine for both projects the merge module as well as main
project. There is no OS difference or any other configuration change
if i do merge module with only language "1033"  it works properly, but when
i tried to do it with localization
just i tried to do the things with foreach loop but it doesn't seems working
for me can you please suggest me properway to achive localization with
merge  module

Thank's
Sagar S.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Calling a managed custom action from a UI control

2010-10-19 Thread McKinnon, Chris

You are absolutely right.  I just wanted to keep all my custom actions
in the same DLL.  I have two other actions for encrypting and decrypting
the .config files.  I switched my code to a VBScript and it works
nicely.  Here's the script if anyone is interested:

Function DirectoryExists() 
  Dim path, fso

  path = Session.Property("_DirectoryExists_Path")
  Set fso = CreateObject("Scripting.FileSystemObject")
  If (fso.FolderExists(path)) Then
Session.Property("_DirectoryExists_Result") = "yes"
  Else
Session.Property("_DirectoryExists_Result") = "no"
  End If
  DirectoryExists = ERROR_SUCCESS 
End Function

It's still frustrating that the DLL approach didn't work.

Thanks,

Chris McKinnon

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Tuesday, October 19, 2010 11:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Are you really cranking up all this infrastructure just to see if a
directory exists? There's got to be a simpler way, even if it's only a
horrible little VBScript 10 line custom action. At least that is
natively supported by Windows Installer.

Phil Wilson

-Original Message-
From: McKinnon, Chris [mailto:cmckin...@atb.com]
Sent: Tuesday, October 19, 2010 8:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Hi Blair,

No log entries, unfortunately.  I've let my installer sit spinning for
about 20-30 minutes.  I could let it sit longer but I don't think that
would help.  I'm going to try my installer on a Windows 2000
Professional workstation when I have a chance today.  Let me know if
there's anything else I can do to track down this issue.

Thanks,

Chris McKinnon

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Tuesday, October 19, 2010 12:06 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Whenever Windows Installer launches a DLL-type custom action, it does so
from a separate msiexec.exe process instance (sandboxing the custom
action
code, if you will). However, because this "sandbox" process may be
reused,
and because loading pre-4.x CLR runtimes "marks" the process preventing
a
different runtime from ever being loaded, DTF runs the assemblies in
their
own child process.

When you build a DTF custom action assembly, a native stub is
built/modified
that contains an entry point for each method with a
CustomActionAttribute,
along with being "packed" with your assembly, config, and dependencies.
This
stub sends a copy of itself to RunDll.exe after creating a two-way
communications pipe to communicate with its child process (which allows
for
querying the session for properties, running queries, etc.).

The stub in the (grandchild) process establishes communication with its
parent (the stub in the sandbox), extracts its payload, loads the
indicated
CLR, loads your assembly into an AppDomain, and finally calls your code
(this is where the transition into managed code finally occurs). You
seem to
be hanging somewhere in this paragraph (at least until you kill the
rundll.exe process). Are there any System or Application event log
entries
that may explain/describe some failure with the CLR spinup?
Unfortunately
calling MsiProcessMessage is documented to not work from a DoAction so
any
error or progress logging performed by the stub won't show up.

-Original Message-
From: McKinnon, Chris [mailto:cmckin...@atb.com]
Sent: Monday, October 18, 2010 10:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Thanks for the ideas Steve.

I tried running my code in a separate thread, like yours, but it still
hangs.  I'm running on Windows Vista Business 32-bit.  I noticed, by
accident, that in Process Explorer when the custom action starts up that
a new process tree is spawned:

1. msiexec.exe
2. msiexec.exe
3. rundll.exe (DTF Self-Extracting Custom Action)

The custom action is run when I click the next button on the
ServiceOptionsDlg in my installer.  The 1st time I click the button it
hangs.  If I kill the process tree above and click the next button
again, it runs my custom action.  Every time after that, if I click
"next", my custom action works fine.  I'm baffled why.  Here's the log
from me, killing the process tree the 1st time (the one at
11:11:06:126), then running my custom action (Directory.Exists()) on a
path of "t" and then on a path of "C:\":

Action 11:08:53: ServiceOptionsDlg. Dialog created
MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH
property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding
_DirectoryExists_Path property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory
A

Re: [WiX-users] Calling a managed custom action from a UI control

2010-10-19 Thread Wilson, Phil

Are you really cranking up all this infrastructure just to see if a directory 
exists? There's got to be a simpler way, even if it's only a horrible little 
VBScript 10 line custom action. At least that is natively supported by Windows 
Installer.

Phil Wilson

-Original Message-
From: McKinnon, Chris [mailto:cmckin...@atb.com]
Sent: Tuesday, October 19, 2010 8:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Calling a managed custom action from a UI control

Hi Blair,

No log entries, unfortunately.  I've let my installer sit spinning for
about 20-30 minutes.  I could let it sit longer but I don't think that
would help.  I'm going to try my installer on a Windows 2000
Professional workstation when I have a chance today.  Let me know if
there's anything else I can do to track down this issue.

Thanks,

Chris McKinnon

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Tuesday, October 19, 2010 12:06 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Whenever Windows Installer launches a DLL-type custom action, it does so
from a separate msiexec.exe process instance (sandboxing the custom
action
code, if you will). However, because this "sandbox" process may be
reused,
and because loading pre-4.x CLR runtimes "marks" the process preventing
a
different runtime from ever being loaded, DTF runs the assemblies in
their
own child process.

When you build a DTF custom action assembly, a native stub is
built/modified
that contains an entry point for each method with a
CustomActionAttribute,
along with being "packed" with your assembly, config, and dependencies.
This
stub sends a copy of itself to RunDll.exe after creating a two-way
communications pipe to communicate with its child process (which allows
for
querying the session for properties, running queries, etc.).

The stub in the (grandchild) process establishes communication with its
parent (the stub in the sandbox), extracts its payload, loads the
indicated
CLR, loads your assembly into an AppDomain, and finally calls your code
(this is where the transition into managed code finally occurs). You
seem to
be hanging somewhere in this paragraph (at least until you kill the
rundll.exe process). Are there any System or Application event log
entries
that may explain/describe some failure with the CLR spinup?
Unfortunately
calling MsiProcessMessage is documented to not work from a DoAction so
any
error or progress logging performed by the stub won't show up.

-Original Message-
From: McKinnon, Chris [mailto:cmckin...@atb.com]
Sent: Monday, October 18, 2010 10:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Thanks for the ideas Steve.

I tried running my code in a separate thread, like yours, but it still
hangs.  I'm running on Windows Vista Business 32-bit.  I noticed, by
accident, that in Process Explorer when the custom action starts up that
a new process tree is spawned:

1. msiexec.exe
2. msiexec.exe
3. rundll.exe (DTF Self-Extracting Custom Action)

The custom action is run when I click the next button on the
ServiceOptionsDlg in my installer.  The 1st time I click the button it
hangs.  If I kill the process tree above and click the next button
again, it runs my custom action.  Every time after that, if I click
"next", my custom action works fine.  I'm baffled why.  Here's the log
from me, killing the process tree the 1st time (the one at
11:11:06:126), then running my custom action (Directory.Exists()) on a
path of "t" and then on a path of "C:\":

Action 11:08:53: ServiceOptionsDlg. Dialog created
MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH
property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding
_DirectoryExists_Path property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory
Action 11:08:58: CheckArchiveDirectory.
Action start 11:08:58: CheckArchiveDirectory.
MSI (c) (CC:80) [11:08:58:573]: Invoking remote custom action. DLL:
C:\Users\e25735\AppData\Local\Temp\MSIF23D.tmp, Entrypoint:
DirectoryExists
MSI (c) (CC:A8) [11:08:58:574]: Cloaking enabled.
MSI (c) (CC:A8) [11:08:58:574]: Attempting to enable all disabled
privileges before calling Install on Server
MSI (c) (CC:A8) [11:08:58:575]: Connected to service for CA interface.
Action ended 11:11:02: CheckArchiveDirectory. Return value 1.
MSI (c) (CC:24) [11:11:06:126]: Doing action: CheckArchiveDirectory
Action 11:11:06: CheckArchiveDirectory.
Action start 11:11:06: CheckArchiveDirectory.
MSI (c) (CC:A0) [11:11:06:184]: Invoking remote custom action. DLL:
C:\Users\e25735\AppData\Local\Temp\MSIE4A7.tmp, Entrypoint:
DirectoryExists
MSI (c) (CC:A0) [11:11:06:184]: Lost connection to custom action server
process. Attempting to regenerate.
MSI (c) (CC:A8) [11:11:06:259]: Clo

Re: [WiX-users] Do WiX 3.0 link times improve using .wixlib files?

2010-10-19 Thread Brian Gillespie

  Hi Blair,

Thanks for the tips... I'll see what happens when I get rid of the merge 
modules first.

I am using cab reuse, but it seems that I have to be careful, especially 
if I build in parallel - one build will trash another build's cached cab.

   - Brian

Brian Gillespie
Rhinoceros Development
Robert McNeel & Associates

On 10/18/2010 8:03 PM, Blair wrote:
> In any given build, most of the time is typically taken doing three things:
> moving files, building cabs, and embedding.
>
> For the scenario you describe, I would recommend each MSI end up with (at
> least) three cabs (1. the 70 MB "common" cab, 2. the 50 MB "locale" cab, and
> 3. the 3MB "platform" cab). Make sure you are using the "cab reuse" feature
> of light (on by default in more recent builds).
>
> Making non-bound wixlibs may (or may not) help light's cab reuse algorithm
> (it's been some time since I looked at it) but it could certainly help
> organize your build activity, so I would recommend looking at it for its
> code organizational aspects.
>
> Making merge modules will likely slow down your builds, since they have to
> embed the files, then extract them and (possibly) embed them again. You may
> see a speed increase by getting rid of your locale merge modules (especially
> if you do NOT make them "binary/bound").
>
> The typical projects I work on tend to take between 15 and 65 minutes to
> link, and at most 1 minute of that is spent processing the XML,
> generating/populating/importing the tables, and other related tasks. All the
> rest is spent copying file content around.
>
> -Blair
>
> -Original Message-
> From: Brian Gillespie [mailto:br...@mcneel.com]
> Sent: Monday, October 18, 2010 12:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Do WiX 3.0 link times improve using .wixlib files?
>
>Hi,
>
> I have a project that builds 88 different flavors - the cross product of
> these three variables:
>
> Platform: x86 | x64
> Configuration: Beta | Retail | Evaluation | Another Evaluation
> Locale: cs, en-us, es-es, de-de, fr-fr, it-it, ja, ko, pl, zh-cn, zh-tw
>
> A core exe (3MB) changes with both Platform and Configuration, and
> locale-related stuff changes with each local (50MB). The rest of the
> content of each installer is identical (70MB).
>
> A merge module is built for each locale. A big wix project then is built
> to make each flavor. It takes 3-5 minutes each.
>
> Would moving the shared contents from the core installer to a .wixlib or
> merge module make any difference in link times? It will take some effort
> to rearrange the code, and I don't want to bother if it will make no
> difference in the final build times. Do you have any things I should
> watch out for that could adversely affect performance?
>
> Thanks in advance,
> - Brian
>
> Brian Gillespie
> Rhinoceros Development
> Robert McNeel&  Associates
>
>
> 
> --
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.5 C# Custom Action Project

2010-10-19 Thread Ryan


I ran into the same issue and also solved it by setting the
useLegacyV2RuntimeActivationPolicy attribute to true.  However, I was (and
still am) unable to see msi log entries about custom action assembly loads. 
For instance, my logs do not contain the text "Hello, I'm your xxbit
Impersonated custom action server." 

I'm logging via /lvx.  Any suggestions on how to enable the assembly load
logging? 

Thanks 
Ryan
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-5-C-Custom-Action-Project-tp5320937p5651686.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prerequisite check for per-user vs per-machine installation

2010-10-19 Thread Lisa Gracias

>
> Does product B always install a particular component guid (or at least a
> narrow set)?


I went through the installers for the last couple of versions and it looks
like the component GUIDs stay the same. To be safe I posted a question on
the Product B message board asking about their GUIDs. They said they are
using Visual Studio to create their installer so they don't know how the
GUIDs are generated or whether they'll change later on.
Any idea what makes an auto-generated GUID change?
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Calling a managed custom action from a UI control

2010-10-19 Thread McKinnon, Chris

Hi Blair,

No log entries, unfortunately.  I've let my installer sit spinning for
about 20-30 minutes.  I could let it sit longer but I don't think that
would help.  I'm going to try my installer on a Windows 2000
Professional workstation when I have a chance today.  Let me know if
there's anything else I can do to track down this issue.

Thanks,

Chris McKinnon

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Tuesday, October 19, 2010 12:06 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Whenever Windows Installer launches a DLL-type custom action, it does so
from a separate msiexec.exe process instance (sandboxing the custom
action
code, if you will). However, because this "sandbox" process may be
reused,
and because loading pre-4.x CLR runtimes "marks" the process preventing
a
different runtime from ever being loaded, DTF runs the assemblies in
their
own child process.

When you build a DTF custom action assembly, a native stub is
built/modified
that contains an entry point for each method with a
CustomActionAttribute,
along with being "packed" with your assembly, config, and dependencies.
This
stub sends a copy of itself to RunDll.exe after creating a two-way
communications pipe to communicate with its child process (which allows
for
querying the session for properties, running queries, etc.).

The stub in the (grandchild) process establishes communication with its
parent (the stub in the sandbox), extracts its payload, loads the
indicated
CLR, loads your assembly into an AppDomain, and finally calls your code
(this is where the transition into managed code finally occurs). You
seem to
be hanging somewhere in this paragraph (at least until you kill the
rundll.exe process). Are there any System or Application event log
entries
that may explain/describe some failure with the CLR spinup?
Unfortunately
calling MsiProcessMessage is documented to not work from a DoAction so
any
error or progress logging performed by the stub won't show up.

-Original Message-
From: McKinnon, Chris [mailto:cmckin...@atb.com] 
Sent: Monday, October 18, 2010 10:52 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Calling a managed custom action from a UI
control

Thanks for the ideas Steve.

I tried running my code in a separate thread, like yours, but it still
hangs.  I'm running on Windows Vista Business 32-bit.  I noticed, by
accident, that in Process Explorer when the custom action starts up that
a new process tree is spawned:

1. msiexec.exe
2. msiexec.exe
3. rundll.exe (DTF Self-Extracting Custom Action)

The custom action is run when I click the next button on the
ServiceOptionsDlg in my installer.  The 1st time I click the button it
hangs.  If I kill the process tree above and click the next button
again, it runs my custom action.  Every time after that, if I click
"next", my custom action works fine.  I'm baffled why.  Here's the log
from me, killing the process tree the 1st time (the one at
11:11:06:126), then running my custom action (Directory.Exists()) on a
path of "t" and then on a path of "C:\":

Action 11:08:53: ServiceOptionsDlg. Dialog created
MSI (c) (CC:24) [11:08:58:414]: PROPERTY CHANGE: Adding ARCHIVE_PATH
property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: PROPERTY CHANGE: Adding
_DirectoryExists_Path property. Its value is 't'.
MSI (c) (CC:24) [11:08:58:543]: Doing action: CheckArchiveDirectory
Action 11:08:58: CheckArchiveDirectory. 
Action start 11:08:58: CheckArchiveDirectory.
MSI (c) (CC:80) [11:08:58:573]: Invoking remote custom action. DLL:
C:\Users\e25735\AppData\Local\Temp\MSIF23D.tmp, Entrypoint:
DirectoryExists
MSI (c) (CC:A8) [11:08:58:574]: Cloaking enabled.
MSI (c) (CC:A8) [11:08:58:574]: Attempting to enable all disabled
privileges before calling Install on Server
MSI (c) (CC:A8) [11:08:58:575]: Connected to service for CA interface.
Action ended 11:11:02: CheckArchiveDirectory. Return value 1.
MSI (c) (CC:24) [11:11:06:126]: Doing action: CheckArchiveDirectory
Action 11:11:06: CheckArchiveDirectory. 
Action start 11:11:06: CheckArchiveDirectory.
MSI (c) (CC:A0) [11:11:06:184]: Invoking remote custom action. DLL:
C:\Users\e25735\AppData\Local\Temp\MSIE4A7.tmp, Entrypoint:
DirectoryExists
MSI (c) (CC:A0) [11:11:06:184]: Lost connection to custom action server
process. Attempting to regenerate.
MSI (c) (CC:A8) [11:11:06:259]: Cloaking enabled.
MSI (c) (CC:A8) [11:11:06:259]: Attempting to enable all disabled
privileges before calling Install on Server
MSI (c) (CC:A8) [11:11:06:259]: Connected to service for CA interface.
MSI (c) (CC!8C) [11:11:31:366]: PROPERTY CHANGE: Adding
_DirectoryExists_Result property. Its value is 'no'.
Action ended 11:11:47: CheckArchiveDirectory. Return value 1.
MSI (c) (CC:24) [11:11:47:571]: PROPERTY CHANGE: Adding VErr_Text
property. Its value is 'The archive path specified does not exist.'.
Action

Re: [WiX-users] SharedDllRefCount on Upgrade

2010-10-19 Thread gapearce


Well!  That's exactly what's going on here.  The overlapping keyfile thing is
the problem - After fixing this (by puttting keyfile on the right file (NOT
the component)), the problem is solved!  

Phil and Blair: you've both been a big help.

Thanks again for looking at this weird problem (that I caused all by
myself...ugh)...

Greg


-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SharedDllRefCount-on-Upgrade-tp5639450p5651089.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSI upgrade remove old registries

2010-10-19 Thread Yu, Brian

Hi Nick

I've just found out about your book and I'll buy it soon

Point1) I am using WIX to write registries, an example is provided

  
...


  


...


And is then referenced in the product.wxs


...



Point2) I think I am a bit confused about major and minor/small upgrade 

 My first installer installs some files and registry
 My second installer then updates the files (90%) to new
versions
 With some addition, edition to registry
 But I expect the registry values added by first installer to
remain if I have not touched them by second installer.
 In this scenario, should I not do major upgrade? 
   My impression of what you said is that major upgrade will remove
registry values from first installer not touched by second

When I tried to do a minor upgrade, I remember I kept the
upgrade and product code the same
And I had to run from in command line with REINSTALL=ALL
REINSTALLMODE=vomus
The problem was that it puts the registry values back to what
the installer default had, but we need to have them unchanged.

Point3) Please let me know if I should do a major and minor upgrade. 
At this point, both ways don't work and I am stuck



Regards
Brian


-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com] 
Sent: 18 October 2010 17:46
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MSI upgrade remove old registries


A major upgrade, as you probably know, will completely remove the old
version. So, if your second installer does not write to the registry, it
makes sense that the value will be removed but not replaced. You
shouldn't
change the UpgradeCode for the lifetime of the product, across all
upgrade
scenarios. 

Are you using WiX to write to the Registry? What does that code look
like
then? 

How have you got the minor upgrade set up? Is it a patch? Or a full
install?
Does it use WiX elements to write to the Registry?
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-upgrad
e-remove-old-registries-tp5639349p5647762.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that
run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

_
This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are 
incorporated under the laws of England and Wales (company no. 05677531 and VAT 
registration no. 872810613). Our registered office is at 155 Bishopsgate, 
London EC2M 3TQ. This e-mail and/or any attached documents may contain 
privileged and confidential information and should only be read by those 
persons to whom this e-mail is addressed. Use by other than intended recipients 
is prohibited. If you are not the addressee, you must not copy, distribute, 
disclose or use any of the information in it. If you have received it in error, 
please delete it and immediately notify the sender. EASYSCREEN reserves the 
right to monitor all e-mail messages passing through its network. As we cannot 
guarantee the genuineness, accuracy or completeness of the information 
contained in this message, the statements set forth are not legally binding.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Include question.

2010-10-19 Thread sagar shinde

Just add ur merg module in ur main project directory where you want to put
files after installation,
and don't furget to add module referance in feature of your main project,
i hope this will work.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Include question.

2010-10-19 Thread jhennessey


Good catch, I didn't even notice he was creating a merge module.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5650417.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix Mailing list

2010-10-19 Thread Bruce Cran

On Tue, 19 Oct 2010 10:29:50 +0200
Ino Murko  wrote:

> Can you please unsubscribe me from Wix mailing list?

Your syntax was wrong:

List-Unsubscribe:
,


So your subject should have been "unsubscribe" (not "Wix Mailing list")
and sent only to wix-users-request@, not wix-users@ . Alternatively,
visit the sourceforge page.

-- 
Bruce Cran

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix Mailing list

2010-10-19 Thread Ino Murko

Can you please unsubscribe me from Wix mailing list?

DubleG

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Fwd: Wix Mailing list

2010-10-19 Thread Ino Murko

Can you please unsubscribe me from Wix mailing list?

DubleG

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module

2010-10-19 Thread sagar shinde

Thanks for reply

I am using same machine for both projects the merge module as well as main
project. There is no OS difference or any other configuration change
if i do merge module with only language "1033"  it works properly, but when
i tried to do it with localization
just i tried to do the things with foreach loop but it doesn't seems working
for me can you please suggest me properway to achive localization with
merge  module

Thank's
Sagar S.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module

Re: [WiX-users] WiX book available

Re: [WiX-users] WiX 3.5 C# Custom Action Project

Re: [WiX-users] WiX 3.5 C# Custom Action Project

Re: [WiX-users] Merge Module

Re: [WiX-users] Calling a managed custom action from a UI control

Re: [WiX-users] Calling a managed custom action from a UI control

Re: [WiX-users] Do WiX 3.0 link times improve using .wixlib files?

Re: [WiX-users] WiX 3.5 C# Custom Action Project

Re: [WiX-users] Prerequisite check for per-user vs per-machine installation

Re: [WiX-users] Calling a managed custom action from a UI control

Re: [WiX-users] SharedDllRefCount on Upgrade

Re: [WiX-users] MSI upgrade remove old registries

Re: [WiX-users] Include question.

Re: [WiX-users] Include question.

Re: [WiX-users] Wix Mailing list

[WiX-users] Wix Mailing list

[WiX-users] Fwd: Wix Mailing list

Re: [WiX-users] Merge Module

19 matches

Site Navigation

Mail list logo

Footer information