[WiX-users] File table won't get transformed
I have an English and a Japanese MSI After creating a japanese transform using msitran and embedding using msidb. i see that the japanese resource files are not embedded in the file table when i opened the MSI using orca ( OR transform will not contain the resource files??) As a result, when the installation tries to refer to the japanese resources, it fails throwing a message tht the file0_japanese cannot be found in the resource.cab which is an embedded cab file. How do i modify file table using the transform?? any ideas?? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/File-table-won-t-get-transformed-tp4131193p4131193.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] File table won't get transformed
I have an English and a Japanese MSI After creating a japanese transform using msitran and embedding using msidb. i see that the japanese resource files are not embedded in the file table when i opened the MSI using orca ( OR transform will not contain the resource files??) As a result, when the installation tries to refer to the japanese resources, it fails throwing a message tht the file0_japanese cannot be found in the resource.cab which is an embedded cab file. How do i modify file table using the transform?? any ideas?? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/File-table-won-t-get-transformed-tp4131192p4131192.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Deferred Custom Action
Hi, I have a custom action that makes a registry entry both during install and uninstall. The custom action is deferred and thus I use another custom action to set the custom action data. This works well in both scenarios (install and uninstall). However if UAC is turned on, then the uninstall custom action fails. The custom action called during install works correctly. The uninstall custom action is called but the problem I figured is that the office version passed as Custom Action data is not getting set. I fail to understand as to why it is not getting set during uninstall since, during install (when UAC is on) the property gets set. What change should I make to my custom action called during uninstall in UAC mode so that the custom action data is set? The install execute sequence is as follows: !-- Custom actions for registry entry -- CustomAction Id=RegistryEntries.Setup Property=RegistryEntries Value= OfficeVersion=[OfficeVersion] / CustomAction Id=RegistryEntries BinaryKey=VSTOCustomAction DllEntry= RegisterAddin Execute=deferred Impersonate=no / CustomAction Id=RegistryEntriesUninstall.Setup Property= RegistryEntriesUninstall Value=OfficeVersion=[OfficeVersion] / CustomAction Id=RegistryEntriesUninstall BinaryKey=VSTOCustomAction DllEntry=UnregisterAddin Execute=deferred Impersonate=no / !-- Sets the office version for registry entries -- CustomAction Id=SetOfficeVersion Property=OfficeVersion Value=12.0 Execute=immediate / InstallExecuteSequence Custom Action=SetOfficeVersion After=LaunchConditions![CDATA[some property evaluated in launch condition]]/Custom !-- Registry entry while installing -- Custom Action=RegistryEntries.Setup After=InstallFiles1/Custom Custom Action=RegistryEntries After=RegistryEntries.SetupNOT Installed /Custom !--Registry entry while removing -- Custom Action=RegistryEntriesUninstall.Setup After=InstallFiles1/ Custom Custom Action=RegistryEntriesUninstall After= RegistryEntriesUninstall.SetupInstalled and Remove/Custom /InstallExecuteSequence Thanks in advance, Nandini -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] facing trouble when run the application after installation - EventType : clr20r3
I knows this is old, but if you haven't resolved this... Making an assumption that the .Net application in question already has top level error handlers for the Application.ThreadException event. Does the application work on the problem machine if you run it as an administrator? If yes, then go and work out what you are doing in the .Net code that requires admin and change it :) For example does the app write to the event log? If it does, you need to get it registered as an eventlog source at install time so it behaves nicely for a regular user. If that fails, I've been able to resolve a couple of oddball errors p9: accessdeniedexception and p9: unauthorizedaccessexception by removing .Net 2.0, 3.0 3.5 from the machine and reinstalling them. Hth Phil -Original Message- From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] Sent: Wednesday, September 30, 2009 10:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] facing trouble when run the application after installation - EventType : clr20r3 I think, it's still something bigger than just a WiX issue... Can you manually install the application on the without using an MSI/ WiX and does it work then? Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com On 30.09.2009, at 15:35, danimian wrote: Hi, yes .NET Framework 3.5 SP1 is our basic requirement and it is already installed on target machine. How to deal with this? Any Idea? Best Regards and Thanks for quick reply Adnan Sebastian Brand (Instyler Software) wrote: Hello, I don't think this relates to the installer or WiX. Is .NET installed on the target machine? Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: danimian [mailto:miand...@gmail.com] Sent: Wednesday, September 30, 2009 14:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] facing trouble when run the application after installation - EventType : clr20r3 Hi, i am facing trouble after installation when i run the application (.exe) on other computers. On my Own computer works fine. I am using WIX V3 and OS is Windows XP Professional SP2. (installation working successfully). i am getting the following error: EventType : clr20r3 P1 : my-application.exe P2 : 0.5.3559.24684 P3 : 4ac200cd P4 : system P5 : 2.0.0.0 P6 : 4889de7a P7 : 393b P8 : 5f P9 : system.invalidoperationexception How to fix it to work properly on other computers also? Something need to be change Installer code? Even when i run this application on Windows XP Professional Image on my own computer, i got this error. Best Regards Adnan -- View this message in context: http://n2.nabble.com/facing-trouble-when-run-the-application-after-installat ion-EventType-clr20r3-tp3742479p3742479.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/facing-trouble-when-run-the-application-after-installat ion-EventType-clr20r3-tp3742479p3742714.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf
[WiX-users] Creating MSI containing both 64 bit and 32 bit files
Hi, I have a single setup program for both 64-bit and 32-bit systems. Actually, all my files except one are of 32 bit. I am detecting if the installation is being done on a 64-bit OS or not. If so, then its installing the 64-bit executable file in 'Program Files' folder. If its a 64-bit OS, then I am making some registry entries too, under HKCR. I don't want these reg entries to go under 'WOW6432Node'. So, I am having few components which are 64-bit i.e. I am marking these component elements with Win64='yes' attribute. But, the problem is that when I do such a thing, I start getting ICE80 validation errors something like below... This package contains 64 bit component 'Component64File' but the Template Summary Property does not contain Intel64 or x64. If I provide the Package/@Platform as 'x64', this ICE validation error goes away, but, my setup doesn't install on 32 bit systems. I have seen MSIs doing similar stuff without this ICE validation error. No idea on how they are doing it. Is there any way I can do this i.e. make the MSI work on both 64 bit and 32 bit systems but, without this ICE validation error? Please suggest... Thanking You, With Regards, // Sudripta Nandy -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Different versions of a single file to same location
I have two flavors of the SDK product that my company produces. I offer a merge module for each flavor to our VARs so that they can work the one they want easily into their installers. So far so good. I also provide a single installer for our normal customers that lets the user select which flavor of the SDK to install and it will install the appropriate one. This is what I'm developing now, and I'm having trouble with it. I have this installer project consume both merge modules, each one in a different feature. I have a dialog that lets the user select which flavor of the SDK he wants, and it will AddLocal the chosen feature and Remove the not chosen one. Sounds good so far. Here's the hitch: Both merge modules have different versions of the same binary files. They get installed to the same directory. Now, I know that the files from each will never be installed together, but the compiler doesn't know that and it gives the following error: error LGHT0204 : ICE30: The target file 'sc6wmn0u.inc|PriorAuthID.inc' is installed in '[TARGETDIR]\xml\templates\' by two different components on an LFN system: 'PriorAuthID.inc.A254A491_D1A5_43DC_88CF_363C10407599' and 'PriorAuthID.inc.29B29778_DD77_4C31_A8FA_A74751B94965'. This breaks component reference counting. Is there a way to make this work? -- Brad -- Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Two Custom Action entry points in one C++ Dll and WcaLog failure
The WiX toolset has plenty of custom actions that are combined in the same DLL. Something else is wrong. Did you call WcaIitialize() at the beginning of each custom action? Is this custom action the target of a control event? On Mon, Dec 7, 2009 at 3:44 PM, Tony Juricic tjuri...@tradestation.comwrote: At one point I was thinking that I have too many C++ Custom Action Dlls and started using existing Dlls. That is, I added a new entry point for a new CA in a Dll that already hosted code for existing CA. That appears to work just fine except for one issue: WcaLog() doesn't work - nothing gets output in a log! I don't know if the fact that I have 2 CA and 2 entry points in this DLL is relevant, but this is the only case where WcaLog doesn't work. I am using calls like: ::WcaLog(LOGMSG_STANDARD, Install folder %S created., Path); so there is hardly anything mysterious here that can fail when many similar calls in many other CA Dlls work. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade
Managed code files have two independent version numbers: the AssemblyVersion and the AssemblyFileVersion. The AssemblyVersion is part of the assembly's identity. The AssemblyFileVersion is not part of the identity (as far as .NET is concerned), but is the only one of the two that Windows Installer can access (and which it uses to make upgrade determinations). If you can change the AssemblyFileVersion then I can help you remove the registry key. -Original Message- From: Ana Martic [mailto:t-anm...@microsoft.com] Sent: Monday, December 07, 2009 10:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade The key itself contains the version it looks like e.g. CLSID/GUID/1.0.0.0. A file is a keypath of that component. I also have to add that it's impossible for me to change the assembly's version. From: Blair [os...@live.com] Sent: Monday, December 07, 2009 5:03 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade Is the registry value containing the version number the keypath if its component? -Original Message- From: Ana Martic [mailto:t-anm...@microsoft.com] Sent: Monday, December 07, 2009 7:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade Hi, While creating an installer that should do a major upgrade I firstly faced the problem that the registry key containing a version number (of the previous version) doesn't get removed. In order to make it possible that the installer of the upgrade removes it I changed the GUID of the component containing that registry key. I experienced that the component with the new GUID gets installed only if I schedule RemoveExistingProducts after InstallInitialize. But in order not to remove an assembly from GAC I have to schedule it after InstallFinalize. Can I find some work around for this problem so that I remove the registry key and keep the assembly? Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Different versions of a single file to same location
It is a component rule violation that is easy for an ICE-style test to ascertain. Not just must those two components be mutually exclusive, they must also never be transitive unless you want unexpected things to happen. Having said that, -sice:ICE30 should suppress the error and allow you to build. -Original Message- From: Younie, Bradford [mailto:bradford.you...@chasepaymentech.com] Sent: Tuesday, December 08, 2009 6:59 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Different versions of a single file to same location I have two flavors of the SDK product that my company produces. I offer a merge module for each flavor to our VARs so that they can work the one they want easily into their installers. So far so good. I also provide a single installer for our normal customers that lets the user select which flavor of the SDK to install and it will install the appropriate one. This is what I'm developing now, and I'm having trouble with it. I have this installer project consume both merge modules, each one in a different feature. I have a dialog that lets the user select which flavor of the SDK he wants, and it will AddLocal the chosen feature and Remove the not chosen one. Sounds good so far. Here's the hitch: Both merge modules have different versions of the same binary files. They get installed to the same directory. Now, I know that the files from each will never be installed together, but the compiler doesn't know that and it gives the following error: error LGHT0204 : ICE30: The target file 'sc6wmn0u.inc|PriorAuthID.inc' is installed in '[TARGETDIR]\xml\templates\' by two different components on an LFN system: 'PriorAuthID.inc.A254A491_D1A5_43DC_88CF_363C10407599' and 'PriorAuthID.inc.29B29778_DD77_4C31_A8FA_A74751B94965'. This breaks component reference counting. Is there a way to make this work? -- Brad -- Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating MSI containing both 64 bit and 32 bit files
An MSI marked as 64-bit simply will not install on a 32-bit system. Nothing you can do. An MSI marked as 32-bit simply cannot place files into a 64-bit directory (they will be redirected to 32-bit equivalent folders). Nothing you can do. An MSI cannot be marked as both 32- and 64-bit. Also nothing you can do. Did you run the ICE tests on those MSIs you see doing similar stuff to verify that they don't have ICE80 errors? I've never seen one in that state. The correct method is to generate two MSIs, one for 32-bit platforms and another for 64-bit platforms. They can share the same external cab files if you need to ship them together to save space. If you do that, you can use a bootstrapper to extract the appropriate one with your CAB(s) and install it. -Original Message- From: Sudripta Nandy [mailto:sudrip...@sarangsoft.co.in] Sent: Tuesday, December 08, 2009 5:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating MSI containing both 64 bit and 32 bit files Hi, I have a single setup program for both 64-bit and 32-bit systems. Actually, all my files except one are of 32 bit. I am detecting if the installation is being done on a 64-bit OS or not. If so, then its installing the 64-bit executable file in 'Program Files' folder. If its a 64-bit OS, then I am making some registry entries too, under HKCR. I don't want these reg entries to go under 'WOW6432Node'. So, I am having few components which are 64-bit i.e. I am marking these component elements with Win64='yes' attribute. But, the problem is that when I do such a thing, I start getting ICE80 validation errors something like below... This package contains 64 bit component 'Component64File' but the Template Summary Property does not contain Intel64 or x64. If I provide the Package/@Platform as 'x64', this ICE validation error goes away, but, my setup doesn't install on 32 bit systems. I have seen MSIs doing similar stuff without this ICE validation error. No idea on how they are doing it. Is there any way I can do this i.e. make the MSI work on both 64 bit and 32 bit systems but, without this ICE validation error? Please suggest... Thanking You, With Regards, // Sudripta Nandy -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deferred Custom Action
Since writing registry keys is something that is built into Windows Installer, I would recommend using semi-custom actions if you have to compute the registry keys/values at install time. See Bob Arnson's blog: http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ That allows Windows Installer to deal with install, removal, rollback, etc. -Original Message- From: nandini sa [mailto:nandini...@gmail.com] Sent: Tuesday, December 08, 2009 5:03 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Deferred Custom Action Hi, I have a custom action that makes a registry entry both during install and uninstall. The custom action is deferred and thus I use another custom action to set the custom action data. This works well in both scenarios (install and uninstall). However if UAC is turned on, then the uninstall custom action fails. The custom action called during install works correctly. The uninstall custom action is called but the problem I figured is that the office version passed as Custom Action data is not getting set. I fail to understand as to why it is not getting set during uninstall since, during install (when UAC is on) the property gets set. What change should I make to my custom action called during uninstall in UAC mode so that the custom action data is set? The install execute sequence is as follows: !-- Custom actions for registry entry -- CustomAction Id=RegistryEntries.Setup Property=RegistryEntries Value= OfficeVersion=[OfficeVersion] / CustomAction Id=RegistryEntries BinaryKey=VSTOCustomAction DllEntry= RegisterAddin Execute=deferred Impersonate=no / CustomAction Id=RegistryEntriesUninstall.Setup Property= RegistryEntriesUninstall Value=OfficeVersion=[OfficeVersion] / CustomAction Id=RegistryEntriesUninstall BinaryKey=VSTOCustomAction DllEntry=UnregisterAddin Execute=deferred Impersonate=no / !-- Sets the office version for registry entries -- CustomAction Id=SetOfficeVersion Property=OfficeVersion Value=12.0 Execute=immediate / InstallExecuteSequence Custom Action=SetOfficeVersion After=LaunchConditions![CDATA[some property evaluated in launch condition]]/Custom !-- Registry entry while installing -- Custom Action=RegistryEntries.Setup After=InstallFiles1/Custom Custom Action=RegistryEntries After=RegistryEntries.SetupNOT Installed /Custom !--Registry entry while removing -- Custom Action=RegistryEntriesUninstall.Setup After=InstallFiles1/ Custom Custom Action=RegistryEntriesUninstall After= RegistryEntriesUninstall.SetupInstalled and Remove/Custom /InstallExecuteSequence Thanks in advance, Nandini -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File table won't get transformed
Unlike the Binary table and some others that contain the binaries themselves, the File table doesn't actually contain the files it describes: it points to them in the CAB(s) which are themselves described in the Media table. Both the English and the Japanese files need to be in the File table separately, and you need to install just the ones you want in each original view. The transform would then switch the view from installing the English files to the Japanese ones. -Original Message- From: Andy2k8 [mailto:appr...@gmail.com] Sent: Tuesday, December 08, 2009 12:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] File table won't get transformed I have an English and a Japanese MSI After creating a japanese transform using msitran and embedding using msidb. i see that the japanese resource files are not embedded in the file table when i opened the MSI using orca ( OR transform will not contain the resource files??) As a result, when the installation tries to refer to the japanese resources, it fails throwing a message tht the file0_japanese cannot be found in the resource.cab which is an embedded cab file. How do i modify file table using the transform?? any ideas?? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/File-table-won-t-get-transformed-tp4131192p4131192.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quiet Execution Custom Action - run a temporary executable
You would need code (in a custom action, most likely) that would extract the EXE from the Binary table so that you could execute it. -Original Message- From: Vladimir Iahnenco [mailto:vladimir.iahne...@gmail.com] Sent: Monday, December 07, 2009 6:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Quiet Execution Custom Action - run a temporary executable Hi All, I have an executable which has to be launched as a custom action. It is a temporary one, I have to run and delete it after that. When I add it as a Binary and Custom action it works. Binary Id=SetConfigExe SourceFile=$(var.SetConfig.TargetDir)SetConfig.exe / CustomAction Id=RunSetConfig PAR1=[SOMEPAR1] / Now I want to execute it silently, I added an action to set RunSetConfig property and another CAQuietExec custom action to execute. CustomAction Id=RunSetConfig BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/ From the log file I see that exe name and parameters are assigned properly but with no path to the exe and installer seems cannot find that exe. Any way to point the action on a binary? I don't want to include that exe as a component. Thanks, Vladimir -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File table won't get transformed
Thanks for that info. So if i add the japanese resources also to the file table it should work fine? Or should i create a separate feature that refers to the japanese resources and add a feature installation condition that check for the japanese locale? Blair-2 wrote: Unlike the Binary table and some others that contain the binaries themselves, the File table doesn't actually contain the files it describes: it points to them in the CAB(s) which are themselves described in the Media table. Both the English and the Japanese files need to be in the File table separately, and you need to install just the ones you want in each original view. The transform would then switch the view from installing the English files to the Japanese ones. -Original Message- From: Andy2k8 [mailto:appr...@gmail.com] Sent: Tuesday, December 08, 2009 12:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] File table won't get transformed I have an English and a Japanese MSI After creating a japanese transform using msitran and embedding using msidb. i see that the japanese resource files are not embedded in the file table when i opened the MSI using orca ( OR transform will not contain the resource files??) As a result, when the installation tries to refer to the japanese resources, it fails throwing a message tht the file0_japanese cannot be found in the resource.cab which is an embedded cab file. How do i modify file table using the transform?? any ideas?? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/File-table-won-t-get-transformed-tp4131192p4131192.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/File-table-won-t-get-transformed-tp4131192p4137939.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
