Re: [WiX-users] Understanding component states

2009-09-04 Thread Ranganatha H C
Hi,

What is there for your component causing issues in Attribute column in
Component table . (You can use ORCA to see the table content in MSI)

The below link may help.
http://msdn.microsoft.com/hi-in/library/aa368007(en-us,VS.85).aspxhttp://msdn.microsoft.com/hi-in/library/aa368007%28en-us,VS.85%29.aspx


Ranganatha


On Wed, Sep 2, 2009 at 4:55 AM, Don Pratt don.pr...@cox.net wrote:

 Thanks Blair and Phil.

 We sequence RemoveExistingProducts before InstallInitialize, but do not
 use Side-by-Side or GAC.

 I'm pretty sure we're doing major upgrade correctly.  We keep the
 UpgradeCode constant and put in a new ProductCode for each new version.
 We let WiX auto-gen the PackageCode.

 One thing I should have mentioned to start with is that this isn't the
 first major upgrade we've done for this product.  Upgrade from v11.2.0
 to 11.2.1 works fine.  Upgrade from 11.2.x to 11.2.2 (the current
 release) ends up dropping this one file.

 Thanks again for the help.  I know trying to troubleshoot remotely can
 be tricky.  If there are other pieces of the log file or our WiX source
 that would be helpful, just let me know.

 Don

 Blair wrote:
  Normally if the component was already installed the Installed: part of
 the
  spew would read Local, not Absent.
 
  Does your component use either Side-by-Side or GAC? There are known
 issues
  with upgrades when RemoveExistingProducts is sequenced too early for
  Windows Installer's interface to those technologies (fusion).
 
  You are sure this is a major upgrade. The ProductCodes are different
 between
  the two packages, correct?
 
  -Original Message-
  From: Wilson, Phil [mailto:phil.wil...@wonderware.com]
  Sent: Tuesday, September 01, 2009 3:18 PM
  To: General discussion for Windows Installer XML toolset.
  Subject: Re: [WiX-users] Understanding component states
 
  I read that to mean that the component is already installed and doesn't
 need
  updating from your new setup, perhaps because the versions are identical.
  Your RemoveExistingProducts is probably sequenced to run at the end of
 your
  install, so it's applying update rules.  In some cases you might see a
  message something like {guid} will not be installed because the same or
 a
  higher-versioned keyfile is already installed, the same situation.
 
  Phil Wilson
 
 
  -Original Message-
  From: Don Pratt [mailto:don.pr...@cox.net]
  Sent: Tuesday, September 01, 2009 1:35 PM
  To: General discussion for Windows Installer XML toolset.
  Subject: [WiX-users] Understanding component states
 
  Hi,
 
  I'm having trouble understanding why one component is failing to get
  installed.  I'm doing a major upgrade, and this component exists in both
  the old and new versions of my package.  If I manually uninstall the old
  version and then do a normal install of the new version, the problem
  component does get installed.
 
  Looking in an MSI log, during the InstallValidate action I see:
  MSI (s) (C4:94) [15:51:13:079]: Component: SPCControls_dll; Installed:
  Absent;   Request: Local;   Action: Null
 
  I have a relatively simple installer with a single feature that contains
  everything.  This component doesn't have any conditions.  I dark'ed this
  MSI and our previous MSI (which handles a major upgrade just fine) and
  they both show identical markup for the component in question.  None of
  the other components seem to have problems.
 
  What else should I look for to understand why the action for this
  component is getting set to 'Null'?
 
  Thanks,
  Don Pratt
 
 
 
 
  --
  Let Crystal Reports handle the reporting - Free Crystal Reports 2008
 30-Day
  trial. Simplify your report design, integration and deployment - and
 focus
  on
  what you do best, core application coding. Discover what's new with
  Crystal Reports now.  http://p.sf.net/sfu/bobj-july
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 
 
  --
  Let Crystal Reports handle the reporting - Free Crystal Reports 2008
 30-Day
  trial. Simplify your report design, integration and deployment - and
 focus
  on
  what you do best, core application coding. Discover what's new with
  Crystal Reports now.  http://p.sf.net/sfu/bobj-july
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 --
  Let Crystal Reports handle the reporting - Free Crystal Reports 2008
 30-Day
  trial. Simplify your report design, integration and deployment - and
 focus on
  what you do best, core application coding. Discover what's new with
  Crystal Reports now.  

