[WiX-users] Лучшие постановки Москвы!
КОМЕДИИ, СПЕКТАКЛИ, КОНЦЕРТЫ билеты НА ЛУЧШИЕ МЕРОПРИЯТИЯ - 229 35 00 LADIES NIGHT. 9, 16.06 - В. ЯРЕМЕНКО, Г. КУЦЕНКО, М. БАШАРОВ, Э. КЮРДЗИДИС ДЕСЯТЬ ТЕНОРОВ, КОТОРЫЕ ПОТРЯСЛИ МИР- The Ten Tenors- ЗВЕЗДНЫЙ КОНЦЕРТ - 5, 6.06 БОЛЬШОЙ ТЕАТР-БАЛЕТЫ: ЗОЛОТОЙ ВЕК-24,25.05 ЛЕБЕДИНОЕ ОЗЕРО - 12.06, СВЕТЛЫЙ РУЧЕЙ-9.06, БАЯДЕРКА-13.06, РАЙМОНДА-14.06, ДОН КИХОТ-22.06, ЖИЗЕЛЬ-24.06 БЕСПРИДАННИЦА (Театр Мастерская П.ФОМЕНКО, ПРЕМЬЕРА) - 29.05 и 6, 18, 24, 29.06. Действие происходит в большом городе Бряхимове на Волге . В спектакле звучат: русские романсы,цыганские песни, незабываемые хиты. ОЧЕНЬ СТИЛЬНЫЙ, НАСТОЯЩИЙ ФОМЕНКОВСКИЙ СПЕКТАКЛЬ ПИГМАЛИОН (Современник, В. ГАФТ и С. МАКОВЕЦКИЙ) - 27.05 И 29, 30.06 ГОЛАЯ ПИОНЕРКА (Современник, Ч. ХАМАТОВА в гл. роли) - 21, 27.05 и 29.06 ЮНОНА И АВОСЬ (Д.ПЕВЦОВ, А.БОЛЬШОВА) #8211; 29.05 и 5, 11, 17, 27.06 ЗАЯЦ LOVE STORY (Современник,ПРЕМЬЕРА, В. ГАФТ,Н. ДОРОШИНА, смешная и трогательная история о встрече бывших супругов...) -16, 23.06 МОРКОВКА ДЛЯ ИМПЕРАТОРА (МАРИЯ АРОНОВА, Г. ХАЗАНОВ) #8211; 25.06...В этом спектакле есть все: и смех до упаду, и слезы, и нежность,и и любовь... Простолюдинка Жозефина (МАРИЯ АРОНОВА)пытается стрясти у Императора Наполеона (Г.ХАЗАНОВ) давнишний долг: он обещал своим солдатам приличное вознаграждение за каждого их сына, названного в его честь. У Жозефины - четыре сына: Наполеон-Франсуа, Наполеон-Жозеф, Наполеон-Бернар и Наполеон-Луи... ЛАРА ФАБИАН - КОНЦЕРТ - 28,29,30.05 -А ТАКЖЕ ВСЕ СПЕКТАКЛИ И КОНЦЕРТЫ СТОЛИЦЫ - ЗВОНИТЕ! - 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 UninstallString to uninstall multiple MSIs
That's great Bob, thanks. I'll look into it. - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Jason Rivers [EMAIL PROTECTED] Cc: WiX Users wix-users@lists.sourceforge.net Sent: Friday, May 16, 2008 5:05 PM Subject: Re: [WiX-users] Using UninstallString to uninstall multiple MSIs Jason Rivers wrote: How do I configure the system so that my setup.exe (which is a stub that can launch a number of MSIs) is run when the user chooses to uninstall my application? I've tried changing various UninstallString registry entries but nothing seems to have any effect. When Add/Remove Programs shows an entry for a product installed by MSI, it uses the MSI API to uninstall the product, not the UninstallString value. To invoke another setup.exe, you need to write the Uninstall key manually. See http://blogs.msdn.com/heaths/archive/tags/ARPSYSTEMCOMPONENT/default.aspx for a set of issues about doing so. -- sig://boB http://joyofsetup.com/ - 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] Vista UAC warning when setup runs
Hi, I've created a wix msi file which is then signed however when i run it under vista i get a strange UAC warning: Program needs your permission to continue which has the Manufacturer name as the msi is signed, but the program is listed as a random/temporary 5 digit name (eg 1cd5b.msi) Is it possible to get rid of this or at least put the correct msi name in? Also, which i think is a known bug, i get a similar error when the package is uninstalled, is it possible to remove this as well. Thanks -- Got needs? Get Goblin'! - http://www.pricegoblin.co.uk/ - 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] Modifying/creating a text file
I'd like to be able to modify a text file during the installation process. Basically I need to replace an existing string with one I'll only know at install time. The file is a batch file (i.e. not INI or XML). How could I go about this? - Sent from Yahoo! Mail. A Smarter Email.- 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] Vista UAC warning when setup runs
Hi John, The first problem with the random digits is due to you not adding the proper name when signing the package. My Votive is playing up right now so I can't see the post build event parameters for signing but I think it is the Description option when using signtool.exe. The second issue is because Windows Installer does some mangling of your MSI when it is installed so that the signature is no longer valid. There is not workaround for this apparently as MSI is only keeping the bits it cares about (I think) and throwing away the other stuff. All setup packages suffer from this problem. I know, it is kind of a bad thing when there is so much emphasis on trying to train users to not load untrusted files. Ryan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lister Sent: 20 May 2008 10:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Vista UAC warning when setup runs Hi, I've created a wix msi file which is then signed however when i run it under vista i get a strange UAC warning: Program needs your permission to continue which has the Manufacturer name as the msi is signed, but the program is listed as a random/temporary 5 digit name (eg 1cd5b.msi) Is it possible to get rid of this or at least put the correct msi name in? Also, which i think is a known bug, i get a similar error when the package is uninstalled, is it possible to remove this as well. Thanks -- Got needs? Get Goblin'! - http://www.pricegoblin.co.uk/ No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.21/1456 - Release Date: 20/05/2008 06:45 - 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] Повышение квалификации строите лей
Повышение квалификации строителей, май-июнь 2008 г., Москва. Подробности по телефону 749-67-29 Даты проведения, темы, стоимость (летние скидки!!!) 26-28.05Практика пожарно-технической безопасности при проектировании, строительстве зданий и сооружений (12663 руб.) 29-30.05Новое в формировании, регистрации и инвентаризации объектов недвижимости и связанных с этим имущественных отношений (12664 руб.) 2-4.06 Практика применения новой сметно-нормативной базы в строительстве (13420 руб.) 2-4.06 Новые эффективные решения систем отопления, вентиляции и кондиционирования воздуха (12823 руб.) 2-4.06 Новое в системах водоснабжения и канализации (нормативная база, проектирование, строительство и реконструкция с учетом требований экологии и ресурсосбережении) (12825 руб.) 5-6.06 Современные требования к деятельности отдела кадров на основе положений Трудового кодекса РФ с учетом последующих изменений и дополнений (12813 руб.) 5-6.06 Роль прораба, начальника участка в современном строительстве (12799 руб.) 9-10.06 Новое в инженерных изысканиях и геодезическом обеспечении строительной деятельности (13494 руб.) 9-10.06 Новое в правовых и экономических вопросах электроснабжения и подключения электрических сетей (12800 руб.) 9-10.06 Управление закупками и проведение конкурсов в строительстве для государственных, муниципальных нужд или свободных предпринимателей (13495 руб.) 16-18-06Практика составления смет на монтаж оборудования и пусконаладочные работы в соответствии с новой сметно-нормативной базой (13497 руб.) - 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] Функции службы заказчика строи тельства
Учебный центр, привлекая специалистов ОАО Центринвестпроекта, Центра экономики и ценообразования в строительстве, аудиторских фирм, приглашает Вас на семинар: ФУНКЦИИ СЛУЖБЫ ЗАКАЗЧИКА СТРОИТЕЛЬСТВА ПРИ РЕАЛИЗАЦИИ ИНВЕСТИЦИОННЫХ ПРОЕКТОВ (НОРМАТИВНЫЕ ДОКУМЕНТЫ, ПРАВОВЫЕ, ТЕХНИЧЕСКИЕ И ФИНАНСОВЫЕ АСПЕКТЫ) 28 - 30 мая 2008г. нормативно-правовые документы, регламентирующие инвестиционно-строительную деятельность: статус заказчика, инвестора, подрядчика;положение о заказчике, документы регламентирующие его деятельность в области предпроектной, проектной подготовки строительства и ее экспертизы (новое Пост. Прав. РФ nbsp;N 87 от 16.02.2008г. #034;О составе разделов проектной документации и требованиях к их содержанию#034; ); требования к организации и финансированию строительства, надзору за строительством, приемки в эксплуатацию законченного строительством объекта; взаимодействие заказчика с административными органами : подготовка проекта, оформлениеи получение разрешительной документации, экспертиза, ввод объекта в эксплуатацию; порядок предоставления земельного участка под строительство : процедура; выбор партнеров на конкурсной основе при строительстве объектов ;договоры и совместная деятельность в области строительства : договор инвестора и заказчика, договор строительного подряда, долевого участия, особенности правового регулирования права собственности на вновь создаваемые объекты недвижимости, изменение и расторжение договоров; структура договорных связей;особенности осуществления контроля и надзора при строительстве: на базе договора строительного подряда; по договору на выполнение отдельных видов работ при реконструкции и выполнении ремонтных работ; по договору об оказании возмездных услуг; по договору купли-продажи; по договору лизинга, при строительстве хозяйственным способом;формы реализации функций заказчика: государственный заказчик, управляющая компания, инжиниринговая фирма, заказчик-застройщик, служба заказчика, технический надзор за строительством, совмещение функций (инвестор-заказчик, подрядчик-заказчик);взаимодействие службы заказчика с: инвестором (застройщиком), изыскательской и проектной организацией, поставщиками материалов, банками и кредитными организациями, генеральным подрядчиком, субподрядчиком;права, обязанности и ответственность службы заказчика при реализации инвестиционного проекта (получение разрешений и подготовка к строительству, при выполнении работ, при вводе объекта в эксплуатацию и в период гарантийной эксплуатации): при бюджетном финансировании или при реализации коммерческих проектов; претензионно-исковая работа , подготовка материалов к рассмотрению дел в арбитражном суде; определение стоимости СМР на основе новой сметно-нормативной базы с учетом спецификиценообразующих факторов, роль заказчика в формировании сметных показателей. Формированиедоговорных цен на строительную продукцию. Инвесторские сметы и расчеты (сметы, калькуляции)подрядчика. Определение сметной стоимости - методы расчета. Определение средств на оплату труда, стоимости материальных ресурсов, накладных расходов и сметной прибыли, оплата затрат на содержание службы заказчика-застройщика; особенности расчетов между инвестором заказчиком и подрядной организацией правовое регулирование обеспечения качества строительства ; отражение этого в договорах и нормах , стандарты ИСО, приемка и ввод в эксплуатацию законченных строительных объектов; Телефон для информации и регистрации участников (495) 721-62-38 Стоимость участия в семинаре - 11 675 руб . НДС не обл. В стоимость входит питание (обеды) и раздаточный материал При участии 2-х человек и более предоставляется скидка в размере 5% Место проведения: г .Москва, ул. Ярославская д.15, порп 3, конф.зал., (Проезд м. ВДНХ), бронируется гостиница. - 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] Эксклюзивные модели телефонов
СУПЕРНОВИНКИ МОБИЛЬНЫХ ТЕЛЕФОНОВ www.vip-gsm.ru [EMAIL PROTECTED] Тюнинг, Эксклюзив, Vertu, Mobiado т. (985) 226-48-22 т. (495) 980-99-20 Адрес: г.Москва, ул.Новый Арбат, д.19, магазин Юпитер ст.метроnbsp;Арбатская или Смоленская. icq: 455753258 icq: 484524791 - 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] Persisent public properties, transforms and security
Hello, Here is a question regarding general understanding of MSI properties and their persistence across product life. From what I understand, properties provided on the command line at installation-time are not stored by Windows Installer for later use. For example, if I do type: msiexec /i prod.msi BACKUP_SERVER=backup-1.company.com the BACKUP_SERVER will not be used (or event defined) upon repair. One solution is to save BACKUP_SERVER in the registry upon installation and then detect that Windows Installer is currently repairing the product, for it to use the value stored in the registry. Q1: Is there an alternative? Another possibility is to use an MSI transform. The BACKUP_SERVER property will then be saved as a transform and the transform will be applied to the MSI upon installation: msiexec /i prod.msi TRANSFORMS=transf.mst When repairing, the content of transf.mst will again be used. This solution is therefore more elegant because there is no need to put some noise in the registry. Problem: what about security? From what I've understood, it is possible to add anything in a transform. Therefore, a system admin could make prod.msi do something dangerous (for example with a custom action defined in the transform), even if prod.msi is digitally signed, and deploy it over the network. Q2: How can a software provider ensure that his MSI in conjunction with an MSI transform will do expected things (I am planing to automate MSI installations with an auto-update service)? Is there a mechanism for limiting the level of alterations induced by a transform (say, only modify the property table or some properties)? Thanks, best regards, JV _ Vous en avez marre de ne pas avoir de place dans votre boîte de réception? Windows Live Hotmail vous offre dès maintenant 5GB de stockage gratuit! Ouvrez gratuitement votre compte Windows Live Hotmail ici! http://get.live.com/mail/overview- 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] finding .net 3.5 or greater
Don, You can use an approach from the article How to determine which versions of the .NET Framework are installed and whether service packs have been applied: http://support.microsoft.com/kb/318785 Just enumerate and analyze subfolder names from the folder %systemroot%\Microsoft.NET\Framework It can be implemented as a Custom Action. WBR, Yuri -Original Message- Date: Mon, 19 May 2008 15:26:43 -0700 From: Don Tasanasanta (Volt) [EMAIL PROTECTED] Subject: [WiX-users] finding .net 3.5 or greater To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] icrosoft.com Content-Type: text/plain; charset=us-ascii How do you determine whether or not the version of .NET Framework on the machine is greater than 3.5? - 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] Integrate WiX in our process
Hi Rob, thanks for your answer The few shared files are in components defined manually, so it's not a problem. When it comes to the thousand of (unshared) files, manually defining components is not an option - there's no way to do it in code, one must use Installshield's clunky GUI. This setup works pretty well, except when it comes to patching. Indeed, NSIS's interaction with MSI is not that good, this is why we are looking for solutions of harmonizing patching with the main installer. Regarding your personal philosophy, I don't think there's really a choice when using MSI. How am I supposed to know what files are to be modified on the user's system, in a future patch ? How can I correctly define components without an intimate knowledge of the relationship between files ? I can only go the paranoid path of one component / file, and at the same time, flush any performance down the drain - most of our files are small include headers in the KB range. Upon further consideration, maybe MSI is not that well suited for us, and what I should do is move the main product to an xcopy setup, and do away with these pesky components altogether :) -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor Romania Work: +40 21 305 2064 Mobile: +40 728 052 499 This e-mail, and any associated attachments have been classified as: [X] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 9:10 PM To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net Subject: RE: Integrate WiX in our process The Dynamic linking feature where Component Ids change with every build makes it impossible to patch. In fact, I think the only option available to you using that methodology for creating MSI packages is major upgrade. Also, I assume you don't have any shared files in the big zip file because those would not be reference counted correctly. It's interesting you use NSIS for the patches. Does the interaction between NSIS patches plus MSI repair/uninstall work out well? I'm not up on the intimate details of patching but there are new features in the WiX toolset that enable you to create patches that target subsets of your setup authoring. That enables you to build independent patches for different areas of your installation. However, when you need to patch the same file more than once, the patch ordering definitely becomes an issue. I'm not sure this advanced functionality is available unless you use the WiX toolset to create the MSI (I think a lot of information comes from the .wixpdb), but it *may* be possible using admin images. Ultimately, I believe that you are correct that maintaining Component Guids is going to be the hardest problem to tackle when creating your patch system. I know Bob had to tackle this exact problem in his day job so he may have suggestions of things to try or avoid. I also know that tallow/heat in their current form will not help you because they don't correctly assign Guids. I haven't tried paraffin but on my initial readings it looked like it was trying to do the right thing... but I don't know if it works in this sort of scenario. Note, these issues for Component Guid are a recognized pain point in the Windows Installer. I'm still working on a way to solve the problem of automatic Guid generation. Finally, the philosophy that each developer should maintain their portion of setup is my personal philosophy. The WiX toolset has features to enable such distributed setup development but that doesn't mean you have to use them. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ene Stelian-Bogdan Sent: Monday, May 19, 2008 09:41 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Integrate WiX in our process Hello, Here's the way our process currently looks like: - We build and ship the main product installer as an MSI, Installshield based project. I am talking about a 900MB product, comprising of about 15.000 files and 2300 folders, so we use Installshield's Dynamic linking feature extensively. (Basically, you point to a folder, and components will be generated on the fly at build time, one component per directory; the ComponentIDs will of course change on every rebuild) Needless to say, we don't subscribe to the MSI/WiX philosophy of having developers maintain the installer components; I receive one big zip file, and must deliver an installer. While I have nothing against changing this state of facts, I don't think it will change soon. - When new chips are introduced, we must deliver a Service pack that will offer compiling/debugging support for it. The patch will generally add new files to the installation, and sometimes update existing files, always in a backwards-compatible manner. Since customers will download only the patch offering support for the device they are working
Re: [WiX-users] Integrate WiX in our process
I'd like to address a couple things about InstallShield.In IS2009 (currently Beta) there is improved support for dynamic linking and upgrading/patching support. Things like table primary key identifiers and component guids should be much better behaved. Even then, I would really hesitate to use the feature for reasons I explain below. Also you don't have to use the clunky/disagree GUI to author installs with InstallShield. There is an automation interface. It's COM based and it makes sense to a VB6/Script user but from a C#/Interop perspective, it is somewhat clunky. However, I have a bigger philosophical problem with this type of `dynamic` pattern regardless of how it's implemented. How do you really know that what's been handed to you truly represents the developers intent? I do build and install automation and all the time I see what I call the `dangling chad` phenom - `deciphering developer (voter) intent`.Either some file is missing or some file is new. The question is, should it really be missing ( or is it a build failure? ) or should it really be new ( or was it an accident? ). It's impossible to know for 100% certain without asking the developer. Is less then 100% good enough? I guess it depends. So what I do is write some build automation that uses an Administrative Install to extract the build and then compare it to the sources. Missing files cause a build break and extra files cause a build break.When a build breaks, we find out why and fix it. This could mean fixing a broken project that's missing a file, fixing a project project that outputs too many files or updating the installer to reflect the new state. Now `updating to reflect the new state` could be a manual process or you could write some automation to do it.Which route you go depends on the level of pain of doing it manual ... the ROI if you will. Either way, in my book, you can't do either until you first decipher intent. Regards, Christopher Painter http://blog.deploymentengineering.com Ene Stelian-Bogdan [EMAIL PROTECTED] wrote: Hi Rob, thanks for your answer The few shared files are in components defined manually, so it's not a problem. When it comes to the thousand of (unshared) files, manually defining components is not an option - there's no way to do it in code, one must use Installshield's clunky GUI. This setup works pretty well, except when it comes to patching. Indeed, NSIS's interaction with MSI is not that good, this is why we are looking for solutions of harmonizing patching with the main installer. Regarding your personal philosophy, I don't think there's really a choice when using MSI. How am I supposed to know what files are to be modified on the user's system, in a future patch ? How can I correctly define components without an intimate knowledge of the relationship between files ? I can only go the paranoid path of one component / file, and at the same time, flush any performance down the drain - most of our files are small include headers in the KB range. Upon further consideration, maybe MSI is not that well suited for us, and what I should do is move the main product to an xcopy setup, and do away with these pesky components altogether :) -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor Romania Work: +40 21 305 2064 Mobile: +40 728 052 499 This e-mail, and any associated attachments have been classified as: [X] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 9:10 PM To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net Subject: RE: Integrate WiX in our process The Dynamic linking feature where Component Ids change with every build makes it impossible to patch. In fact, I think the only option available to you using that methodology for creating MSI packages is major upgrade. Also, I assume you don't have any shared files in the big zip file because those would not be reference counted correctly. It's interesting you use NSIS for the patches. Does the interaction between NSIS patches plus MSI repair/uninstall work out well? I'm not up on the intimate details of patching but there are new features in the WiX toolset that enable you to create patches that target subsets of your setup authoring. That enables you to build independent patches for different areas of your installation. However, when you need to patch the same file more than once, the patch ordering definitely becomes an issue. I'm not sure this advanced functionality is available unless you use the WiX toolset to create the MSI (I think a lot of information comes from the .wixpdb), but it *may* be possible using admin images. Ultimately, I believe that you are correct that maintaining Component Guids is going to be the hardest problem to tackle
[WiX-users] Please help me understand SelfReg and GAC library dependencies
OK, I know it's not the best way to install things with WiX, but my product
includes a DirectShow filter, and they create some random binary registry
entry on selfRegistration, so I have little choice but to register it as
self reg.
unfortunatley, because it depends on the DirectShow samples in the SDK, it
also ends up depending on the latest version of the run time libraries (at
least I couldn't get it to build without them being dynamically linked).
So, I'm stuck.
I've authored the following to selfreg after I've installed the msm's for
vs2005:
Component Id=AxGrab Guid={MYGUIDS}
File Id=axgrab Name=grabber.ax
Source=..\Grabber\Release\grabber.ax /
/Component
then to declare the custom actions, I add:
CustomAction Id=regGrabber Execute=commit
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /y
[#axgrab]' Impersonate='no' /
CustomAction Id=unregGrabber Execute=commit
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x
[#axgrab]' Impersonate='no' /
CustomAction Id=rollbackGrabber Execute=rollback
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x
[#axgrab]' Impersonate='no' /
finally, in the install execute sequence I add:
InstallExecuteSequence
...
Custom Action=unregGrabber
Before=SelfUnregModules$AxGrab=2/Custom
Custom Action=regGrabber Before=InstallFinalize
$AxGrab2/Custom
Custom Action=rollbackGrabber After=regGrabber
$AxGrab2/Custom
...
/InstallExecuteSequence
I haven't checked my logs yet as I've had to do a full restore to get back
to a known state, but while uninstalling, I got the message are you sure
you wan't to uninstall, and regardless of how i answer, the uninstall rolls
back and says there's some error. That may not be to do with this though,
as some other weirdness is also going on calling DPInst.exe to install a
device driver.
Does the above sequence look like the right sequencing and conditions for
the CustomActions?
Should I be ignoring the return codes using Return=ignore
Anthony Wieser
Wieser Software Ltd
-
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] DTF in WiX
Oh, about getting a QDatabase from a Session, I just realized there is a much easier way that doesn't require any code modification. The LINQ assembly adds an extension method to the ordinary Database class that converts it to a QDatabase. Just call session.Database.AsQueryable() From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau Sent: Monday, May 19, 2008 3:30 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I created Visual Studio templates today for C# and VB custom action projects. Look for them in the next build. I really should have done this before the release -- sorry for making you figure things out the hard way. I'm happy to review any samples you want to contribute or blog about. Be careful with the LINQ stuff... as noted in the doc it is experimental and has some limitations. I am interested in feedback about it though: How useful do you think it would be if the implementation was high quality? Anyway it looks there's currently no public way to get a QDatabase for a custom action Session. That's an oversight that will be easy to fix. If you want to get something working temporarily, you can change the internal QDatabase constructor to public, rebuild, and then create one like this: new QDatabase(session.Database.Handle, false, String.Empty, DatabaseOpenMode.ReadOnly); To query a custom table, just use the indexer on the QDatabase instance: qdb[tableName] returns a general-purpose QTableQRecord. Or you can create your own custom QRecord subclass (like the ones in Entities.cs) and create and run queries on a QTableYourCustomRecord -Jason- From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 11:26 AM To: Jason Ginchereau; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] DTF in WiX If you'd give me some requirements and peer review my work, I'd be willing to help contribute the samples as part of my DTF learning process. BTW, I'm refactoring an ExecuteQuery/Scalar pattern I just wrote to LINQ and I'm a little confused on how to get from session to QDatabase. the db.InstallExecuteSequences explanation doesn't make sense to me. ( BTW, my query is against a custom table, not a well known table ). Jason Ginchereau [EMAIL PROTECTED] wrote: Yes, a VS project template for a managed custom action is something we've talked about that would be nice to do. In general I want to work on some richer CA samples in the coming months. From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 7:39 PM To: Jason Ginchereau; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX Sorry, one more question. How do you feel about WiX registering a new project type in Visual Studio? A sample C# class that includes the right references and plumbing to build the class and wrap it into a CA package assembly? Jason Ginchereau [EMAIL PROTECTED] wrote: 1) Yes, full support for the new functionality added in MSI 4.5 is near the top of my list of things to work on in DTF. I have briefly looked at the embedded external-UI feature, and I don't forsee any unusual technical challenges to enabling embedded external-UI in managed code. 2) Oh, I guess that sample code in the doc is out of date. Properties are accessed as an indexer directly on the session object. The CHM reference topic for the Session class (Item Property) and the actual sample ManagedCA project are correct. 3) DTF samples are included in the WiX sources (src/dtf/Samples) but not in WiX3.msi. 4) Umm, grapefruit juice. Seriously. :) Thank you for reporting these issues. I hope you find DTF useful. -Jason- From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 1:25 PM To: Jason Ginchereau; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I have a few other questions for you if you don't mind. 1) Will DTF have support for authoring MSI 4.5 style Embedded External UI handlers? 2) The Sample C# custom action references a Session.Property[ string Property ] but when I add the reference and using statement I get an error that that Session doesn't have a definition for Property. Am I pulling in the wrong reference or something? 3) The CHM topic references a Samples\ManagedCA directory. I don't see it? 4) What's your favorite beverage? Jason Ginchereau [EMAIL PROTECTED] wrote: Looks like Errors.resources.resources got ignored by by the zip which is supposed to pickup all the sources, because of the .resources file extension. I'll fix it for the next build. Meanwhile you can create that file by running resgen.exe on Errors.txt. (I should probably make that happen during the project build anyway.) Or you can build without it, but you'll get resource exceptions instead of error messages if you encounter any errors in cabinet creation/extraction.
[WiX-users] DTF in WiX - LINQ Issue
I'm trying to do my first custom action with a LINQ query with the below code.
However I'm getting an exception.I've stepped through the debugger and
what's wierd is that when var actions get assigned and proccessed it thinks
there is 6 selectColumns instead of 3. It then goes to build a query string
duplicating the columns like this:
SELECT `Property`, `Expression`, `Condition`, `Property`, `Expression`,
`Condition` FROM `Math`
I'm not sure if this is an SDK bug or if I'm consuming it incorrectly. If I
take out the lines that say Property, Expression, Condition I see 3
selectColumns but I still get the exception.
Exception thrown by custom action:
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.NullReferenceException: Object reference
not set to an instance of an object.
at Microsoft.Deployment.WindowsInstaller.Linq.Query`1.GetResult(Record
resultRec)
at
Microsoft.Deployment.WindowsInstaller.Linq.Query`1.InvokeQueryd__0.MoveNext()
at MGAM.Installer.CustomActions.LinqTest.ProcessMath(Session session)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object
arguments, SignatureStruct sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object
arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle
typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32
sessionHandle, String entryPoint, Int64 remotingDelegatePtr)
[CustomAction]
public static ActionResult ProcessMath( Session session )
{
QDatabase db = session.Database.AsQueryable();
var actions = from a in db[Math]
select new
{
Property = a[Property],
Expression = a[Expression],
Condition = a[Condition]
};
foreach (var a in actions)
{
Console.WriteLine(test);
}
-
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] Create a repair setup
Hi, I'm struggling to create quite a simple wix-setup-project. I would like to create a MSI to install some components - so far so god. If I execute my installer again, I always get a message stating, that the product is already installed - which is correct :). But instead of this message I would like to start a repair-setup ... but how would I achieve this with wix? -- Mit freundlichem Gruß Henning Eiben busitec GmbH Consultant e-mail: [EMAIL PROTECTED] +49 (251) 13335-0 Tel +49 (251) 13335-35 Fax Rudolf-Diesel-Straße 59 48157 Münster www.busitec.de Sitz der Gesellschaft: Münster HR B 55 75 - Amtsgericht Münster USt-IdNr. DE 204607833 - St.Nr. 336/5704/1277 Geschäftsführer: Simon Böwer, Henning Eiben, Stefan Kühn, Martin Saalmann - 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] DTF in WiX
FWIW, I had to turn off all the signing in the MakeSfxCA project to get this to work. Just in case anyone else tries to build it, they will need to do the same presumably. Chris On Fri, May 16, 2008 at 3:35 PM, Jason Ginchereau [EMAIL PROTECTED] wrote: Yes, sorry it looks like I accidentally omitted MakeSfxCA.exe from the binaries zip and the MSI. I'll get it in for next week's build. Meanwhile you should be able to build it easily from the sources. -Jason- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Christopher Painter *Sent:* Friday, May 16, 2008 11:32 AM *To:* wix-users@lists.sourceforge.net *Subject:* [WiX-users] DTF in WiX I'm was reading DTF.chm and it looks really fabulous. I want to play with it right now but I don't see MakeSfxCA.exe. Am I missing something? - 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] Integrate WiX in our process
Hehe
I suppose some of our international users might not understand the reference
especialling since I said dangling chad instead of hanging chad. In case you
don't know, it's a reference to problematic paper ballots used during elections.
Anyways, at the time I started using the expression for setups I was working
at a company called Hart InterCivic that was in the elections space. We
actually worked in a different space but it just fit.
Chad Petersen [EMAIL PROTECTED] wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }I take exception to your
dangling chad remark. Why cant it be a dangling chris? Just this once?
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Tuesday, May 20, 2008 8:51 AM
To: Ene Stelian-Bogdan; Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Integrate WiX in our process
I'd like to address a couple things about InstallShield.In IS2009
(currently Beta) there is improved support for dynamic linking and
upgrading/patching support. Things like table primary key identifiers and
component guids should be much better behaved. Even then, I would really
hesitate to use the feature for reasons I explain below.
Also you don't have to use the clunky/disagree GUI to author installs
with InstallShield. There is an automation interface. It's COM based and it
makes sense to a VB6/Script user but from a C#/Interop perspective, it is
somewhat clunky.
However, I have a bigger philosophical problem with this type of `dynamic`
pattern regardless of how it's implemented. How do you really know that
what's been handed to you truly represents the developers intent?
I do build and install automation and all the time I see what I call the
`dangling chad` phenom - `deciphering developer (voter) intent`.Either some
file is missing or some file is new. The question is, should it really be
missing ( or is it a build failure? ) or should it really be new ( or was it
an accident? ). It's impossible to know for 100% certain without asking the
developer. Is less then 100% good enough? I guess it depends.
So what I do is write some build automation that uses an Administrative
Install to extract the build and then compare it to the sources. Missing files
cause a build break and extra files cause a build break.When a build
breaks, we find out why and fix it. This could mean fixing a broken project
that's missing a file, fixing a project project that outputs too many files or
updating the installer to reflect the new state.
Now `updating to reflect the new state` could be a manual process or you
could write some automation to do it.Which route you go depends on the
level of pain of doing it manual ... the ROI if you will. Either way, in my
book, you can't do either until you first decipher intent.
Regards,
Christopher Painter
http://blog.deploymentengineering.com
Ene Stelian-Bogdan [EMAIL PROTECTED] wrote:
Hi Rob, thanks for your answer
The few shared files are in components defined manually, so it's not a
problem. When it comes to the thousand of (unshared) files, manually
defining components is not an option - there's no way to do it in code,
one must use Installshield's clunky GUI. This setup works pretty well,
except when it comes to patching.
Indeed, NSIS's interaction with MSI is not that good, this is why we are
looking for solutions of harmonizing patching with the main installer.
Regarding your personal philosophy, I don't think there's really a
choice when using MSI. How am I supposed to know what files are to be
modified on the user's system, in a future patch ? How can I correctly
define components without an intimate knowledge of the relationship
between files ? I can only go the paranoid path of one component / file,
and at the same time, flush any performance down the drain - most of our
files are small include headers in the KB range.
Upon further consideration, maybe MSI is not that well suited for us,
and what I should do is move the main product to an xcopy setup, and do
away with these pesky components altogether :)
--
Stelian ENE
Installer Engineer, DevTech
Freescale Semiconductor Romania
Work: +40 21 305 2064
Mobile: +40 728 052 499
This e-mail, and any associated attachments have been classified as:
[X] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 9:10 PM
To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net
Subject: RE: Integrate WiX
Re: [WiX-users] Integrate WiX in our process
I take exception to your 'dangling chad' remark. Why can't it be a dangling chris? Just this once? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Tuesday, May 20, 2008 8:51 AM To: Ene Stelian-Bogdan; Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Integrate WiX in our process I'd like to address a couple things about InstallShield.In IS2009 (currently Beta) there is improved support for dynamic linking and upgrading/patching support. Things like table primary key identifiers and component guids should be much better behaved. Even then, I would really hesitate to use the feature for reasons I explain below. Also you don't have to use the clunky/disagree GUI to author installs with InstallShield. There is an automation interface. It's COM based and it makes sense to a VB6/Script user but from a C#/Interop perspective, it is somewhat clunky. However, I have a bigger philosophical problem with this type of `dynamic` pattern regardless of how it's implemented. How do you really know that what's been handed to you truly represents the developers intent? I do build and install automation and all the time I see what I call the `dangling chad` phenom - `deciphering developer (voter) intent`. Either some file is missing or some file is new. The question is, should it really be missing ( or is it a build failure? ) or should it really be new ( or was it an accident? ). It's impossible to know for 100% certain without asking the developer. Is less then 100% good enough? I guess it depends. So what I do is write some build automation that uses an Administrative Install to extract the build and then compare it to the sources. Missing files cause a build break and extra files cause a build break. When a build breaks, we find out why and fix it. This could mean fixing a broken project that's missing a file, fixing a project project that outputs too many files or updating the installer to reflect the new state. Now `updating to reflect the new state` could be a manual process or you could write some automation to do it.Which route you go depends on the level of pain of doing it manual ... the ROI if you will. Either way, in my book, you can't do either until you first decipher intent. Regards, Christopher Painter http://blog.deploymentengineering.com Ene Stelian-Bogdan [EMAIL PROTECTED] wrote: Hi Rob, thanks for your answer The few shared files are in components defined manually, so it's not a problem. When it comes to the thousand of (unshared) files, manually defining components is not an option - there's no way to do it in code, one must use Installshield's clunky GUI. This setup works pretty well, except when it comes to patching. Indeed, NSIS's interaction with MSI is not that good, this is why we are looking for solutions of harmonizing patching with the main installer. Regarding your personal philosophy, I don't think there's really a choice when using MSI. How am I supposed to know what files are to be modified on the user's system, in a future patch ? How can I correctly define components without an intimate knowledge of the relationship between files ? I can only go the paranoid path of one component / file, and at the same time, flush any performance down the drain - most of our files are small include headers in the KB range. Upon further consideration, maybe MSI is not that well suited for us, and what I should do is move the main product to an xcopy setup, and do away with these pesky components altogether :) -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor Romania Work: +40 21 305 2064 Mobile: +40 728 052 499 This e-mail, and any associated attachments have been classified as: [X] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 9:10 PM To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net Subject: RE: Integrate WiX in our process The Dynamic linking feature where Component Ids change with every build makes it impossible to patch. In fact, I think the only option available to you using that methodology for creating MSI packages is major upgrade. Also, I assume you don't have any shared files in the big zip file because those would not be reference counted correctly. It's interesting you use NSIS for the patches. Does the interaction between NSIS
Re: [WiX-users] Integrate WiX in our process
Hehe
I suppose some of our international users might not understand the reference
especialling since I said dangling chad instead of hanging chad. In case you
don't know, it's a reference to problematic paper ballots used during elections.
Anyways, at the time I started using the expression for setups I was working
at a company called Hart InterCivic that was in the elections space. We
actually worked in a different space but it just fit.
Chad Petersen [EMAIL PROTECTED] wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }I take exception to your
dangling chad remark. Why cant it be a dangling chris? Just this once?
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Tuesday, May 20, 2008 8:51 AM
To: Ene Stelian-Bogdan; Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Integrate WiX in our process
I'd like to address a couple things about InstallShield.In IS2009
(currently Beta) there is improved support for dynamic linking and
upgrading/patching support. Things like table primary key identifiers and
component guids should be much better behaved. Even then, I would really
hesitate to use the feature for reasons I explain below.
Also you don't have to use the clunky/disagree GUI to author installs
with InstallShield. There is an automation interface. It's COM based and it
makes sense to a VB6/Script user but from a C#/Interop perspective, it is
somewhat clunky.
However, I have a bigger philosophical problem with this type of `dynamic`
pattern regardless of how it's implemented. How do you really know that
what's been handed to you truly represents the developers intent?
I do build and install automation and all the time I see what I call the
`dangling chad` phenom - `deciphering developer (voter) intent`.Either some
file is missing or some file is new. The question is, should it really be
missing ( or is it a build failure? ) or should it really be new ( or was it
an accident? ). It's impossible to know for 100% certain without asking the
developer. Is less then 100% good enough? I guess it depends.
So what I do is write some build automation that uses an Administrative
Install to extract the build and then compare it to the sources. Missing files
cause a build break and extra files cause a build break.When a build
breaks, we find out why and fix it. This could mean fixing a broken project
that's missing a file, fixing a project project that outputs too many files or
updating the installer to reflect the new state.
Now `updating to reflect the new state` could be a manual process or you
could write some automation to do it.Which route you go depends on the
level of pain of doing it manual ... the ROI if you will. Either way, in my
book, you can't do either until you first decipher intent.
Regards,
Christopher Painter
http://blog.deploymentengineering.com
Ene Stelian-Bogdan [EMAIL PROTECTED] wrote:
Hi Rob, thanks for your answer
The few shared files are in components defined manually, so it's not a
problem. When it comes to the thousand of (unshared) files, manually
defining components is not an option - there's no way to do it in code,
one must use Installshield's clunky GUI. This setup works pretty well,
except when it comes to patching.
Indeed, NSIS's interaction with MSI is not that good, this is why we are
looking for solutions of harmonizing patching with the main installer.
Regarding your personal philosophy, I don't think there's really a
choice when using MSI. How am I supposed to know what files are to be
modified on the user's system, in a future patch ? How can I correctly
define components without an intimate knowledge of the relationship
between files ? I can only go the paranoid path of one component / file,
and at the same time, flush any performance down the drain - most of our
files are small include headers in the KB range.
Upon further consideration, maybe MSI is not that well suited for us,
and what I should do is move the main product to an xcopy setup, and do
away with these pesky components altogether :)
--
Stelian ENE
Installer Engineer, DevTech
Freescale Semiconductor Romania
Work: +40 21 305 2064
Mobile: +40 728 052 499
This e-mail, and any associated attachments have been classified as:
[X] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 9:10 PM
To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net
Subject: RE: Integrate WiX
[WiX-users] setupexe and CompareString on Windows 2000
I know there were some discussions before regarding the proper use of CompareString() in the Wix sources, but I can't seem to find them. I found a problem running the setupexe.exe in Wix on Windows 2000. The command line parsing which uses CompareString is failing because of the LOCALE_INVARIANT which apparently is only available on Windows XP and higher. According to MSDN it should be like this: On Windows XP and later: CompareString(LOCALE_INVARIANT, NORM_IGNORECASE, mystr, -1, _T(InLap), -1); For earlier operating systems: DWORD lcid = MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT); CompareString(lcid, NORM_IGNORECASE, mystr, -1, _T(InLap), -1); Is this a bug in Wix, or was it designed this way? Thanks, Mike Ballou - 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] Integrate WiX in our process
On Tue, 20 May 2008 11:37:24 -0700 (PDT), Christopher Painter wrote: Christopher, I suppose some of our international users might not understand the reference especialling since I said dangling chad instead of hanging chad. In this era of CNN, who wouldn't know? :-) Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - 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] really slow using pyro
2. Simply supply the wixpdb instead of the wixout files in your command-line. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy Sent: Monday, May 19, 2008 5:24 PM To: Rob Mensching Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] really slow using pyro 1. ok.. I'll bite. How would I override the default BinderFileManager in an extension? Can you point me at an extension that overrides a part of the WiX system in a way that is similar to what I'd have to do? 2. How can I use the pdb instead? Is there a cmdline argument to pyro for that? Kelly Rob Mensching [EMAIL PROTECTED] 05/15/2008 08:54 PM To Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net, [EMAIL PROTECTED] [EMAIL PROTECTED] Subject RE: [WiX-users] really slow using pyro “safe” is one way to look at it. “correct” is another. smile/ We can look at adding a switch to make it easy, but you can actually get what you want right now. You could implement an extension that overrides the default “BinderFileManager” and implement the CompareFiles() method using the method you describe. You can see the default BinderFileManager does a byte by byte comparison. Also, I noticed that you were using .wixouts to build your patch. I would recommend using the .wixpdb instead. That will actually have all the necessary information to get much faster comparison (when the switch is finally implemented). From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 20:33 To: Rob Mensching Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] really slow using pyro I'm a bit suprised that it is doing this comparison for every file. Is it just to be safe? Could we add a switch that allowed it to do slightly less safe comparisons (i.e. I can guarantee that if two files have the same date, size, and name, that their contents are the same (or at least I'm willing to take that risk)). Wouldn't that speed up comparisons considerably? Kelly Rob Mensching [EMAIL PROTECTED] 05/15/2008 08:19 PM To Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net, [EMAIL PROTECTED] [EMAIL PROTECTED] Subject RE: [WiX-users] really slow using pyro I talked to Peter. For a product with ~2,000 - 3,000 files 10 minutes is reasonable. Pyro is diffing all of the files in your product looking for different ones and that takes time. I noticed that you are using Includes all over the place. Instead, you could use Fragments and get improvements in the compile steps and also do filtering at the Fragment level during patching. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 12:01 To: Rob Mensching Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] really slow using pyro 10 minutes running pyro, 2 minutes running the 'light' command line that builds the original msi's. Were you able to get the makefile, or do you want me to paste the command lines into an email for you? Kelly Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/15/2008 10:04 AM To Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject Re: [WiX-users] really slow using pyro One more question: can you give me an idea of the time spent building MSI vs. building MSP? Basically, I’m looking for a bit more details about what “long time” means. smile/ I’m not the patching expert but Peter is back from vacation and I’ll make sure he gets this thread tonight. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 09:14 To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] really slow using pyro Sorry, I was braindead last night and it didn't even occur to me that knowing the version and what I'm doing might be useful information :( 0. tried that - didn't seem to tell me much of anything. 1. 3.0.3419 - I'll try a newer build today. 2. pyro Update1\Build\USA\Patch.wixmsp -out Update1\Build\USA\Patch.msp -t mgalfa Update1\Build\USA\DiffRTM.wixmst (entire makefile is attached) 3. all files are local other info: running Vista x64 Business on a quad-core machine with 4gb RAM and mirrored HDDs using hardware RAID. not much else going on while building (I've been giving it the full machine). Patch.wxs file, Product.wxs file, .wxi's, and makefile attached. The wixproj contains the RTM folder's contents. The Update1 folder mentioned in the makefile is nearly identical, with only differences being in content and the definitions in the defines.wxi (also attached here). Any recommendations would be greatly appreciated - and if there's anything I can do to
[WiX-users] DTF in MSBuild
I've got the DTF wrapper bit running as a simple exec task by adding the
following to the end of my project file for the CA dll.
It uses the project output and appends an _Sfx to it to mark it as the
wrapped version. It's brute force, and it steals from the wix.targets
file
Pay special attention to the DTFBin Property. you can find a better way to
populate it, or just change it to point to your installation. I had to
build the DTF myself and disable a bunch of the signing to get this to work,
since MakeSfxCA.exe wasn't included in the binary distro for this release.
It's uglybut hey, if someone wants to use it/improve it, be my guest.
Chris
Target Name=AfterBuild
CallTarget Targets=MakeSfxCA /
/Target
!--
From the Wix.targets file - CMK
Several properties must be set in the main project file, before using this
.targets file.
However, if the properties are not set, we pick some defaults.
--
PropertyGroup
!-- Not a good way, but it works for me. This should use registry
search, the same way the wix.targets does --
DTFBinc:\Program Files (x86)\Windows Installer XML
v3\sdk\/DTFBin
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
Platform Condition= '$(Platform)'=='' AnyCPU/Platform
OutputPath Condition= '$(OutputPath)' == ''
bin\$(Configuration)\/OutputPath
!-- Ensure any OutputPath has a trailing slash, so it can be
concatenated --
OutputPath Condition= '$(OutputPath)' != '' and
!HasTrailingSlash('$(OutputPath)') $(OutputPath)\/OutputPath
_OriginalOutputType$(OutputType)/_OriginalOutputType
OutputType Condition= '$(OutputType)' == '' Library/OutputType
/PropertyGroup
PropertyGroup
!-- Example, bin\Debug\ --
OutDir Condition= '$(OutDir)' == '' $(OutputPath)/OutDir
!-- Ensure OutDir has a trailing slash, so it can be concatenated
--
OutDir Condition= '$(OutDir)' != '' and
!HasTrailingSlash('$(OutDir)') $(OutDir)\/OutDir
!-- Example, MyCA --
ProjectName Condition= '$(ProjectName)' == ''
$(MSBuildProjectName)/ProjectName
!-- Example, MyCA.csproj --
ProjectFileName Condition= '$(ProjectFileName)' == ''
$(MSBuildProjectFile)/ProjectFileName
!-- Example, .csproj --
ProjectExt Condition= '$(ProjectExt)' == ''
$(MSBuildProjectExtension)/ProjectExt
!-- Example, c:\MyProjects\MyCA\ --
ProjectDir Condition= '$(ProjectDir)' == ''
$(MSBuildProjectDirectory)\/ProjectDir
!-- Example, c:\MyProjects\MyCA\MyCA.csproj --
ProjectPath Condition= '$(ProjectPath)' == ''
$(ProjectDir)$(ProjectFileName)/ProjectPath
!-- Example, MyCA --
TargetName Condition= '$(TargetName)' == ''
$(OutputName)/TargetName
!-- Example, MyCA.dll --
TargetFileName Condition= '$(TargetFileName)' == ''
$(TargetName)$(TargetExt)/TargetFileName
!-- Example, MyCA_Sfx.dll --
TargetSfxName Condition= '$(TargetSfxName)' == ''
$(TargetName)_Sfx$(TargetExt)/TargetSfxName
!-- Example, x86, x64 --
TargetArchitecture Condition= '$(TargetArchitecture)' == ''
x86/TargetArchitecture
!-- Example, c:\MyProjects\MyCA\bin\Debug\ --
FullOutDir Condition= '$(FullOutDir)' == ''
$(ProjectDir)$(OutDir)/FullOutDir
/PropertyGroup
Target Name=MakeSfxCA
Exec Command=quot;$(DTFbin)MakeSfxCA.exequot;
quot;$(FullOutDir)$(TargetSfxName)quot;
quot;$(DTFbin)$(TargetArchitecture)\SfxCA.dllquot;
quot;$(FullOutDir)$(TargetFileName)quot;
quot;$(ProjectDir)CustomAction.configquot;
quot;$(DTFbin)Microsoft.Deployment.WindowsInstaller.dllquot;
quot;$(DTFbin)Microsoft.Deployment.Resources.dllquot; /
/Target
-
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] DTF in MSBuild
Oh yeah, also note, this depends on you having a file named
CustomAction.config in your project. I great improvement would be to have
it check for the file's existence before including it. :-)
YMMV.
Chris
On Tue, May 20, 2008 at 5:49 PM, Christopher Karper
[EMAIL PROTECTED] wrote:
I've got the DTF wrapper bit running as a simple exec task by adding the
following to the end of my project file for the CA dll.
It uses the project output and appends an _Sfx to it to mark it as the
wrapped version. It's brute force, and it steals from the wix.targets
file
Pay special attention to the DTFBin Property. you can find a better way to
populate it, or just change it to point to your installation. I had to
build the DTF myself and disable a bunch of the signing to get this to work,
since MakeSfxCA.exe wasn't included in the binary distro for this release.
It's uglybut hey, if someone wants to use it/improve it, be my guest.
Chris
Target Name=AfterBuild
CallTarget Targets=MakeSfxCA /
/Target
!--
From the Wix.targets file - CMK
Several properties must be set in the main project file, before using
this .targets file.
However, if the properties are not set, we pick some defaults.
--
PropertyGroup
!-- Not a good way, but it works for me. This should use
registry search, the same way the wix.targets does --
DTFBinc:\Program Files (x86)\Windows Installer XML
v3\sdk\/DTFBin
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
Platform Condition= '$(Platform)'=='' AnyCPU/Platform
OutputPath Condition= '$(OutputPath)' == ''
bin\$(Configuration)\/OutputPath
!-- Ensure any OutputPath has a trailing slash, so it can be
concatenated --
OutputPath Condition= '$(OutputPath)' != '' and
!HasTrailingSlash('$(OutputPath)') $(OutputPath)\/OutputPath
_OriginalOutputType$(OutputType)/_OriginalOutputType
OutputType Condition= '$(OutputType)' == ''
Library/OutputType
/PropertyGroup
PropertyGroup
!-- Example, bin\Debug\ --
OutDir Condition= '$(OutDir)' == '' $(OutputPath)/OutDir
!-- Ensure OutDir has a trailing slash, so it can be concatenated
--
OutDir Condition= '$(OutDir)' != '' and
!HasTrailingSlash('$(OutDir)') $(OutDir)\/OutDir
!-- Example, MyCA --
ProjectName Condition= '$(ProjectName)' == ''
$(MSBuildProjectName)/ProjectName
!-- Example, MyCA.csproj --
ProjectFileName Condition= '$(ProjectFileName)' == ''
$(MSBuildProjectFile)/ProjectFileName
!-- Example, .csproj --
ProjectExt Condition= '$(ProjectExt)' == ''
$(MSBuildProjectExtension)/ProjectExt
!-- Example, c:\MyProjects\MyCA\ --
ProjectDir Condition= '$(ProjectDir)' == ''
$(MSBuildProjectDirectory)\/ProjectDir
!-- Example, c:\MyProjects\MyCA\MyCA.csproj --
ProjectPath Condition= '$(ProjectPath)' == ''
$(ProjectDir)$(ProjectFileName)/ProjectPath
!-- Example, MyCA --
TargetName Condition= '$(TargetName)' == ''
$(OutputName)/TargetName
!-- Example, MyCA.dll --
TargetFileName Condition= '$(TargetFileName)' == ''
$(TargetName)$(TargetExt)/TargetFileName
!-- Example, MyCA_Sfx.dll --
TargetSfxName Condition= '$(TargetSfxName)' == ''
$(TargetName)_Sfx$(TargetExt)/TargetSfxName
!-- Example, x86, x64 --
TargetArchitecture Condition= '$(TargetArchitecture)' == ''
x86/TargetArchitecture
!-- Example, c:\MyProjects\MyCA\bin\Debug\ --
FullOutDir Condition= '$(FullOutDir)' == ''
$(ProjectDir)$(OutDir)/FullOutDir
/PropertyGroup
Target Name=MakeSfxCA
Exec Command=quot;$(DTFbin)MakeSfxCA.exequot;
quot;$(FullOutDir)$(TargetSfxName)quot;
quot;$(DTFbin)$(TargetArchitecture)\SfxCA.dllquot;
quot;$(FullOutDir)$(TargetFileName)quot;
quot;$(ProjectDir)CustomAction.configquot;
quot;$(DTFbin)Microsoft.Deployment.WindowsInstaller.dllquot;
quot;$(DTFbin)Microsoft.Deployment.Resources.dllquot; /
/Target
-
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] DTF in MSBuild
I took the lazy way out for now with a postbuild event since Jason has said
proper templates will be coming. I decided to add DTF to the filename for
uniqueness. My goal was to isolate the dependencies and wire it up as a
standard C# class project without any particularly special plumbing.
$(ProjectDir)SDK\MakeSfxCA.exe $(TargetDir)$(TargetName).DTF.dll
$(ProjectDir)SDK\sfxca.dll $(TargetPath)
$(ProjectDir)SDK\Microsoft.Deployment.WindowsInstaller.dll
$(ProjectDir)ExternalAssemblies\AxLibrary.dll
I also wrote a few blogs on the topic if you are interested. ( Can you tell,
I REALLY like DTF )
http://blog.deploymentengineering.com/2008/05/price-of-ideology-and-great-new-hope.html
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
http://blog.deploymentengineering.com/2008/05/data-driven-cas-made-easy-with-dtf.html
Christopher Karper [EMAIL PROTECTED] wrote:
Oh yeah, also note, this depends on you having a file named
CustomAction.config in your project. I great improvement would be to have it
check for the file's existence before including it. :-)
YMMV.
Chris
On Tue, May 20, 2008 at 5:49 PM, Christopher Karper [EMAIL PROTECTED] wrote:
I've got the DTF wrapper bit running as a simple exec task by adding the
following to the end of my project file for the CA dll.
It uses the project output and appends an _Sfx to it to mark it as the wrapped
version. It's brute force, and it steals from the wix.targets file
Pay special attention to the DTFBin Property. you can find a better way to
populate it, or just change it to point to your installation. I had to build
the DTF myself and disable a bunch of the signing to get this to work, since
MakeSfxCA.exe wasn't included in the binary distro for this release.
It's uglybut hey, if someone wants to use it/improve it, be my guest.
Chris
Target Name=AfterBuild
CallTarget Targets=MakeSfxCA /
/Target
!--
From the Wix.targets file - CMK
Several properties must be set in the main project file, before using this
.targets file.
However, if the properties are not set, we pick some defaults.
--
PropertyGroup
!-- Not a good way, but it works for me. This should use registry
search, the same way the wix.targets does --
DTFBinc:\Program Files (x86)\Windows Installer XML v3\sdk\/DTFBin
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
Platform Condition= '$(Platform)'=='' AnyCPU/Platform
OutputPath Condition= '$(OutputPath)' == ''
bin\$(Configuration)\/OutputPath
!-- Ensure any OutputPath has a trailing slash, so it can be
concatenated --
OutputPath Condition= '$(OutputPath)' != '' and
!HasTrailingSlash('$(OutputPath)') $(OutputPath)\/OutputPath
_OriginalOutputType$(OutputType)/_OriginalOutputType
OutputType Condition= '$(OutputType)' == '' Library/OutputType
/PropertyGroup
PropertyGroup
!-- Example, bin\Debug\ --
OutDir Condition= '$(OutDir)' == '' $(OutputPath)/OutDir
!-- Ensure OutDir has a trailing slash, so it can be concatenated --
OutDir Condition= '$(OutDir)' != '' and
!HasTrailingSlash('$(OutDir)') $(OutDir)\/OutDir
!-- Example, MyCA --
ProjectName Condition= '$(ProjectName)' == ''
$(MSBuildProjectName)/ProjectName
!-- Example, MyCA.csproj --
ProjectFileName Condition= '$(ProjectFileName)' == ''
$(MSBuildProjectFile)/ProjectFileName
!-- Example, .csproj --
ProjectExt Condition= '$(ProjectExt)' == ''
$(MSBuildProjectExtension)/ProjectExt
!-- Example, c:\MyProjects\MyCA\ --
ProjectDir Condition= '$(ProjectDir)' == ''
$(MSBuildProjectDirectory)\/ProjectDir
!-- Example, c:\MyProjects\MyCA\MyCA.csproj --
ProjectPath Condition= '$(ProjectPath)' == ''
$(ProjectDir)$(ProjectFileName)/ProjectPath
!-- Example, MyCA --
TargetName Condition= '$(TargetName)' == ''
$(OutputName)/TargetName
!-- Example, MyCA.dll --
TargetFileName Condition= '$(TargetFileName)' == ''
$(TargetName)$(TargetExt)/TargetFileName
!-- Example, MyCA_Sfx.dll --
TargetSfxName Condition= '$(TargetSfxName)' == ''
$(TargetName)_Sfx$(TargetExt)/TargetSfxName
!-- Example, x86, x64 --
TargetArchitecture Condition= '$(TargetArchitecture)' == ''
x86/TargetArchitecture
!-- Example, c:\MyProjects\MyCA\bin\Debug\ --
FullOutDir Condition= '$(FullOutDir)' == ''
$(ProjectDir)$(OutDir)/FullOutDir
/PropertyGroup
Target Name=MakeSfxCA
Exec Command=quot;$(DTFbin)MakeSfxCA.exequot;
quot;$(FullOutDir)$(TargetSfxName)quot;
quot;$(DTFbin)$(TargetArchitecture)\SfxCA.dllquot;
quot;$(FullOutDir)$(TargetFileName)quot;
quot;$(ProjectDir)CustomAction.configquot;
quot;$(DTFbin)Microsoft.Deployment.WindowsInstaller.dllquot;
Re: [WiX-users] DTF in MSBuild
It looks like you're copying in all the DTF support files into a subdir as
well. I was trying to just use the preinstalled locs.
To each their own. It'd be pretty easy to make an msbuild action out of
MakeSfxCA since it's all managed code anyway. I'm sure it'll come along
soon enough.
Chris
On Tue, May 20, 2008 at 5:58 PM, Christopher Painter
[EMAIL PROTECTED] wrote:
I took the lazy way out for now with a postbuild event since Jason has said
proper templates will be coming. I decided to add DTF to the filename for
uniqueness. My goal was to isolate the dependencies and wire it up as a
standard C# class project without any particularly special plumbing.
$(ProjectDir)SDK\MakeSfxCA.exe $(TargetDir)$(TargetName).DTF.dll
$(ProjectDir)SDK\sfxca.dll $(TargetPath)
$(ProjectDir)SDK\Microsoft.Deployment.WindowsInstaller.dll
$(ProjectDir)ExternalAssemblies\AxLibrary.dll
I also wrote a few blogs on the topic if you are interested. ( Can you
tell, I REALLY like DTF )
http://blog.deploymentengineering.com/2008/05/price-of-ideology-and-great-new-hope.html
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
http://blog.deploymentengineering.com/2008/05/data-driven-cas-made-easy-with-dtf.html
*Christopher Karper [EMAIL PROTECTED]* wrote:
Oh yeah, also note, this depends on you having a file named
CustomAction.config in your project. I great improvement would be to have
it check for the file's existence before including it. :-)
YMMV.
Chris
On Tue, May 20, 2008 at 5:49 PM, Christopher Karper
[EMAIL PROTECTED] wrote:
I've got the DTF wrapper bit running as a simple exec task by adding the
following to the end of my project file for the CA dll.
It uses the project output and appends an _Sfx to it to mark it as the
wrapped version. It's brute force, and it steals from the wix.targets
file
Pay special attention to the DTFBin Property. you can find a better way
to populate it, or just change it to point to your installation. I had to
build the DTF myself and disable a bunch of the signing to get this to work,
since MakeSfxCA.exe wasn't included in the binary distro for this release.
It's uglybut hey, if someone wants to use it/improve it, be my guest.
Chris
Target Name=AfterBuild
CallTarget Targets=MakeSfxCA /
/Target
!--
From the Wix.targets file - CMK
Several properties must be set in the main project file, before using
this .targets file.
However, if the properties are not set, we pick some defaults.
--
PropertyGroup
!-- Not a good way, but it works for me. This should use
registry search, the same way the wix.targets does --
DTFBinc:\Program Files (x86)\Windows Installer XML
v3\sdk\/DTFBin
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
Platform Condition= '$(Platform)'=='' AnyCPU/Platform
OutputPath Condition= '$(OutputPath)' == ''
bin\$(Configuration)\/OutputPath
!-- Ensure any OutputPath has a trailing slash, so it can be
concatenated --
OutputPath Condition= '$(OutputPath)' != '' and
!HasTrailingSlash('$(OutputPath)') $(OutputPath)\/OutputPath
_OriginalOutputType$(OutputType)/_OriginalOutputType
OutputType Condition= '$(OutputType)' == ''
Library/OutputType
/PropertyGroup
PropertyGroup
!-- Example, bin\Debug\ --
OutDir Condition= '$(OutDir)' == '' $(OutputPath)/OutDir
!-- Ensure OutDir has a trailing slash, so it can be concatenated
--
OutDir Condition= '$(OutDir)' != '' and
!HasTrailingSlash('$(OutDir)') $(OutDir)\/OutDir
!-- Example, MyCA --
ProjectName Condition= '$(ProjectName)' == ''
$(MSBuildProjectName)/ProjectName
!-- Example, MyCA.csproj --
ProjectFileName Condition= '$(ProjectFileName)' == ''
$(MSBuildProjectFile)/ProjectFileName
!-- Example, .csproj --
ProjectExt Condition= '$(ProjectExt)' == ''
$(MSBuildProjectExtension)/ProjectExt
!-- Example, c:\MyProjects\MyCA\ --
ProjectDir Condition= '$(ProjectDir)' == ''
$(MSBuildProjectDirectory)\/ProjectDir
!-- Example, c:\MyProjects\MyCA\MyCA.csproj --
ProjectPath Condition= '$(ProjectPath)' == ''
$(ProjectDir)$(ProjectFileName)/ProjectPath
!-- Example, MyCA --
TargetName Condition= '$(TargetName)' == ''
$(OutputName)/TargetName
!-- Example, MyCA.dll --
TargetFileName Condition= '$(TargetFileName)' == ''
$(TargetName)$(TargetExt)/TargetFileName
!-- Example, MyCA_Sfx.dll --
TargetSfxName Condition= '$(TargetSfxName)' == ''
$(TargetName)_Sfx$(TargetExt)/TargetSfxName
!-- Example, x86, x64 --
TargetArchitecture Condition= '$(TargetArchitecture)' == ''
x86/TargetArchitecture
!-- Example, c:\MyProjects\MyCA\bin\Debug\ --
FullOutDir Condition=
[WiX-users] how does Repair work?
How exactly does repair work? When choosing repair in maintenance mode what does Windows Installer do? Does it go back to the MSI logic and run through it again? Does it remember what was installed the first time and try to duplicate what was done? Here's the scenario: - Install product - uninstall dependency that install has - Try to repair product Repair fails because dependency has been removed. Originally the component that fails has a conditional to not install if dependency is not present. But the dependency was present during the initial install and then later removed. So the dependency was gone during repair but the repair still tries to fix the component with the dependency and fails. Any way around 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
Re: [WiX-users] how does Repair work?
Mark the component transitive. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta (Volt) Sent: Tuesday, May 20, 2008 16:20 To: wix-users@lists.sourceforge.net Subject: [WiX-users] how does Repair work? How exactly does repair work? When choosing repair in maintenance mode what does Windows Installer do? Does it go back to the MSI logic and run through it again? Does it remember what was installed the first time and try to duplicate what was done? Here's the scenario: - Install product - uninstall dependency that install has - Try to repair product Repair fails because dependency has been removed. Originally the component that fails has a conditional to not install if dependency is not present. But the dependency was present during the initial install and then later removed. So the dependency was gone during repair but the repair still tries to fix the component with the dependency and fails. Any way around 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
Re: [WiX-users] DTF in WiX - LINQ Issue
Yes it's a bug, I can repro it. You can workaround it easily by including a
where clause in the query. Any where clause will do.
I wasn't intending to do a lot of work on the LINQ library right now, but this
one might be worth fixing... shouldn't be too hard I think.
-Jason-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Tuesday, May 20, 2008 10:33 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DTF in WiX - LINQ Issue
I'm trying to do my first custom action with a LINQ query with the below code.
However I'm getting an exception.I've stepped through the debugger and
what's wierd is that when var actions get assigned and proccessed it thinks
there is 6 selectColumns instead of 3. It then goes to build a query string
duplicating the columns like this:
SELECT `Property`, `Expression`, `Condition`, `Property`, `Expression`,
`Condition` FROM `Math`
I'm not sure if this is an SDK bug or if I'm consuming it incorrectly. If I
take out the lines that say Property, Expression, Condition I see 3
selectColumns but I still get the exception.
Exception thrown by custom action:
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.NullReferenceException: Object reference
not set to an instance of an object.
at Microsoft.Deployment.WindowsInstaller.Linq.Query`1.GetResult(Record
resultRec)
at
Microsoft.Deployment.WindowsInstaller.Linq.Query`1.InvokeQueryd__0.MoveNext()
at MGAM.Installer.CustomActions.LinqTest.ProcessMath(Session session)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object
arguments, SignatureStruct sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object
arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle
typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32
sessionHandle, String entryPoint, Int64 remotingDelegatePtr)
[CustomAction]
public static ActionResult ProcessMath( Session session )
{
QDatabase db = session.Database.AsQueryable();
var actions = from a in db[Math]
select new
{
Property = a[Property],
Expression = a[Expression],
Condition = a[Condition]
};
foreach (var a in actions)
{
Console.WriteLine(test);
}
-
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] DTF in WiX - LINQ Issue
Would you like me to log it?
Jason Ginchereau [EMAIL PROTECTED] wrote:Yes it's a bug, I
can repro it. You can workaround it easily by including a where clause in the
query. Any where clause will do.
I wasn't intending to do a lot of work on the LINQ library right now, but
this one might be worth fixing... shouldn't be too hard I think.
-Jason-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Tuesday, May 20, 2008 10:33 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DTF in WiX - LINQ Issue
I'm trying to do my first custom action with a LINQ query with the below
code. However I'm getting an exception.I've stepped through the debugger
and what's wierd is that when var actions get assigned and proccessed it thinks
there is 6 selectColumns instead of 3. It then goes to build a query string
duplicating the columns like this:
SELECT `Property`, `Expression`, `Condition`, `Property`, `Expression`,
`Condition` FROM `Math`
I'm not sure if this is an SDK bug or if I'm consuming it incorrectly. If I
take out the lines that say Property, Expression, Condition I see 3
selectColumns but I still get the exception.
Exception thrown by custom action:
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.NullReferenceException: Object reference
not set to an instance of an object.
at Microsoft.Deployment.WindowsInstaller.Linq.Query`1.GetResult(Record
resultRec)
at
Microsoft.Deployment.WindowsInstaller.Linq.Query`1.InvokeQueryd__0.MoveNext()
at MGAM.Installer.CustomActions.LinqTest.ProcessMath(Session session)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object
arguments, SignatureStruct sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object
arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle
typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32
sessionHandle, String entryPoint, Int64 remotingDelegatePtr)
[CustomAction]
public static ActionResult ProcessMath( Session session )
{
QDatabase db = session.Database.AsQueryable();
var actions = from a in db[Math]
select new
{
Property = a[Property],
Expression = a[Expression],
Condition = a[Condition]
};
foreach (var a in actions)
{
Console.WriteLine(test);
}
-
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] DTF in MSBuild
I wanted to keep this abstracted and loosely coupled. It's all prototype/play
work right now and I don't want to add dependencies to the build box that I
can't resolve by just pulling some third party components out of source.
I'm sure when the day comes that wix3.msi has all the right bits deployed to
the right locations with official project templates with proper msbuild support
then I'll change my implementation and incorporate that pattern instead. It's
just simple and expediant for now.
Christopher Karper [EMAIL PROTECTED] wrote:
It looks like you're copying in all the DTF support files into a subdir as
well. I was trying to just use the preinstalled locs.
To each their own. It'd be pretty easy to make an msbuild action out of
MakeSfxCA since it's all managed code anyway. I'm sure it'll come along soon
enough.
Chris
On Tue, May 20, 2008 at 5:58 PM, Christopher Painter [EMAIL PROTECTED]
wrote:
I took the lazy way out for now with a postbuild event since Jason has said
proper templates will be coming. I decided to add DTF to the filename for
uniqueness. My goal was to isolate the dependencies and wire it up as a
standard C# class project without any particularly special plumbing.
$(ProjectDir)SDK\MakeSfxCA.exe $(TargetDir)$(TargetName).DTF.dll
$(ProjectDir)SDK\sfxca.dll $(TargetPath)
$(ProjectDir)SDK\Microsoft.Deployment.WindowsInstaller.dll
$(ProjectDir)ExternalAssemblies\AxLibrary.dll
I also wrote a few blogs on the topic if you are interested. ( Can you tell,
I REALLY like DTF )
http://blog.deploymentengineering.com/2008/05/price-of-ideology-and-great-new-hope.html
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
http://blog.deploymentengineering.com/2008/05/data-driven-cas-made-easy-with-dtf.html
Christopher Karper [EMAIL PROTECTED] wrote:
Oh yeah, also note, this depends on you having a file named
CustomAction.config in your project. I great improvement would be to have it
check for the file's existence before including it. :-)
YMMV.
Chris
On Tue, May 20, 2008 at 5:49 PM, Christopher Karper [EMAIL PROTECTED] wrote:
I've got the DTF wrapper bit running as a simple exec task by adding the
following to the end of my project file for the CA dll.
It uses the project output and appends an _Sfx to it to mark it as the wrapped
version. It's brute force, and it steals from the wix.targets file
Pay special attention to the DTFBin Property. you can find a better way to
populate it, or just change it to point to your installation. I had to build
the DTF myself and disable a bunch of the signing to get this to work, since
MakeSfxCA.exe wasn't included in the binary distro for this release.
It's uglybut hey, if someone wants to use it/improve it, be my guest.
Chris
Target Name=AfterBuild
CallTarget Targets=MakeSfxCA /
/Target
!--
From the Wix.targets file - CMK
Several properties must be set in the main project file, before using this
.targets file.
However, if the properties are not set, we pick some defaults.
--
PropertyGroup
!-- Not a good way, but it works for me. This should use registry
search, the same way the wix.targets does --
DTFBinc:\Program Files (x86)\Windows Installer XML v3\sdk\/DTFBin
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
Platform Condition= '$(Platform)'=='' AnyCPU/Platform
OutputPath Condition= '$(OutputPath)' == ''
bin\$(Configuration)\/OutputPath
!-- Ensure any OutputPath has a trailing slash, so it can be
concatenated --
OutputPath Condition= '$(OutputPath)' != '' and
!HasTrailingSlash('$(OutputPath)') $(OutputPath)\/OutputPath
_OriginalOutputType$(OutputType)/_OriginalOutputType
OutputType Condition= '$(OutputType)' == '' Library/OutputType
/PropertyGroup
PropertyGroup
!-- Example, bin\Debug\ --
OutDir Condition= '$(OutDir)' == '' $(OutputPath)/OutDir
!-- Ensure OutDir has a trailing slash, so it can be concatenated --
OutDir Condition= '$(OutDir)' != '' and
!HasTrailingSlash('$(OutDir)') $(OutDir)\/OutDir
!-- Example, MyCA --
ProjectName Condition= '$(ProjectName)' == ''
$(MSBuildProjectName)/ProjectName
!-- Example, MyCA.csproj --
ProjectFileName Condition= '$(ProjectFileName)' == ''
$(MSBuildProjectFile)/ProjectFileName
!-- Example, .csproj --
ProjectExt Condition= '$(ProjectExt)' == ''
$(MSBuildProjectExtension)/ProjectExt
!-- Example, c:\MyProjects\MyCA\ --
ProjectDir Condition= '$(ProjectDir)' == ''
$(MSBuildProjectDirectory)\/ProjectDir
!-- Example, c:\MyProjects\MyCA\MyCA.csproj --
ProjectPath Condition= '$(ProjectPath)' == ''
$(ProjectDir)$(ProjectFileName)/ProjectPath
!-- Example, MyCA --
TargetName
[WiX-users] WIX property
Hi, I am new to the list and just subscribed a few days back, The command line specified :msiexec /qn /i setup.msi [EMAIL PROTECTED] I wish to check if the user had specifed the PASSWORD property or not? Is there any way to find out ? ~Regards Pradnya - 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
