Re: [WiX-users] Understanding component states
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?
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
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
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?
| 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
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
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
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
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
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
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
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
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
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