Re: [WiX-users] How to show different language license files?

2009-09-04 Thread Jiang, Chunyan (GE Healthcare)
Many thanks to Blair and Neil!

I formatted the license files to rtf format. And I tried the simple way as Neil 
suggested. It works good. I tried both Visual Studio build and command line 
build, they all work.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Freitag, 4. September 2009 02:42
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] How to show different language license files?

From Visual Studio: instead of using the Cultures property to make 
several
MSIs with different EULAs, you need to instead either make different wixproj 
files (one for each license) or separate your default language build from 
your localized language builds and override the property you use to set the 
license rtf file in each separate invocation of MSBuild. This of course means 
you have just made your build process more complicated.

We should write a proposal to make the current cultures accessible from the 
linker somehow (such as a linker or binder var) so that building multiple MSIs 
(one for each culture) from one invocation of one project can change EULAs or 
alternately allow WixUILicenseRtf to be a loc var instead of a wix var.

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Thursday, September 03, 2009 10:22 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] How to show different language license files?

Let me retract my solution. At one time they were in the same namespace, but it 
appears that doesn't work now.

Are you building from VS/MSBuild or from command-line (such as 
makefile/nant/etc.)?

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Thursday, September 03, 2009 9:54 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to show different language license files?

Your license files MUST be RTF, not plain text.

WixVariables and WiX Localization values (even though they are accessed using 
two different namespaces: var  loc) actually occupy the same namespace. So, 
here is what you do:

In your .wxl files, create a string called WixUILicenseRtf. Remove the entry 
for licenseRtf from your .wixproj, and put that path in your English .wxl file 
as the value of the WixUILicenseRtf string. In your other .wxl files (for your 
other languages) you instead use the paths to your translated RTF license files.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Thursday, September 03, 2009 1:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to show different language license files?

Hi Wix-users,
 
I want to show the license text in the license dialog. According to the 
example, 
 
Control Id=LicenseText Type=ScrollableText X=20 Y=60
Width=330 Height=140 Sunken=yes TabSkip=no

Text SourceFile=!(wix.WixUILicenseRtf=$(var.licenseRtf)) /

/Control

And in .wixproj, define:

licenseRtf=D:\Work\Program
Doc\Wix\src\ext\UIExtension\wixlib\license.rtf; 

Then the license dialog can show the license text. However, if I want to show 
license as different language. How can I do it? I have alreay different 
language license text files, like germany.txt, france.txt, italy.txt.

 

Best regards,

 

Chunyan 


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with Crystal 
Reports now.  http://p.sf.net/sfu/bobj-july 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with Crystal 
Reports now.  http://p.sf.net/sfu/bobj-july 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with Crystal 
Reports now.  http://p.sf.net/sfu/bobj-july 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Let Crystal Reports 

[WiX-users] Query regarding Localization of Windows Installer

2009-09-04 Thread mahesh u
Hi All,

I read about localizing a MSI installer using Wix. It seems like I need to
localize the installer by using appropriate language .wxl file during MSI
package creation time itself.

So, Is there any way I can localize installer UI dynamically i.e. something
like when Installer starts up detect the OS language and localize it to that
language?

Thanks,
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] HttpHeader doesn't handle the duplicated elements correctly and breaks custom headers in IIS

2009-09-04 Thread Yan Sklyarenko
Hello WiX Community,

I’ve faced with a problem, which seems to be a bug in IIS extension. 

I have a Website element (in a component), which contains HttpHeader element. 
When I run the installation, it changes the custom headers in IIS in the 
following way:
  -- if there's no such header name, it registers new header correctly
  -- if there's a header with such name, it adds another one (or more) with 
unreadable content, like this
  ē꾱栀킆栀鑠栀阸栀騢栀먤栀뾊栀沎栀焀栀ꪮ栀唰ǔ∢∢

I'm not sure you can all read the line above, it looks like Chinese hieroglyphs 
to me. 

Expected behavior: if there's a header with such a name, the HttpHeader element 
should update it with new value.
In my example I would like to change an existing header from X-Powered-By: 
ASP.NET to X-Powered-By: ASP.NET; My Product.

Does anyone know the workaround? I've checked for IIS 5.1 so far.

WiX developers, can you confirm it is a bug?

Thank you!

