[WiX-users] Не пропустите!
САМЫЕ ЯРКИЕ СОБЫТИЯ СЦЕНЫ ТРУДНЫЕ ЛЮДИ - 19.05 ...Современник, Л. АХЕДЖАКОВА, В. ГАФТ, И. КВАША, А. ЛЕОНТЬЕВ ... история о несостоявшемся сватовстве в еврейском семействе, очень похожая на анекдот, незаметно превращается в лирическую комедию. ЕВГЕНИЙ МИРОНОВ в гл. роли - ФИГАРО - 21 ИЮНЯ ЮНОНА И АВОСЬ (Ленком, Д.ПЕВЦОВ, А.БОЛЬШОВА) - 12, 17, 29.05 ЖЕНИТЬБА (Ленком, И. ЧУРИКОВА, О. ЯНКОВСКИЙ, Л.БРОНЕВОЙ, А. ЗАХАРОВА.) - 23, 24.05 И 13, 14, 28, 29.06 1900-Й - ОЛЕГ МЕНЬШИКОВ - В ПРЕМЬЕРЕ СЕЗОНА! 15.05 И 16.05 LADIES NIGHT. Мужская комедия для женщин - 19.05 и 9, 16, 23.06 - В. ЯРЕМЕНКО, Г. КУЦЕНКО, М. БАШАРОВ, Э. КЮРДЗИДИС ПИГМАЛИОН (Современник, В.ГАФТ, С.МАКОВЕЦКИЙ) - 27.05 СПАРТАК (БОЛЬШОЙ ТЕАТР) - 15.05 ВА-БАНК (Ленком, А.ЗБРУЕВ, А.ЗАХАРОВА, Д.ПЕВЦОВ) -13, 15.05 БЕСПРИДАННИЦА (Театр Мастерская П.ФОМЕНКО, ПРЕМЬЕРА!) -17,29.05 И 6,18,24,29.06 ПРИМАДОННЫ #8211; 22, 23.05 И 6, 15, 26.06 СУПЕРКОМЕДИЯ, МХАТ им. Чехова ГОЛАЯ ПИОНЕРКА (Современик, Ч. ХОМАТОВА в гл. роли ) - 21,25,26 мая TOUT PAYE, ИЛИ ВСЕ ОПЛАЧЕНО (Ленком, О. ЯНКОВСКИЙ, И. ЧУРИКОВА, А. ЗБРУЕВ ) #8211; 25, 31 мая и 9, 10, 20, 21.06 БОЛЬШОЙ ТЕАТР (ЛЕГЕНДА О ЛЮБВИ-17,18.05, ЗОЛОТОЙ ВЕК-24,25.05 ) ДЖО КОКЕР - 17 МАЯ УЖИН С ДУРАКОМ (Г. ХАЗАНОВ, О. БАСИЛАШВИЛИ) #8211; 24 ИЮНЯ 2 2 9 3 5 0 0 доставка билетов - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] more problems with wix
I have a situation where we are serving msi files via a website link….what ends up happening is that if I choose to run the file directly without saving it locally it does install the product but if I do another run without saving and hit the repair button it fails with a network error saying it cannot read the installer file….is this a wix problem or a problem related to temporary internet files on a windows machine??? Any ideas??? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting INSTALLLOCATION to [WindowsVolume]
I currently have the following (default) directory setup: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=WixProject1 This offers (via the UI) the default installation directory C:\Program Files\WixProject1\ How can I get the default to be the windows volume (e.g. C:\)? Leaving it blank produces the root volume, which is picking up a USB external drive. - Sent from Yahoo! Mail. A Smarter Email.- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] more problems with wix
It's likely to be the temporary internet folder. That's one of the reasons for the setup.exe/msistuff.exe internet download bootstrapper. http://msdn.microsoft.com/en-us/library/aa369557.aspx Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kunal desai Sent: Monday, May 12, 2008 5:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] more problems with wix I have a situation where we are serving msi files via a website linkwhat ends up happening is that if I choose to run the file directly without saving it locally it does install the product but if I do another run without saving and hit the repair button it fails with a network error saying it cannot read the installer fileis this a wix problem or a problem related to temporary internet files on a windows machine??? Any ideas??? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Referencing a file in dependency merge module.
Hi, I am using WiX v3.0.4102.0 now. I am having problem to reference a file in a merge module (say ModuleA) from another merge module. (say ModuleB). I am referencing the file in ModuleA from a custom action of ModuleB. The problem is that when actual merge module is generated, the name is modularized to include ModuleB's ID. CustomAction Id='ModifyAppConfig.SetProperty' Property='ModifyAppConfig' Value='[#MyService.exe.config.87654321_4321_4321_4321_210987654321]'/ So [#MyService.exe.config.87654321_4321_4321_4321_210987654321] becomes something like below in the actual merge module. [#MyService.exe.config.87654321_4321_4321_4321_210987654321.403D71D6_50FA_40D2_8FB7_E33B0A9BCC5C] Is there any way to let WiX know that it shouldn't modularize this file reference? Thanks, Sunghwa - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Срочное изготовление сальни ков
Уважаемые господа! Предлагаем Вам услугу по срочному изготовлению резинотехнических изделий. Производим любые виды РТИ - Манжеты (вортниковые, шевронные) - Сальники (любые размеры на заказ 2-3 дня, любые размеры (от 6 до 5000мм диам) - Ремни клиновые, плоские, вариаторные (любой размер на заказ. Аналоги GATES, OPTIBELT по цене Российских) - Профили (профили любых сечений на заказ в срок от 2 недель. Дешево делаем большие размеры сечений) - Любые нестандартные изделия на заказ в срок от 1 недели. С Уважением, ООО Аскон Техно 8 (495) 72 5O 452 Просим прощения если наше письмо причинило Вам неудобство.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Hi Chris I can only second your opinion. It's almost unbelievable, how difficult even the most common, primitive task is. One has this long-honed professional developer instinct that constantly tells you there must be an easier way, I just have to find it. Believe me: in case of MSI there is none! Stop wasting your time searching for any sign of logic, design or even common sense. And it took me a while to realize, that WiX is only a wrapper. No abstraction whatsoever. So dont't blame WiX, except maybe for not making the thin wrapper catch clear from the beginning. It helps to cross the custom action / custom dialog barrier. Don't even try without, even if you think your application is plain vanilla! There has to be an awful lot of (pre-)historical bagagge that crippels MSIs design (to insult that word). I guess its a cross-breed between declarative and imperative princibles terribly gone wrong and awfully neglected since. Survival guide: 0. switch off your expectations 1. learn how to write custom actions and use them liberally 2. learn how to write custom dialogs and use them liberally 3. forget minor and small updates - use major upgrades only 4. realize that they only really thought of files and registry entries! Shortcuts, .ini-file entries, in some cases even directories, etc. were seemingly tacked on later and are terribly crippled because they have to somehow piggy back either on a file, directory or registry key; use the ugly hacks in the internet and don't waste your time searching for elegance 5. realize the power of properties set through custom actions 6. realize the power of conditions (often you can't dynamically change even the simplest things, like i.e. the name of a shortcut. But you can switch OFF one component and switch ON another - sometimes that helps) 6. isolate everything in your application that remains absolutely static once it's deployed 7. then only(!) setup that static part with MSI/WiX 8. setup everything else (such as initial configuration, initial databases, etc.) either with a custom action or with your application (first run) 9. expect problems - this technology (to insult that word too) is gagging for trial and error (and shot deadlines) Hope that helps a bit. -Mark _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Mumford Gesendet: Montag, 12. Mai 2008 06:13 An: wix-users@lists.sourceforge.net Betreff: [WiX-users] yep - back to being 100% frustrated Man: I can't believe how much making Windows Installer based installs suck - I mean really sucks! Did we just invent this technology to make us hate our lives? And WiX doesn't make it any easier. I'm calling it a night. Peace out man... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
In article [EMAIL PROTECTED], Markus Kuehni [EMAIL PROTECTED] writes: 1. learn how to write custom actions and use them liberally Disagree 2. learn how to write custom dialogs and use them liberally Use custom dialogs only when needed; most projects don't need them. 3. forget minor and small updates - use major upgrades only Disagree 4. realize that they only really thought of files and registry entries! Disagree 5. realize the power of properties set through custom actions For Type 51 (set a property) CAs, Agree. 6. realize the power of conditions [...] Agree 6. isolate everything in your application that remains absolutely static once it's deployed I'm not sure what this is even talking about. 7. then only(!) setup that static part with MSI/WiX Disagree, if this is talking about files and not items in 8. If only talking about items in 8, then Agree. 8. setup everything else (such as initial configuration, initial databases, etc.) either with a custom action or with your application (first run) Agree 9. expect problems - this technology (to insult that word too) is gagging for trial and error (and shot deadlines) Disagree. Like anything else, it helps if you read the documentation. I've had a summer intern do just with with a relatively complex MSI installation (and this was with MSI 1.2) just by taking the time to read documentation and understand what it says before flailing about in a non-productive fashion and then declaring frustration. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstalling a Feature where the Level condition has changed since installation
Our product contains a feature to integrate with Lotus Notes. The feature's Level is set to 0 (so that it is not selectable), and conditionally set to 1 if Lotus Notes is installed. If later, Notes is uninstalled, then our product won't uninstall the Notes integration feature, leaving files in the Notes install folder and the product entry in the ARP. This must be the wrong approach as it is certainly not the desired behavior. Is there a better way? Or am I once again missing an important detail? John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using wixlibs or msm's to speed build process?
It is unlikely that the compiling/linking is taking a lot of time. .wixlibs may help some but if the majority of your time is spent moving files around you won't see a big win there. It is easy to use .wixlibs, just use lit.exe on a bunch of .wixobjs then add the .wixlib on the command-line to light.exe instead of all the .wixobjs. Merge Modules will only make the file processing slower because files are compressed into the Merge Module during Merge Module creation. Then when used in an MSI the files are extracted from the Merge Module and laid out (often compressed) into the MSI image. I think the feature you really are looking for is the cabinet cache, assuming your files are compressed. The cabinet cache works by creating the cabinet once then re-using the cabinet in multiple MSIs. It's kinda' like incremental linking. Check out the switches on light.exe for how to define where the cabinet cache should be. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy Sent: Friday, May 09, 2008 12:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using wixlibs or msm's to speed build process? We have some installers that take a while to build, and we're currently doing a lot of releases that don't change a large portion of the files in the installer (much of the installer is 'content' rather than 'system' files). Can anybody point me at a reference for how to use wixlibs or msm's to incrementally build our installer (i.e. build a wixlib or a msm for the content that just gets merged (hopefully quickly) into the output msi)? Is this likely to improve things, or is it more likely that this will take just as long to build as the other process? Thanks, Kelly Leahy ** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless otherwise noted in this email or its attachments, this communication does not form a Statement of Actuarial Opinion under American Academy of Actuaries guidelines. ** - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installshield decompiling
Is a bug open on this issue? I try to keep up with what is going on in the internet but we tend to focus our fixes on bugs that open in the bug database for WiX on SourceForge. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jody Belka (WCS) Sent: Sunday, May 11, 2008 15:21 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installshield decompiling I just tried to decompile an msi we produced using Installshield, and hit the bug mentioned here: http://skizz.biz/blog/2007/11/22/wix-bug-fix-for-importing-installshield-project-with-dark/ I was wondering if a fix for this will be making it into WiX sometime soon? Or if there's any way around it other than building my own copy of Dark? J -- Jody Belka knew (at) pimb (dot) org - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Не пропустите!
САМЫЕ ЯРКИЕ СОБЫТИЯ СЦЕНЫ ТРУДНЫЕ ЛЮДИ - 19.05 ...Современник, Л. АХЕДЖАКОВА, В. ГАФТ, И. КВАША, А. ЛЕОНТЬЕВ ... история о несостоявшемся сватовстве в еврейском семействе, очень похожая на анекдот, незаметно превращается в лирическую комедию. ЕВГЕНИЙ МИРОНОВ в гл. роли - ФИГАРО - 21 ИЮНЯ ЮНОНА И АВОСЬ (Ленком, Д.ПЕВЦОВ, А.БОЛЬШОВА) - 12, 17, 29.05 ЖЕНИТЬБА (Ленком, И. ЧУРИКОВА, О. ЯНКОВСКИЙ, Л.БРОНЕВОЙ, А. ЗАХАРОВА.) - 23, 24.05 И 13, 14, 28, 29.06 1900-Й - ОЛЕГ МЕНЬШИКОВ - В ПРЕМЬЕРЕ СЕЗОНА! 15.05 И 16.05 LADIES NIGHT. Мужская комедия для женщин - 19.05 и 9, 16, 23.06 - В. ЯРЕМЕНКО, Г. КУЦЕНКО, М. БАШАРОВ, Э. КЮРДЗИДИС ПИГМАЛИОН (Современник, В.ГАФТ, С.МАКОВЕЦКИЙ) - 27.05 СПАРТАК (БОЛЬШОЙ ТЕАТР) - 15.05 ВА-БАНК (Ленком, А.ЗБРУЕВ, А.ЗАХАРОВА, Д.ПЕВЦОВ) -13, 15.05 БЕСПРИДАННИЦА (Театр Мастерская П.ФОМЕНКО, ПРЕМЬЕРА!) -17,29.05 И 6,18,24,29.06 ПРИМАДОННЫ - 22, 23.05 И 6, 15, 26.06 СУПЕРКОМЕДИЯ, МХАТ им. Чехова ГОЛАЯ ПИОНЕРКА (Современик, Ч. ХАМАТОВА в гл. роли ) - 21,25,26 мая TOUT PAYE, ИЛИ ВСЕ ОПЛАЧЕНО (Ленком, О. ЯНКОВСКИЙ, И. ЧУРИКОВА, А. ЗБРУЕВ ) - 25, 31 мая и 9, 10, 20, 21.06 БОЛЬШОЙ ТЕАТР (ЛЕГЕНДА О ЛЮБВИ-17,18.05, ЗОЛОТОЙ ВЕК-24,25.05 ) ДЖО КОКЕР - 17 МАЯ УЖИН С ДУРАКОМ (Г. ХАЗАНОВ, О. БАСИЛАШВИЛИ) - 24 ИЮНЯ 22935OO доставка билетов - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Definitely interesting commentary. I'd have to say that I agree with Richard and mostly disagree with Markus' comment - although I see where he's coming from. My guess is that his rules are mostly born from experience and he's chosen the most pragmatic approach that seems likely to work. It's my understanding that nearly all custom actions are improperly written and I really want to try to create an installation with zero CA's if possible. I'm sure that when I get to some crazy things like deleting files and registry values (that no installer would ever want to do sarcasm /) I'll have to write a CA. I did my first MSI somewhere around 8-9 years ago and have used most of the major installer tools from Wise, InstallShield, WiX, and MakeMSI. It's been a good five years since I've wrestled with Windows Installer - staying away for obvious reasons. So now I'm rewriting one of my installations (which has always had issues) and I'm going to try to do it right with WiX. So I get it to install a few files in the right folder, and my very next step is to create a simple stupid shortcut - and it doesn't work with an ICE48 error. Searching around didn't really turn up much, but there was a Google hit on Rob's site - which was down - G. Call me old fashioned but I think that any solution should make it easy to do what 80% of the users want. Maybe this is a bad example but who cares a flip about advertised features. I don't see this as a feature at all. It just complicates our lives as installer writers and it complicates the lives of the end user too. Sure this isn't a WiX thing - it's a *feature* of Windows Installer, but man I wish WiX made things easier for us - and it could. Well anyhow, I've gotta get back to my day gig now. Thanks for your thoughts. BTW stay in touch Siva - I may be begging you forward my resume for that security guard gig after a few more weeks of playing with this tech. ;-) Cheers. On Mon, May 12, 2008 at 11:53 AM, Markus Kuehni [EMAIL PROTECTED] wrote: Hi Chris I can only second your opinion. It's almost unbelievable, how difficult even the most common, primitive task is. One has this long-honed professional developer instinct that constantly tells you there must be an easier way, I just have to find it. Believe me: in case of MSI there is none! Stop wasting your time searching for any sign of logic, design or even common sense. And it took me a while to realize, that WiX is only a wrapper. No abstraction whatsoever. So dont't blame WiX, except maybe for not making the thin wrapper catch clear from the beginning. It helps to cross the custom action / custom dialog barrier. Don't even try without, even if you think your application is plain vanilla! There has to be an awful lot of (pre-)historical bagagge that crippels MSIs design (to insult that word). I guess its a cross-breed between declarative and imperative princibles terribly gone wrong and awfully neglected since. Survival guide: 0. switch off your expectations 1. learn how to write custom actions and use them liberally 2. learn how to write custom dialogs and use them liberally 3. forget minor and small updates - use major upgrades only 4. realize that they only really thought of files and registry entries! Shortcuts, .ini-file entries, in some cases even directories, etc. were seemingly tacked on later and are terribly crippled because they have to somehow piggy back either on a file, directory or registry key; use the ugly hacks in the internet and don't waste your time searching for elegance 5. realize the power of properties set through custom actions 6. realize the power of conditions (often you can't dynamically change even the simplest things, like i.e. the name of a shortcut. But you can switch OFF one component and switch ON another - sometimes that helps) 6. isolate everything in your application that remains absolutely static once it's deployed 7. then only(!) setup that static part with MSI/WiX 8. setup everything else (such as initial configuration, initial databases, etc.) either with a custom action or with your application (first run) 9. expect problems - this technology (to insult that word too) is gagging for trial and error (and shot deadlines) Hope that helps a bit. -Mark -- *Von:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *Im Auftrag von *Chris Mumford *Gesendet:* Montag, 12. Mai 2008 06:13 *An:* wix-users@lists.sourceforge.net *Betreff:* [WiX-users] yep - back to being 100% frustrated Man: I can't believe how much making Windows Installer based installs suck - I mean really sucks! Did we just invent this technology to make us hate our lives? And WiX doesn't make it any easier. I'm calling it a night. Peace out man... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
Re: [WiX-users] yep - back to being 100% frustrated
Richard Like anything else, it helps if you read the documentation. I've just done that. Read what scarce documentation is available about WiX. Read the dusty tramontana tutorial cover to cover before I started. Maybe its my mistake, but it took me a long time to realize that WiX is just a wrapper and that it in no way aspires to abstract from MSI. That indeed it assumes you know all about MSI to succeed in the first place. In hindsight it's clear as water but that's now. On the WiX site it says: The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code when it should say something like The Windows Installer XML (WiX) is a toolset built around a human readable, easily machine generatable XML representation of the otherwise unaltered relational structure of Windows Installer packages Now, it's true that by the time I realized this, I was knee deep into my installer generator and learned many things the hard way, desperately scratching together morsels of information from bad, outdated and incomplete documentation bits, desperado blogs and mailing lists. Just consider the pain level in this mailing list as evidence of that! I should have stopped and bought me a Windows Installer Book. Maybe. However, I (kind of) succeeded in the end. So this is NOT a non-productive frustration rant like you suggested. Its more a glance back over my shoulder, still shaking my head in disbelief. My critisism does not come from the frustration of being stuck. It does come from realization, once it was solved, how complicated even the simplest task was! Just some of the snags I encountered (if I'm talking about custom action, I mean self-made): - minor updates/small updates can't be administered by double clicking the .msi; this bug was not fixed since at least 2004 (I think) - adding a bootstrapper to fix this, IMHO breaks the rule of self-containedness - non-advertised shortcuts need to piggy back on a dummy per user(!) registry entry just to pass ICEs; incredibly, even with per machine installations! - advertised shortcuts bloat the .msi if you use external .cabs - advertised shortcut with same binary but different command-line argument did not work (didn't really try to confirm or resolve that, because I switched to non-advertised) - shortcuts can't have dynamic names (set by property) - shortcut folders need to be explicitely removed on uninstall while file directories need not (why?) - ini file entries must be piggy backed to the containing directory component (no, I can't use the registry: it's not network transparent) - IniFileSearch does only work in the Windows folder! - FileSearch produces parent folder when @Id not set: documentation wrong and/or does not work; bad hack work-around required - features without components (empty or all conditioned false) behave eradically (don't know if that's WiX_UI's or MSI's fault) - features can't be declared mutually exclusive (basic requirement IMHO) - because of the last two shortcomings: you can't use the feature tree to configure simple additional setup options; custom dialogs are required - there is no warning-OK|cancel action built in (just error-cancel); again: custom dialog required for the simplest thing - incredibly there ist not even a properties expression syntax: anything more complex than concatenating properties together and some text, does require a custom action - condition expressions is limited to ~200 odd characters, again requiring custom actions to set dedicated condition properties (condition expressions tend to become huge as there is no else if-chaining possible) - component update rules (confusingly named REINSTALLMODE, although active on initial install) are global, not per component - component update rules operate on momentary assumptions, not taking RemoveExistingProducts into consideration, thus leaving some files uninstalled(!) if you choose the wrong (but documented as valid!) sequence; (incredible, considering the huge database driven overhead behind the scene - what is it for, then?) - this one took me ages to believe: MSI does not support setting up the initial version of files (like databases or configuration files) that are thereafter modified by the application and should be left alone both on repair AND on major upgrade (I managed to get one or the other working but not both); one needs to copy/write those files using a custom action (like I said: deploy static stuff only!) - internationalization? don't ask; incredible considering it's just looking up strings (no, our product does not need a language code; it's multilingual); many bugs in WiX there too - the overall confusion, the misinformation about component GUIDs is amazing! in complete violation of the zero overhead rule, ALL components of an installation suffer the full blast from the complexities of the oddest shared component scenario! (our app has no shared components) - auto-generating WiX files and
Re: [WiX-users] yep - back to being 100% frustrated
In article [EMAIL PROTECTED], Chris Mumford [EMAIL PROTECTED] writes: So now I'm rewriting one of my installations (which has always had issues) and I'm going to try to do it right with WiX. So I get it to install a few files in the right folder, and my very next step is to create a simple stupid shortcut - and it doesn't work with an ICE48 error. Searching around didn't really turn up much, but there was a Google hit on Rob's site - which was down - G. Creating plain shortcuts is rather straightforward, but for some reason its something that people seem to get hung up on relatively often. From the MSI documentation for the Shortcut table: Target The shortcut target. [...] For a non-advertised shortcut, the installer evaluates this field as a Formatted string. The field should contains a property identifier enclosed by square brackets ([ ]), that is expanded into the file or a folder pointed to by the shortcut. For more information, see the CreateShortcuts action. If you're getting an ICE48 error (ICE48 checks for directories that are hard-coded to local paths in the Property table.), then that doesn't have anything to do with shortcuts. In your Target column of your shortcut, you should be using the properties associated with directories as you've defined them in rows of the Directory table. If you're trying to create shortcuts to items in folders you didn't create, then use AppSearch to set the directory property. That WiX isn't an abstraction that raises you above having to understand the MSI table schema is a valid observation. I don't know if its a valid criticism of WiX as having an abstraction that raises you above the schema wasn't a design goal of WiX. You might as well criticize WiX because it doesn't solve world hunger. My aversion to CA's is that for some reason people immediately rush to create a CA when most of the time the standard actions already do what they want. Then there's the stupid VS.NET documentation that tells people to write CA's to get around the limitations of their authoring tool and not Windows Installer... Yet, CAs are there for a reason and sometimes you need them. But getting all the error handling working properly in a CA isn't easy and most of the bugs that I've fixed in complex installs revolved around CAs that failed in some peculiar way and didn't handle the failure properly. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] deleting old files
Use RemoveFile /. Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kunal Desai Sent: Monday, May 12, 2008 4:08 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] deleting old files 1) I create an installer based on the files in a particular folder 2) I delete a file from the folder 3) I compile another installer that doesn't have the deleted file my problem is that the file is still there on the install location and needs to be deleted by the new installerhow do I do this - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Removing old files
I'm developing a IE extension. After releasing a new version, a user tries to upgrade on the website. That means the IE browser is open and the old files are being used when the installer tries to remove the old version. The weird thing is that the installer makes some error but really removing the old files without closing running browsers and putting new files in it, even though those old files are open. Anyway it worked. - upgrading without closing IE browsers. So I want to suppress the modal dialog showing an error 8203 or something... Is it possible? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
1. Yes, WiX is a relatively thin layer above MSI. Some people liken it to assembly but I still think C/C++ is more appropriate. The only thing that makes C++ reasonable is a wide range of libraries to help do some heavy lifting (like file IO (libc, kernel32) or drawing pixels on the screen (gdi32)). We're still building up those layers. 2. I basically agree with all of the issues raised below. I don't see anything new in that list of pain points with the Windows Installer. 3. However, the real question is how would you fix them in a way that always works? So far we have been very cautious about automagically fixing things since there are a lot of different valid ways to solve the same problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Kuehni Sent: Monday, May 12, 2008 15:02 To: 'Richard'; 'WiX Users' Subject: Re: [WiX-users] yep - back to being 100% frustrated Richard Like anything else, it helps if you read the documentation. I've just done that. Read what scarce documentation is available about WiX. Read the dusty tramontana tutorial cover to cover before I started. Maybe its my mistake, but it took me a long time to realize that WiX is just a wrapper and that it in no way aspires to abstract from MSI. That indeed it assumes you know all about MSI to succeed in the first place. In hindsight it's clear as water but that's now. On the WiX site it says: The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code when it should say something like The Windows Installer XML (WiX) is a toolset built around a human readable, easily machine generatable XML representation of the otherwise unaltered relational structure of Windows Installer packages Now, it's true that by the time I realized this, I was knee deep into my installer generator and learned many things the hard way, desperately scratching together morsels of information from bad, outdated and incomplete documentation bits, desperado blogs and mailing lists. Just consider the pain level in this mailing list as evidence of that! I should have stopped and bought me a Windows Installer Book. Maybe. However, I (kind of) succeeded in the end. So this is NOT a non-productive frustration rant like you suggested. Its more a glance back over my shoulder, still shaking my head in disbelief. My critisism does not come from the frustration of being stuck. It does come from realization, once it was solved, how complicated even the simplest task was! Just some of the snags I encountered (if I'm talking about custom action, I mean self-made): - minor updates/small updates can't be administered by double clicking the .msi; this bug was not fixed since at least 2004 (I think) - adding a bootstrapper to fix this, IMHO breaks the rule of self-containedness - non-advertised shortcuts need to piggy back on a dummy per user(!) registry entry just to pass ICEs; incredibly, even with per machine installations! - advertised shortcuts bloat the .msi if you use external .cabs - advertised shortcut with same binary but different command-line argument did not work (didn't really try to confirm or resolve that, because I switched to non-advertised) - shortcuts can't have dynamic names (set by property) - shortcut folders need to be explicitely removed on uninstall while file directories need not (why?) - ini file entries must be piggy backed to the containing directory component (no, I can't use the registry: it's not network transparent) - IniFileSearch does only work in the Windows folder! - FileSearch produces parent folder when @Id not set: documentation wrong and/or does not work; bad hack work-around required - features without components (empty or all conditioned false) behave eradically (don't know if that's WiX_UI's or MSI's fault) - features can't be declared mutually exclusive (basic requirement IMHO) - because of the last two shortcomings: you can't use the feature tree to configure simple additional setup options; custom dialogs are required - there is no warning-OK|cancel action built in (just error-cancel); again: custom dialog required for the simplest thing - incredibly there ist not even a properties expression syntax: anything more complex than concatenating properties together and some text, does require a custom action - condition expressions is limited to ~200 odd characters, again requiring custom actions to set dedicated condition properties (condition expressions tend to become huge as there is no else if-chaining possible) - component update rules (confusingly named REINSTALLMODE, although active on initial install) are global, not per component - component update rules operate on momentary assumptions, not taking RemoveExistingProducts into consideration, thus leaving some files uninstalled(!) if you choose the wrong (but documented as valid!) sequence; (incredible, considering the huge database driven overhead
Re: [WiX-users] Custom Actions
Are you doing an admin install? If not, you'll want the action in the InstallExecuteSequence. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harini Gurusamy Sent: Monday, May 12, 2008 18:48 To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom Actions I am trying to execute a custom action during install as below. But the exe never gets executed. Any pointers ?? CustomAction Id=LaunchFile FileKey=catsign.exe ExeCommand=Add Execute=deferred/ AdminExecuteSequence Custom Action='LaunchFile' After='InstallFiles'NOT Installed/Custom /AdminExecuteSequence Attaching the log file Thanks, Harini - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] LGHT0001 : Unknown error while getting hash of file
Any suggestions please as to what to look for to cure this error (in a WiX setup that I'm taking over from someone else)? We're using the final/stable WiX 2.0.5805. c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Release/thecoapp.msi Release/oe.wixobj Release/ocommon.wixobj Release/oCore.wixobj Release/oService.wixobj Release/DNE.wixobj Release/OPlugin.wixobj Release/OCA.wixobj Release/oGui.wixobj c:\PROGRA~1\WI577F~1\bin\wixui.wixlib -loc c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl light.exe : error LGHT0001 : Unknown error while getting hash of file: f:\theco\wix\License.rtf, system error: 5 Exception Type: System.ApplicationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileHash(String filePath, Int32 options, Int32[] hash) at Microsoft.Tools.WindowsInstallerXml.Binder.UpdateFileInformation(Output output) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) make: *** [Release/thecoapp.msi] Error 1 The license file does exist: dir f:\theco\wix\License.rtf Volume in drive F is Data Volume Serial Number is CCBD-19CF Directory of f:\theco\wix 05/12/2008 06:52 PM 6,406 License.rtf 1 File(s) 6,406 bytes 0 Dir(s) 26,728,669,184 bytes free thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0001 : Unknown error while getting hash of file
System Error 5 == ERROR_ACCESS_DENIED. Something is probably locking the file, preventing the WiX toolset from calculating the hash. Definitely could have a better error message (I *think* there is one in WiX v3). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair Sent: Monday, May 12, 2008 19:05 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT0001 : Unknown error while getting hash of file Any suggestions please as to what to look for to cure this error (in a WiX setup that I'm taking over from someone else)? We're using the final/stable WiX 2.0.5805. c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Release/thecoapp.msi Release/oe.wixobj Release/ocommon.wixobj Release/oCore.wixobj Release/oService.wixobj Release/DNE.wixobj Release/OPlugin.wixobj Release/OCA.wixobj Release/oGui.wixobj c:\PROGRA~1\WI577F~1\bin\wixui.wixlib -loc c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl light.exe : error LGHT0001 : Unknown error while getting hash of file: f:\theco\wix\License.rtf, system error: 5 Exception Type: System.ApplicationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileHash(String filePath, Int32 options, Int32[] hash) at Microsoft.Tools.WindowsInstallerXml.Binder.UpdateFileInformation(Output output) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) make: *** [Release/thecoapp.msi] Error 1 The license file does exist: dir f:\theco\wix\License.rtf Volume in drive F is Data Volume Serial Number is CCBD-19CF Directory of f:\theco\wix 05/12/2008 06:52 PM 6,406 License.rtf 1 File(s) 6,406 bytes 0 Dir(s) 26,728,669,184 bytes free thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0001 : Unknown error while getting hash of file
many thanks ... it was indeed locked (at least, ls -l says -- 1 alan None 6406 May 12 18:52 License.rtf, and chmod 777 ... fixed the problem) Rob Mensching wrote: System Error 5 == ERROR_ACCESS_DENIED. Something is probably locking the file, preventing the WiX toolset from calculating the hash. Definitely could have a better error message (I *think* there is one in WiX v3). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair Sent: Monday, May 12, 2008 19:05 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT0001 : Unknown error while getting hash of file Any suggestions please as to what to look for to cure this error (in a WiX setup that I'm taking over from someone else)? We're using the final/stable WiX 2.0.5805. c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Release/thecoapp.msi Release/oe.wixobj Release/ocommon.wixobj Release/oCore.wixobj Release/oService.wixobj Release/DNE.wixobj Release/OPlugin.wixobj Release/OCA.wixobj Release/oGui.wixobj c:\PROGRA~1\WI577F~1\bin\wixui.wixlib -loc c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl light.exe : error LGHT0001 : Unknown error while getting hash of file: f:\theco\wix\License.rtf, system error: 5 Exception Type: System.ApplicationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileHash(String filePath, Int32 options, Int32[] hash) at Microsoft.Tools.WindowsInstallerXml.Binder.UpdateFileInformation(Output output) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) make: *** [Release/thecoapp.msi] Error 1 The license file does exist: dir f:\theco\wix\License.rtf Volume in drive F is Data Volume Serial Number is CCBD-19CF Directory of f:\theco\wix 05/12/2008 06:52 PM 6,406 License.rtf 1 File(s) 6,406 bytes 0 Dir(s) 26,728,669,184 bytes free thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] VirtualDir within drectory of WebSite
Hi all. I work currently with a certain Microsoft CRM product and am attempting to create an installer that will do the following. Install all our web applications into configurable directory C:\Program Files\...\IIS ( Simple and done ) Create a Virtual Directory for each web app in [MSCRM Web Site]\ISV\blah\ Now, I am able to create the virtual directory's directly under [MSCRM Web Site], but this is not a particularly optimal solution as the recommended and supported location is /ISV. Reading pages like http://www.tramontana.co.hu/wix/lesson6.php#6.3 and the iis.xsd make me believe that iis:VirtualDir is only capable of installing into the root directory of the Website. Is this correct? Are there any other possible solutions. I believe that the only other one would involve installing everything directly into the C:\Program Files\...\...\ISV\ directory. I would prefer not to install anything within the MS CRM directory for fear and paranoia reasons. Alistair Bush Intermediate Developer Quadrant 2 Limited - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VirtualDir within drectory of WebSite
Just put the multiple vdirs in the Alias attribute. Virtual directories are virtual so they don't actually need a whole hierarchy to exist to create them. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alistair Bush Sent: Monday, May 12, 2008 21:35 To: wix-users@lists.sourceforge.net Subject: [WiX-users] VirtualDir within drectory of WebSite Hi all. I work currently with a certain Microsoft CRM product and am attempting to create an installer that will do the following. Install all our web applications into configurable directory C:\Program Files\...\IIS ( Simple and done ) Create a Virtual Directory for each web app in [MSCRM Web Site]\ISV\blah\ Now, I am able to create the virtual directory's directly under [MSCRM Web Site], but this is not a particularly optimal solution as the recommended and supported location is /ISV. Reading pages like http://www.tramontana.co.hu/wix/lesson6.php#6.3 and the iis.xsd make me believe that iis:VirtualDir is only capable of installing into the root directory of the Website. Is this correct? Are there any other possible solutions. I believe that the only other one would involve installing everything directly into the C:\Program Files\...\...\ISV\ directory. I would prefer not to install anything within the MS CRM directory for fear and paranoia reasons. Alistair Bush Intermediate Developer Quadrant 2 Limited - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