-- Yan

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] RES: Is it possible to read registry during execution?

2009-09-04 Thread André Werlang
| Could you instead write that registry value in its own component
| after computing it based on the installation states of the other
| components that need to contribute to it?

Hi Blair,

I think I'll go that way...I even tried to use SetProperty each time a
component is processed, to build the final string and write to registry
only once, but an ICE validation complained about the duplicate action.
Can I do this in an iterative fashion instead of a bunch of conditions?


André Felipe Werlang

  Antes de imprimir pense em seu compromisso com o Meio Ambiente
 e o comprometimento com os Custos

-Mensagem original-
De: Blair [mailto:os...@live.com]
Enviada em: 3 de setembro de 2009 19:25
Para: 'General discussion for Windows Installer XML toolset.'
Assunto: Re: [WiX-users] Is it possible to read registry during execution?

Not without replacing the WriteRegistryValues built-in action. Even then it 
would be a severe violation of the component rules.

What happens is that the costing actions determine which components will be 
installed. Each of the other actions then reference the action state of each 
component referenced in their respective tables and then blasts those values 
out to the respective locations. The only built-in support for registry value 
concatenation is for multi-string registry values where each appended string is 
an additional string in the value, not a concatenation on any existing string.

Could you instead write that registry value in its own component after 
computing it based on the installation states of the other components that need 
to contribute to it?

-Original Message-
From: André Werlang [mailto:and...@gvdasa.com.br]
Sent: Thursday, September 03, 2009 1:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Is it possible to read registry during execution?

Hi!

I have a dozen components such that for each it can be written on registry
the same key entry, concatenating with the old value.
But, I've just found that RegistrySearch is made during AppSearch, which happens
to be the first action in execute sequence, so my approach didn't work.

Can it be made that the reading is accomplished just before it is written again?

Thanks


André Felipe Werlang

  Antes de imprimir pense em seu compromisso com o Meio Ambiente
 e o comprometimento com os Custos

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] RES: Specifying source files

2009-09-04 Thread André Werlang
Hi,

Yes, my fault - i'm using heat.

Here's the command line:

heat dir .\wPDF -cg wPDFGroup -dr APPLICATIONFOLDER -ke -gg -nologo 
-sfrag -sreg -svb6 -scom -template:fragment -out wPDFGroup.wxs

And Product's directory struture:

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=ProgramFilesFolder
Directory Id=APPLICATIONFOLDER Name=GVSetup
/Directory
  /Directory
/Directory

I tried setting APPLICATIONFOLDER's @FileSource to the actual location, with 
and without wPDF in the path and it still can't find the file.

I'd appreciate any comment on this...I think I'm missing something.


André Felipe Werlang

  Antes de imprimir pense em seu compromisso com o Meio Ambiente
 e o comprometimento com os Custos


-Mensagem original-
De: Blair [mailto:os...@live.com]
Enviada em: 3 de setembro de 2009 21:05
Para: 'General discussion for Windows Installer XML toolset.'
Assunto: Re: [WiX-users] Specifying source files

I think Andre is looking to use the Identifying files by name and directory
tree method described in the Specifying source files topic in wix.chm.

Andre, I suspect the problem has more to do with the way that your fragments
are generated. I assume you used Heat.exe. What was your entire exact
commandline?

The reason it couldn't find the files when you removed the SourceDir\ part
of your @Source would depend on the @FileSource value for the
APPLICATIONFOLDER directory which you don't show in your email.

-Original Message-
From: Chris Lord [mailto:chris.l...@atterotech.com]
Sent: Thursday, September 03, 2009 9:15 AM
To: wix-users
Subject: Re: [WiX-users] Specifying source files

The source has no affect on the location the file is placed when it is
installed on the target machine.  That is set by the directory structure
you have defined with the directory components.

The source should point to the file location of CID_Demo.pdf on your
machine that is to be included in the installation.  This can be an
absolute reference such as
C:\program files\installer\CID_Demo.pdf

Or a relative one such as in your snippet
SourceDir\CID_Demo.pdf

If a relative path is given, Light uses the folder location of the
source file it's processing as a base and adds the source location to it
to create an absolute reference to the file it needs.  If the file does
not exist in that location, Light will then give an error.

For example, if the fragment containing the snippet below is located in
a file in c:\program files\Wix, Light will be looking to include the
following file:
c:\program files\Wix\SourceDir\CID_Demo.pdf.

The simplest way to fix it is just to change the source to be the actual
location of the CID_Demo.pdf file on your machine.

Chris


-Original Message-
From: André Werlang [mailto:and...@gvdasa.com.br]
Sent: Thursday, September 03, 2009 10:24
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Specifying source files

Hi.

I'm generating a .wxs for a directory structure called wPDF just below
base input path. i.e.

+ SourceDir
|
+--+ wPDF
   |
   +-- CID_Demo.pdf
   ...

It is generated a fragment like this:

DirectoryRef Id=APPLICATIONFOLDER
Directory Id=dir905B51C2A07DFF9A1FC94352B9FF6E43
Name=wPDF
Component Id=cmp033B46C482346EB39AB9256BCF6ACFBA
Guid={C2D8AB1E-A06C-4132-8D94-8A51EF576ADA}
File Id=fil976FBB6708A816CF5F68BBDF59FFA4F4
KeyPath=yes Source=SourceDir\CID_Demo.pdf /
/Component
...

Light isn't able of locating source files, because they're in wPDF
subdirectory. If I change references to SourceDir\wPDF\, then it works.
What I find weird is that if I remove SourceDir leaving the file alone,
it still can't locate the file, I'd expect it to use the path of the
Directory above. And I hadn't managed to make Directory/@FileSource
work.

My question is: how can I generate this source file ready to link? I've
seen -var option, maybe it's the easiest way...any tips?

Thanks in advance.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus on what you do best, core application coding. Discover what's
new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing 

[WiX-users] Copying folders from the target directory to a folder in ProgramFiles

2009-09-04 Thread Sam K
Hi There,
I need to copy files from a folder, say targetdir\xxx to
programfilesfolder\yyy. The targetdir (for ex d:\) is different than the
programfilesfolder (c:\) and there can only be one targetdir.
Is there a way to do that? Can I do it using a Custom action? Can somebody
please reply?
Thanks a lot.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Copying folders from the target directory to a folderin ProgramFiles

2009-09-04 Thread David Watson
Not sure what you want exactly but have you looked at the copyfile
element ?

http://wix.sourceforge.net/manual-wix3/wix_xsd_copyfile.htm

Dave 

-Original Message-
From: Sam K [mailto:sam.re...@gmail.com] 
Sent: 04 September 2009 15:29
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Copying folders from the target directory to a
folderin ProgramFiles

Hi There,
I need to copy files from a folder, say targetdir\xxx to
programfilesfolder\yyy. The targetdir (for ex d:\) is different than the
programfilesfolder (c:\) and there can only be one targetdir.
Is there a way to do that? Can I do it using a Custom action? Can
somebody please reply?
Thanks a lot.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus on what you do best, core application coding. Discover what's
new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Multiple Driver Packages

2009-09-04 Thread Thomas Svare
I had the same situation and once I put the .inf, .sys and supporting
dlls into different directories it worked fine.

Thanks,
Tom

-Original Message-
From: Jeremy Farrell [mailto:jfarr...@pillardata.com] 
Sent: Friday, September 04, 2009 1:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Driver Packages

 From: Slide [mailto:slide.o@gmail.com] 
 
 I have two drivers that I need to install, I currently have 
 two inf files for them. Apparently DIFXAPP doesn't support
 this as I get the following error:
 
 ...
 DIFXAPP: ERROR: more than one driver package found in 'C:\Program
 Files\MYAPP\'
 DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
 DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
 Action ended 20:52:22: InstallFinalize. Return value 3.
 
 Do I have to combine the two drivers into a single inf file?

Just based on the error message, it looks like putting the different
packages in different directories would work.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Multiple Driver Packages

2009-09-04 Thread Jeremy Farrell
 From: Slide [mailto:slide.o@gmail.com] 
 
 I have two drivers that I need to install, I currently have 
 two inf files for them. Apparently DIFXAPP doesn't support
 this as I get the following error:
 
 ...
 DIFXAPP: ERROR: more than one driver package found in 'C:\Program
 Files\MYAPP\'
 DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
 DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
 Action ended 20:52:22: InstallFinalize. Return value 3.
 
 Do I have to combine the two drivers into a single inf file?

Just based on the error message, it looks like putting the different
packages in different directories would work.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Multiple Driver Packages

2009-09-04 Thread Quinton Tormanen
I found that they need to be installed to separate directories. We
install two drivers in this way.

For example, install one to C:\Program Files\MyApp\Driver1 and the other
to C:\Program Files\MyApp\Driver2, or we actually install one as a
subdirectory of the other.

--Quinton

-Original Message-
From: Slide [mailto:slide.o@gmail.com] 
Sent: Thursday, September 03, 2009 9:02 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Driver Packages

I have two drivers that I need to install, I currently have two inf
files
for them. Apparently DIFXAPP doesn't support this as I get the following
error:

DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is
'{508258F9-33BA-4362-B532-590D1842BB23}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is
'C:\Program
Files\MYAPP\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xE.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'MYAPP
Software'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'ME,
Inc.'.
DIFXAPP: INFO: user SID of user performing the install is 'SIDHERE'.
DIFXAPP: INFO: opening
HKEY_USERS\SIDHERE\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Com
ponents\{508258F9-33BA-4362-B532-590D1842BB23}
(User's SID: 'S-1-5-21-1801674531-527237240-682003330-50333') ...
DIFXAPP: ERROR: more than one driver package found in 'C:\Program
Files\MYAPP\'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
Action ended 20:52:22: InstallFinalize. Return value 3.

Do I have to combine the two drivers into a single inf file?

Thanks,

slide

-- 
slide-o-blog
http://slide-o-blog.blogspot.com/

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] HttpHeader doesn't handle the duplicated elements correctly and breaks custom headers in IIS

2009-09-04 Thread Blair
Smells like a codepage issue.

Crack open your MSI with Orca. What do your IIsHttpHeader table contents look 
like?

-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net] 
Sent: Friday, September 04, 2009 3:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] HttpHeader doesn't handle the duplicated elements 
correctly and breaks custom headers in IIS

Hello WiX Community,

I’ve faced with a problem, which seems to be a bug in IIS extension. 

I have a Website element (in a component), which contains HttpHeader element. 
When I run the installation, it changes the custom headers in IIS in the 
following way:
  -- if there's no such header name, it registers new header correctly
  -- if there's a header with such name, it adds another one (or more) with 
unreadable content, like this
  ē꾱栀킆栀鑠栀阸栀騢栀먤栀뾊栀沎栀焀栀ꪮ栀唰ǔ∢∢

I'm not sure you can all read the line above, it looks like Chinese hieroglyphs 
to me. 

Expected behavior: if there's a header with such a name, the HttpHeader element 
should update it with new value.
In my example I would like to change an existing header from X-Powered-By: 
ASP.NET to X-Powered-By: ASP.NET; My Product.

Does anyone know the workaround? I've checked for IIS 5.1 so far.

WiX developers, can you confirm it is a bug?

Thank you!

-- Yan

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Query regarding Localization of Windows Installer

2009-09-04 Thread Blair
There is a naming convention of transforms you embed into your MSI that
causes Windows Installer to automatically apply one of them based on the OS
(or User? I don't know) language. Unfortunately it is unsupported, but it
has worked for all the recent versions of Windows Installer released so far
(I don't know how far back it works, I personally try to stay away from
non-supported behaviors).

You would build localized MSIs (using your .wxl files) by linking them
repeatedly using the different culture values each time, and then use the
Torch tool to generate MST files (doffing your English from your localized
ones), which you then use the SDK to embed into your English MSI you used
each time you called torch.

You would need to search for that convention. I know it has been mentioned
in this list as well as on some blogs I have read.

-Original Message-
From: mahesh u [mailto:maheshu.u...@gmail.com] 
Sent: Friday, September 04, 2009 3:34 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Query regarding Localization of Windows Installer

Hi All,

I read about localizing a MSI installer using Wix. It seems like I need to
localize the installer by using appropriate language .wxl file during MSI
package creation time itself.

So, Is there any way I can localize installer UI dynamically i.e. something
like when Installer starts up detect the OS language and localize it to that
language?

Thanks,

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus
on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] RES: Specifying source files

2009-09-04 Thread Blair
Looking at the help spew from Heat, I noticed something interesting. The -var 
argument:

   -var VariableName  substitute File/@Source=SourceDir with a preprocessor 
variable
(e.g. -var var.MySource will become File/@Source=$(var.MySource)\myfile.txt).

Try adding -var var.wPDF to your Heat commandline, and -dwPDF=SourceDir\wPDF 
to your Candle commandline (at least the instance that builds the file Heat 
produces).

I haven't tested this, but it looks worth a try to me.

-Original Message-
From: André Werlang [mailto:and...@gvdasa.com.br] 
Sent: Friday, September 04, 2009 6:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] RES: Specifying source files

Hi,

Yes, my fault - i'm using heat.

Here's the command line:

heat dir .\wPDF -cg wPDFGroup -dr APPLICATIONFOLDER -ke -gg -nologo 
-sfrag -sreg -svb6 -scom -template:fragment -out wPDFGroup.wxs

And Product's directory struture:

Directory Id=TARGETDIR Name=SourceDir
  Directory Id=ProgramFilesFolder
Directory Id=APPLICATIONFOLDER Name=GVSetup
/Directory
  /Directory
/Directory

I tried setting APPLICATIONFOLDER's @FileSource to the actual location, with 
and without wPDF in the path and it still can't find the file.

I'd appreciate any comment on this...I think I'm missing something.


André Felipe Werlang

  Antes de imprimir pense em seu compromisso com o Meio Ambiente
 e o comprometimento com os Custos


-Mensagem original-
De: Blair [mailto:os...@live.com]
Enviada em: 3 de setembro de 2009 21:05
Para: 'General discussion for Windows Installer XML toolset.'
Assunto: Re: [WiX-users] Specifying source files

I think Andre is looking to use the Identifying files by name and directory
tree method described in the Specifying source files topic in wix.chm.

Andre, I suspect the problem has more to do with the way that your fragments
are generated. I assume you used Heat.exe. What was your entire exact
commandline?

The reason it couldn't find the files when you removed the SourceDir\ part
of your @Source would depend on the @FileSource value for the
APPLICATIONFOLDER directory which you don't show in your email.

-Original Message-
From: Chris Lord [mailto:chris.l...@atterotech.com]
Sent: Thursday, September 03, 2009 9:15 AM
To: wix-users
Subject: Re: [WiX-users] Specifying source files

The source has no affect on the location the file is placed when it is
installed on the target machine.  That is set by the directory structure
you have defined with the directory components.

The source should point to the file location of CID_Demo.pdf on your
machine that is to be included in the installation.  This can be an
absolute reference such as
C:\program files\installer\CID_Demo.pdf

Or a relative one such as in your snippet
SourceDir\CID_Demo.pdf

If a relative path is given, Light uses the folder location of the
source file it's processing as a base and adds the source location to it
to create an absolute reference to the file it needs.  If the file does
not exist in that location, Light will then give an error.

For example, if the fragment containing the snippet below is located in
a file in c:\program files\Wix, Light will be looking to include the
following file:
c:\program files\Wix\SourceDir\CID_Demo.pdf.

The simplest way to fix it is just to change the source to be the actual
location of the CID_Demo.pdf file on your machine.

Chris


-Original Message-
From: André Werlang [mailto:and...@gvdasa.com.br]
Sent: Thursday, September 03, 2009 10:24
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Specifying source files

Hi.

I'm generating a .wxs for a directory structure called wPDF just below
base input path. i.e.

+ SourceDir
|
+--+ wPDF
   |
   +-- CID_Demo.pdf
   ...

It is generated a fragment like this:

DirectoryRef Id=APPLICATIONFOLDER
Directory Id=dir905B51C2A07DFF9A1FC94352B9FF6E43
Name=wPDF
Component Id=cmp033B46C482346EB39AB9256BCF6ACFBA
Guid={C2D8AB1E-A06C-4132-8D94-8A51EF576ADA}
File Id=fil976FBB6708A816CF5F68BBDF59FFA4F4
KeyPath=yes Source=SourceDir\CID_Demo.pdf /
/Component
...

Light isn't able of locating source files, because they're in wPDF
subdirectory. If I change references to SourceDir\wPDF\, then it works.
What I find weird is that if I remove SourceDir leaving the file alone,
it still can't locate the file, I'd expect it to use the path of the
Directory above. And I hadn't managed to make Directory/@FileSource
work.

My question is: how can I generate this source file ready to link? I've
seen -var option, maybe it's the easiest way...any tips?

Thanks in advance.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus