[WiX-users] Новинка!
Новейшие базы данных. Внешнеэкономическая деятельность 1999-2008 гг РФ и Украины . Юридические лица и предприятия Москвы и РФ по 2008 г . ( регистрационные и фактические данные ) 3000 руб . Банковские переводы ( данные РКЦ ЦБ ) 6000 руб . Физические лица Москвы и Московской области ( телефоны , прописка , собственность , паспорта ) по 2007 г 2000 руб . ГАИ Москвы и Московской области ( данные по автомобилям и владельцам , водительским удостоверениям , ДТП , ПДД и др .) по 2007 г 2000 руб . Пенсионный фонд ( данные о работодателе , месте работы , месте жительства , доходе ) 2000 руб . Антикриминал ( полный сборник по криминальной тематике ) по 2007 г . 3 000 руб . Регионы России ( физ . лица , ГАИ городов России ). 4000 руб . Стоимость полного комплекта - 15000руб. Наш телефон для связи: /495/ 961 5 867 - 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] WiX 3 CustomActions in Fragments
Hi, How does one go about placing CustomActions in a fragment (separate file) and then include them at build time? I¹ve tried creating the following 2 files with a reference to the Fragment file 1) installer.wxs * WiXProduct..FragmentRef Id=CAs /./Product/Wix 2) custom_actions.wxs * Fragment Id=CAsCustomAction/Fragment Candle gives the following error: ...build\installer.wxs(32) : error CNDL0005 : The Product element contains an unexpected child element 'FragmentRef'. This works fine for a UIRef to a Fragment file, which makes this issue a bit difficult to understand. Using WiX 3.0.2925.0 Thanks, Alex G. - 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] WiX 3 CustomActions in Fragments
I believe that you can define the CA's in a separate fragment, then just schedule them in the main file and they will get included. http://www.clearviewecm.com/ The information contained in this email is privileged and confidential and is intended solely for the addressee(s). If you are not the intended recipient, please respond to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] then delete this email from your system. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Goryuk Sent: Monday, May 19, 2008 9:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 3 CustomActions in Fragments Hi, How does one go about placing CustomActions in a fragment (separate file) and then include them at build time? I've tried creating the following 2 files with a reference to the Fragment file 1) installer.wxs * WiXProduct..FragmentRef Id=CAs /./Product/Wix 2) custom_actions.wxs * Fragment Id=CAsCustomAction/Fragment Candle gives the following error: ...build\installer.wxs(32) : error CNDL0005 : The Product element contains an unexpected child element 'FragmentRef'. This works fine for a UIRef to a Fragment file, which makes this issue a bit difficult to understand. Using WiX 3.0.2925.0 Thanks, Alex G. image001.png- 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 website only if doesn't exist
Hello If we put iis:WebVirtualDir under website nested in Product tag, the virtual directory will be created under existsing website. If website is nested under Component tag, new website will be created. My question is how to create website only if given website doesn't exist? Regards, Michael - 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
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. -Jason- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Friday, May 16, 2008 11:42 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I also pulled the sources but I can't get the Compression.Cab project in the DTF solution to build. It's missing the file Errors.resources.resources file. If I exclude it from the project it seems to build fine though. Christopher Painter [EMAIL PROTECTED] wrote: 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 - 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
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 with, these patches can be applied more or less in any order. Currently, these patches are built using the NullSoft installer. As a first step, I'd like to get rid of NullSoft, and replace it with WiX; on the long run, a full transition to WiX could be an interesting option. I don't understand how I can use MSI's own patching support: it seems to impose a linear evolution of the product, with a well defined sequence of applying patches - and by all means, do correct me if I'm wrong. My first impulse is to integrate something like tallow/paraffin in the patch build system, and generate service packs as standalone installers with 1 component/file (performance of patches is not really critical, they are quite small). Coupled with Installshield's dynamic linking, this is bound to break the component rules in a systematic manner. Also, there's the open issue of uninstalling these patches when the main product is uninstalled. Can you provide some pointers on the best way to proceed ? Thank you ! -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor 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 - 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
I'm working on a sample for my blog right now. In doing so, I've noticed something. It seems that session.Log() method automatically formats the text. For example I want to do something like // Property A = 21 // Property B = 2 string expression = [A]*[B]; //Really comes from table data session.Log( MyCA: Found Expression: + expression ); string formattedExpression = session.Format( expression ); session.Log (MyCa: Expression Formats as: + formattedExpression ); But when I look at my logfile, both lines say 21*2 instead of [A]*[B] and 21*2. Make sense? I'm wondering if there is a way to log the data found without formatting it. 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. -Jason- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Friday, May 16, 2008 11:42 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I also pulled the sources but I can't get the Compression.Cab project in the DTF solution to build. It's missing the file Errors.resources.resources file. If I exclude it from the project it seems to build fine though. Christopher Painter [EMAIL PROTECTED] wrote: 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.
Re: [WiX-users] DigitalCertificate Element
Albert Shamsiyan wrote: Thanks for the prompt response Adam. So basically I should point the [EMAIL PROTECTED] element to the public key (spc file) representing my company signatures? If that's so, Is it possible to extract it from already signed file? If so how? You probably have to point it at the private key, otherwise there wouldn't be a lot of point - a public key isn't any use except for verification of a signature on a file.. it's public (hence the name) thus confers zero security on its own. It goes without saying that the private key is not in the signed file. Tony - 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
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 with, these patches can be applied more or less in any order. Currently, these patches are built using the NullSoft installer. As a first step, I'd like to get rid of NullSoft, and replace it with WiX; on the long run, a full transition to WiX could be an interesting option. I don't understand how I can use MSI's own patching support: it seems to impose a linear evolution of the product, with a well defined sequence of applying patches - and by all means, do correct me if I'm wrong. My first impulse is to integrate something like tallow/paraffin in the patch build system, and generate service packs as standalone installers with 1 component/file (performance of patches is not really critical, they are quite small). Coupled with Installshield's dynamic linking, this is bound to break the component rules in a systematic manner. Also, there's the open issue of uninstalling these patches when the main product is uninstalled. Can you provide some pointers on the best way to proceed ? Thank you ! -- Stelian ENE Installer Engineer, DevTech Freescale Semiconductor 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 - 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
Re: [WiX-users] Installing .NET 3.5 redist?
Neil, why does a bootstrapper mean you have to give up control? The latest version of Office uses a bootstrapper to install a great many MSI packages to actually take back complete control of the installation experience (for example, one progress bar with no resets). It has extremely consistent look and feel. Granted it took them a lot of work to accomplish that but you should be able to get the same sort of experience. The fundamental fact is that many installs are moving toward multi-package installs. There are a number of reasons for it but the big ones come down to the limitations around patching redistributables (i.e. lack of Merge Module patching support) and multi-lingual installations. The problem for us on the WiX toolset is that I'm 2 years behind execution on the bootstrapper platform I wanted in the WiX toolset. I saw the need a long time ago when I created the silly little bootstrapper that is part of the WiX toolset today but we need something far more feature rich than that. Fortunately, Fredrik (of MSMQ and COM+ fame) is working on it and based on his previous work, I'm pretty confident it will provide a great starting point... when he gets done. Finally, there is no WiX philosophy about the way you should handle your dependencies. The WiX toolset should allow you to handle your dependencies how you wish. Eventually, I hope we have an out of box experience for those that desire (or need to handle) a multi-package experience. Right now, you just have to write a lot more code (or use some other existing bootstrapper) to get multi-package scenarios. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Sunday, May 18, 2008 18:27 To: Adam Majer; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing .NET 3.5 redist? The problem with option 1 is that it means we have to give up control of the end-to-end install and out of box experience for our product. When you are trying to construct a carefully designed user experience and impression of your application, a bootstrapper is a pretty fugly addition to the mix. Contrast that with our DirectX 9.0 install, which we can seamlessly fold into our installer with no need for intervention by the user. I'm sure there are plenty of reasons why the .NET team had to go with the distribution solution they did. It just means our final experience winds up being less than we'd hoped. Ah well. Neil From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Majer [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 6:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing .NET 3.5 redist? Christopher Painter wrote: The WiX `philosophy` seems to be don't add .NET dependencies to your install and don't redist the framework.Just do an AppSearch/Launch Condition and tell the user to go do it on their own. Personally this conflicts with my needs and results in one of the many reasons why I can't use WiX even though I'd like to. The limitation is with Windows Installer, *not* WiX. The correct way of doing this is either, 1. a bootstrapper that will check for MSI and install it if needed, or 2. just ship your MSI with the requirement condition and let the destination deal with installing .NET 3.5. For corporate deployments, #2 is probably best while option #1 is better for the home user. MSI is just a single-transaction-at-a-time installer. It is not like Debian's APT that can install dozens if not more dependencies for you at the same time as it installs or upgrades hundreds of other applications. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - 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] 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. -Jason- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Friday, May 16, 2008 11:42 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I also pulled the sources but I can't get the Compression.Cab project in the DTF solution to build. It's missing the file Errors.resources.resources file. If I exclude it from the project it seems to build fine though. Christopher Painter [EMAIL PROTECTED] wrote: 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 - This
Re: [WiX-users] Installing .NET 3.5 redist?
It's rather ironic that the Microsoft folks, including the .NET team, are just like us. In the case of (say) the 3.0 .NET FW they have something like 5 MSIs to install, consequently they have a bootstrapper to tie them together. So they don't really treat their product as a redist but rather as an actual product. I'm not complaining, just finding it interesting that we all have the same problems to solve. VS 2008 SP1 is similar. There are reasons to keep these setups separate from yours, mainly the requirement for admin rights to install them which may not be the case with your app install. It's not really all that safe for your own bootstrapper to check for Windows Installer because you don't know the minimum required level. You could insist on 3.0 perhaps, but you won't know what you need unless you look at all the embedded MSI files to see what they want. Also, one version of the .NET FW shipped with an embedded update to the MSI engine, obviously something that needs installing first, so unless we can guarantee that they'll never do that again it rules out thinking about attempts to run a .NET FW install from a running MSI (leaving aside the other issues). Even in MSI 4.5 and a multi-MSI transaction I wouldn't like to reboot half-way through to restart where we left off to update the MSI engine (and I don't know what 4.5 does in this situation). Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Sunday, May 18, 2008 6:27 PM To: Adam Majer; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing .NET 3.5 redist? The problem with option 1 is that it means we have to give up control of the end-to-end install and out of box experience for our product. When you are trying to construct a carefully designed user experience and impression of your application, a bootstrapper is a pretty fugly addition to the mix. Contrast that with our DirectX 9.0 install, which we can seamlessly fold into our installer with no need for intervention by the user. I'm sure there are plenty of reasons why the .NET team had to go with the distribution solution they did. It just means our final experience winds up being less than we'd hoped. Ah well. Neil From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Majer [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 6:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing .NET 3.5 redist? Christopher Painter wrote: The WiX `philosophy` seems to be don't add .NET dependencies to your install and don't redist the framework.Just do an AppSearch/Launch Condition and tell the user to go do it on their own. Personally this conflicts with my needs and results in one of the many reasons why I can't use WiX even though I'd like to. The limitation is with Windows Installer, *not* WiX. The correct way of doing this is either, 1. a bootstrapper that will check for MSI and install it if needed, or 2. just ship your MSI with the requirement condition and let the destination deal with installing .NET 3.5. For corporate deployments, #2 is probably best while option #1 is better for the home user. MSI is just a single-transaction-at-a-time installer. It is not like Debian's APT that can install dozens if not more dependencies for you at the same time as it installs or upgrades hundreds of other applications. - Adam -- Mail Etiquette == * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC - 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] Registering a dll in Vista
Well, the most robust way to solve the problem is to add the COM registration to your setup authoring. If you provide the appropriate Class, ProgId, TypeLib, and Registry elements in your setup then things should work very well under UAC. Heat (on non-Vista Oss) usually does a pretty good job grabbing the appropriate registration automatically but it certainly does miss some things (there are a number of bugs opened on heat right now about that). There is also a way to have your DLL SelfReg called during install but that has a lot of issues as documented in the MSI SDK. -Original Message- From: Colin Bleckner [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 11:23 To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Registering a dll in Vista I have a fairly simple installation process. I copy a couple of files into a Program Files directory (one of which is a DLL file) and then set the keys needed to register that DLL. I'm using a custom UI, which is just 3 dialogs: a welcome to the installer dialog, the actual installation dialog, and a installation complete dialog. My MSI opens without triggering anything. But clicking my Install button, which starts the actual installation, triggers a UAC message. I tell Vista to allow the operation to continue and my installation continues, appearing to work. The files are put in the right place and it looks like the registry keys are set correctly. However, my DLL is not registered correctly. Also: if I try to manually register the DLL file using regsvr32 (without elevated permissions) I get an access denied error (error code 0x80070005). I'd love to make my installation work with UAC, but, more importantly, I don't want my installer to appear to work and not actually work. I'm reading through the links in Brian's reply right now, but are there any easy answers for this? Colin Rob Mensching wrote: 0. Yeah, capturing SelfReg has turned out to be a pretty tricky process. There are a lot of crazy SelfReg routines out there. smile/ 1. There isn't currently an owner working on heat.exe so the development stalled out when Derek moved on. That makes it a real hit or miss tool. 2. Please do open a bug about heat not warning that it doesn't work well on Vista. That is a very good idea until/if we can fix all the open bugs about heat on Vista. 3. Can you provide more details about what does not work when you install on Vista with UAC? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Bleckner Sent: Thursday, May 15, 2008 23:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registering a dll in Vista Wow, this has been a long two days in WiX world. I've been trying to register a single DLL with WiX. I started by using heat to capture all the registry keys set by my DLL. (Feature request: it would be AWESOME if heat.exe returned some sort of error message in Vista telling me that even though it's generating valid output, it's not actually generating the correct set of registry keys. After a day of beating my head against a wall I happened to stumble across a wixwiki page that mentioned that heat doesn't work 100% correctly in Vista. Fantastic.) Anyway, I ran heat on XP and got a more complete looking set of registry keys. But my installer STILL didn't register my DLL on a fresh Vista install correctly. I just finally discovered that if I turn off Vista's UAC first my installer works correctly. Is that expected? Is there anything I can do to avoid this? Or at the very least a condition I can set to prevent a seemingly valid install happen? Sorry for sounding a little rantish, it's been a long couple days... :) Colin - 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] Bootstrapper Guidence
I need to create a bootstrapper that will both download/inslall .NET Framework 2.0 and launch my MSI setup properly for minor upgrades. So far I've created a setup.exe with Bootstrapper Manifest Generator that handles the prereq very nicely, but not the minor upgrade. And from what i've seen, it looks like setupbld will properly handle the upgrade, but I don't see how to add prerequisites. Can someone get me pointed in the right direction on the best way to handle this? Thank you, -- steve - 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] Unexpected error while including merge Module
I am using Wix 3.0. when I try to merge in the Visual Studio 9.0 documentation integration merge modules, I receive this exception: d:\sa\drivers\mobilepc\auxdisplay\managedapi\setupsdk\light.exe : error LGHT0001 : Encountered an unexpected error while merging 'd:\sa.binaries.x86fre\SideShow\API\Docs\HTML_Help_Registration__RTL_---_---.msm'. More information about the merge and the failure can be found in the merge log: 'd:\sa.obj.x86fre\drivers\mobilepc\auxdisplay\managedapi\setupsdk\objfre\i386\-zslkxtz\merge.log' Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Binder.MergeModules(String tempDatabaseFile, Output output, FileRowCollection fileRows, StringCollection suppressedTableNames) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) has anyone seen this before? Any suggestions on how to proceed? Thanks.. --Doug - 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] Comparing result of a dword RegistrySearch to a number?
Ok, there's gotta be something obvious I'm missing here. How do I compare the result of a RegistrySearch for a dword against a number? I need to make sure the number returned is greater than or equal to 1, but it has the pesky # in front of it so a straight MYVARIABLE = 1 in the condition fails. Thanks, Neil - 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] Comparing result of a dword RegistrySearch to a number?
Assuming TESTPROP as the property assigned by Appsearch, try: TESTPROP and Not TESTPROP=#0 This should make sure that the property has data and that it isn't 0. Due to the nature of dwords, this should work. Neil Enns [EMAIL PROTECTED] wrote: Ok, theres gotta be something obvious Im missing here. How do I compare the result of a RegistrySearch for a dword against a number? I need to make sure the number returned is greater than or equal to 1, but it has the pesky # in front of it so a straight MYVARIABLE = 1 in the condition fails. Thanks, Neil - 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] Comparing result of a dword RegistrySearch to a number?
I guess that'll work, but wow, there's no way to do an integer greater than? Neil From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 2:51 PM To: Neil Enns; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Comparing result of a dword RegistrySearch to a number? Assuming TESTPROP as the property assigned by Appsearch, try: TESTPROP and Not TESTPROP=#0 This should make sure that the property has data and that it isn't 0. Due to the nature of dwords, this should work. Neil Enns [EMAIL PROTECTED] wrote: Ok, there's gotta be something obvious I'm missing here. How do I compare the result of a RegistrySearch for a dword against a number? I need to make sure the number returned is greater than or equal to 1, but it has the pesky # in front of it so a straight MYVARIABLE = 1 in the condition fails. Thanks, Neil - 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] Comparing result of a dword RegistrySearch to a number?
You can try this also: ( literals wrapped in quotes TESTPROP#0 ( Might have to do some XML escaping ) I seem to recall something about strange unexpected behavior on the comparisons but it's escaping me what it was at the moment if it exists at all. Neil Enns [EMAIL PROTECTED] wrote: I guess thatll work, but wow, theres no way to do an integer greater than? Neil From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2008 2:51 PM To: Neil Enns; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Comparing result of a dword RegistrySearch to a number? Assuming TESTPROP as the property assigned by Appsearch, try: TESTPROP and Not TESTPROP=#0 This should make sure that the property has data and that it isn't 0. Due to the nature of dwords, this should work. Neil Enns [EMAIL PROTECTED] wrote: Ok, theres gotta be something obvious Im missing here. How do I compare the result of a RegistrySearch for a dword against a number? I need to make sure the number returned is greater than or equal to 1, but it has the pesky # in front of it so a straight MYVARIABLE = 1 in the condition fails. Thanks, Neil - 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] finding .net 3.5 or greater
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] 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. -Jason- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Friday, May 16, 2008 11:42 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DTF in WiX I also pulled the sources but I can't get the Compression.Cab project in the DTF solution to build. It's missing the file Errors.resources.resources file. If I exclude it from the project it seems to build fine though. Christopher Painter [EMAIL PROTECTED] wrote: I'm
Re: [WiX-users] finding .net 3.5 or greater
You can use the NetFxExtension that comes with WiX. http://www.wixwiki.com/index.php?title=NetFxExtension. Add -ext WixNetFxExtension to both candle.exe and light.exe, then you can add a PropertyRef to NETFRAMEWORK35. There's an example on the above page of how it all works. Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta (Volt) Sent: Monday, May 19, 2008 3:27 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] finding .net 3.5 or greater 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] DTF in WiX
Cool, it's ok, it was a good learning excercise. I've only been doing .NET for a couple years on the side so it's good to keep me on my toes. How useful is LINQ?Hehehe, your joking right?Do you have any idea how many times I've felt like blowing my brains out over the years after yet another vbscript 1720 error because I didn't properly escape some MSI SQL statement? As an aside I was working on a project a year ago that I never finished... a System.Data.Common DBProvider for MSI. I'm now wondering how I could use MSI LINQ in the tools space to write visualization utilities like Orca. I know how to do it ADO.NET style but I don't know what I would use here. Thanks for the Session-QDatabase tip. I'll work on that and the subclassing and see what I can put together. Wicked cool... this is the best interop I've seen yet for MSI and I've looked over quite a few of them in the last couple of years. Jason Ginchereau [EMAIL PROTECTED] wrote: 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
Re: [WiX-users] finding .net 3.5 or greater
I already use NETFRAMEWORK35 to determine if .net 3.5 is on the machine... what I'm really concerned with is the greater than part. How do you test against the condition greater than or equal to 3.5 From: Neil Enns Sent: Monday, May 19, 2008 3:38 PM To: Don Tasanasanta (Volt); wix-users@lists.sourceforge.net Subject: RE: finding .net 3.5 or greater You can use the NetFxExtension that comes with WiX. http://www.wixwiki.com/index.php?title=NetFxExtension. Add -ext WixNetFxExtension to both candle.exe and light.exe, then you can add a PropertyRef to NETFRAMEWORK35. There's an example on the above page of how it all works. Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta (Volt) Sent: Monday, May 19, 2008 3:27 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] finding .net 3.5 or greater 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
[WiX-users] Catching FilesInUse condition during quiet mode upgrade
From my understanding of the documentation here http://msdn.microsoft.com/en-us/library/aa369546(VS.85).aspx If you are doing a quiet install or haven't defined a filesinuse dialog with the appropriate controls, the default behaviour is equivalent to selecting ignore. That is, windows installer overwrites what files it can, renames and replaces other files, and schedules a reboot. What I am aiming to do is instead just fail and exit the installation immediately. I have conceived a few ways to get around this but I'm not sure if some are even feasable. The most straightforward that I can think of is to bump up a UILevel or two and define my own filesinuse dialog with only an exit ControlEvent defined. If I could make it hidden and apply the action immediately that would be awesome. Alternatively I could create a CA that rolled back the upgrade conditionally depending upon ReplacedInUseFiles. I think this might be set too late in the sequence though, and I'm not sure how I'd do the rollback anyway. Third catch INSTALLMESSAGE_FILESINUSE directly and return an error somehow, which seems very un-Wixy. Any help appreciated, Tim - 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
It's kind of difficult to test against a future unkown framework because they sit side by side and a newer release doesn't always entail a release of the CLR.If you care about the CLR version, you could check the FileVersion of System32\mscoree.dll. Other then that, if a BCL extension called 3.6 was to get released, I don't know that there is a good way to detect it without first knowing what it would be called. Maybe I'm missing something that could make this problem easier to solve. Don Tasanasanta (Volt) [EMAIL PROTECTED] wrote: I already use NETFRAMEWORK35 to determine if .net 3.5 is on the machine what Im really concerned with is the greater than part. How do you test against the condition greater than or equal to 3.5 From: Neil Enns Sent: Monday, May 19, 2008 3:38 PM To: Don Tasanasanta (Volt); wix-users@lists.sourceforge.net Subject: RE: finding .net 3.5 or greater You can use the NetFxExtension that comes with WiX. http://www.wixwiki.com/index.php?title=NetFxExtension. Add ext WixNetFxExtension to both candle.exe and light.exe, then you can add a PropertyRef to NETFRAMEWORK35. Theres an example on the above page of how it all works. Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta (Volt) Sent: Monday, May 19, 2008 3:27 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] finding .net 3.5 or greater 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 - 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
The Session.Log() method passes the message string to to
MsiProcessMessagehttp://msdn.microsoft.com/en-us/library/aa370354.aspx as the
format-string (field 0) of a Record, so it gets automatically formatted there.
To avoid that behavior, you can do something like this:
using (Record rec = new Record(1))
{
rec.FormatString = [1];
rec[1] = msg;
session.Message(InstallMessage.Info, rec);
}
Or you can escape the
bracketshttp://msdn.microsoft.com/en-us/library/aa368609.aspx like this:
session.Log(@[\[]Not a property[\]]);
From: Christopher Painter [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 8:37 AM
To: Jason Ginchereau; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] DTF in WiX
I'm working on a sample for my blog right now. In doing so, I've noticed
something. It seems that session.Log() method automatically formats the text.
For example I want to do something like
// Property A = 21
// Property B = 2
string expression = [A]*[B]; //Really comes from table data
session.Log( MyCA: Found Expression: + expression );
string formattedExpression = session.Format( expression );
session.Log (MyCa: Expression Formats as: + formattedExpression );
But when I look at my logfile, both lines say 21*2 instead of [A]*[B] and 21*2.
Make sense? I'm wondering if there is a way to log the data found without
formatting it.
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.
-Jason-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Friday, May 16, 2008 11:42 AM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] DTF in WiX
I also pulled the sources but I can't get the Compression.Cab project in the
DTF solution to build. It's missing the file Errors.resources.resources file.
If I exclude it from the project it seems to build fine though.
Christopher Painter [EMAIL PROTECTED] wrote:
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.
Re: [WiX-users] DTF in WiX
Thanks. In my case I was trying to log table data queried before and after
formatting for debugging purposes. Do you think others might have a similar
need? If so, do you think an overload for Log to disable formatting could be a
good thing?
Jason Ginchereau [EMAIL PROTECTED] wrote:
The Session.Log() method passes the message string to to
MsiProcessMessage as the format-string (field 0) of a Record, so it gets
automatically formatted there. To avoid that behavior, you can do something
like this:
using (Record rec = new Record(1))
{
rec.FormatString = [1];
rec[1] = msg;
session.Message(InstallMessage.Info, rec);
}
Or you can escape the brackets like this:
session.Log(@[\[]Not a property[\]]);
From: Christopher Painter [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 8:37 AM
To: Jason Ginchereau; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] DTF in WiX
I'm working on a sample for my blog right now. In doing so, I've noticed
something. It seems that session.Log() method automatically formats the text.
For example I want to do something like
// Property A = 21
// Property B = 2
string expression = [A]*[B]; //Really comes from table data
session.Log( MyCA: Found Expression: + expression );
string formattedExpression = session.Format( expression );
session.Log (MyCa: Expression Formats as: + formattedExpression );
But when I look at my logfile, both lines say 21*2 instead of [A]*[B] and
21*2.
Make sense? I'm wondering if there is a way to log the data found without
formatting it.
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.
-Jason-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Painter
Sent: Friday, May 16, 2008 11:42 AM
To: [EMAIL PROTECTED];
Re: [WiX-users] Bootstrapper Guidence
We've settled on dotNetInstaller - http://www.devage.com/Wiki/ViewArticle.aspx?name=dotnetinstallerversion =0. Works well. I also have developers adding some small features to it (mixed-mode download, 64bit), silent install. Cheers dB. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Payne Sent: Monday, May 19, 2008 4:10 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bootstrapper Guidence I need to create a bootstrapper that will both download/inslall .NET Framework 2.0 and launch my MSI setup properly for minor upgrades. So far I've created a setup.exe with Bootstrapper Manifest Generator that handles the prereq very nicely, but not the minor upgrade. And from what i've seen, it looks like setupbld will properly handle the upgrade, but I don't see how to add prerequisites. Can someone get me pointed in the right direction on the best way to handle this? Thank you, -- steve - 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
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 help repro / debug, I'd be happy to do so, assuming it's within my capabilities or relatively close to them. Kelly Rob Mensching [EMAIL PROTECTED] 05/14/2008 11:52 PM To Kelly Leahy [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Subject RE: [WiX-users] really slow using pyro 0. I assume you’ve tried passing the “-v” switch for verbose? (I’m
Re: [WiX-users] Running an action *after* rebooting
Another way is to install your utility with the msi, write a RunOnce registry key with the command for the utility and then ScheduleReboot. A dialog explaining the need to reboot to finish is nicer than ForceReboot -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Friday, May 16, 2008 9:17 AM To: Richard Amos Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Running an action *after* rebooting Richard Amos wrote: I'd like to launch a configuration utility *after* a ScheduleReboot, but, as the ScheduleReboot doesn't have an ID, how to I tell the custom action that launches the utility to run *after* the reboot? ScheduleReboot schedules a reboot after the setup completes; the setup doesn't start back up after reboot. To do that, use ForceReboot (and be prepared for irate users). -- 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
Re: [WiX-users] How to let other user can find my program in ARP on Vista?
Thank YOU, Phil! Base on your information, I set ALLUSERS and it work well. Your solution is what I need. Akibo. Wilson, Phil wrote: You might not have done the installation with the ALLUSERS setting that does a per-machine install, so you did a per-user install that only you (the installing account) can see. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Akibo Sent: Thursday, May 15, 2008 5:54 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to let other user can find my program in ARP on Vista? Hello, I install my program with account A, and can see my product name in uninstall program on Vista. But account B cannot see this product name in his control panel/uninstall program. Both account are in administrators group. I check HKLM\\Uninstall. I saw my product key are in HKLM\\Uninstall\\[GID] but not exist in HKLM\\Uninstall. I saw most other application have a registry - HKLM\\Uninstall\\[APP] and put product name in this folder. Is that root cause? Whether yes or no, how to resolve it with wix? Will be appreciate for your kindly help. -- View this message in context: http://www.nabble.com/How-to-let-other-user-can-find-my-program-in-ARP-on-Vista--tp17252574p17252574.html Sent from the wix-users mailing list archive at Nabble.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 -- View this message in context: http://www.nabble.com/How-to-let-other-user-can-find-my-program-in-ARP-on-Vista--tp17252574p17331366.html Sent from the wix-users mailing list archive at Nabble.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
[WiX-users] Interest in a MSI/MSP installer generator based on Wix
We have built and used a tool internally that provides a wrapper over Wix in MSI/MSP generation for over two years. Spikesource is in the business of building and packaging a large number of open source components (in the hundreds) and integrating them into application infrastructure stacks. On windows each of these open source components (e.g. apache, tomcat, jboss, mysql etc) are packaged into MSI files. These components can later be updated through MSP or MSI, so making sure the MSIs are built with component GUID tracking is an important feature in the tool. I wanted to send out a brief description of what the tool does (or intends to do, in some cases) and see if there would be interest in the Wix community for such a tool. We would like to open source our tool, if it would be useful to others. *Goal: * Make it extremely easy to build simple MSI based installers with built-in support for most common installation tasks. Support 80% of the typical installation tasks through a XML configuration file that does not require deep knowledge of windows installer technology. The tool will generate human readable and editable Wix source files, so for those 20% cases that are outside the scope of the tool, there should be enough Wix code generation to be a good starting point for customization. If this sounds interesting, please read on :) *Inputs:* (required ones, there will be a few additional optional ones) 1. Product name 2. Source directories (supports multiple sources) where the deployment files are 3. An XML document that specifies configuration information about MSI installation features. *Outputs: * 1. MSI or MSP (will have a few additional required inputs) 2. GUIDs ini file for tracking Component Rules 3. Wix Source Files that the user can edit for further customizations. *Installation Features Support: * 1. Create basic Windows Installers, with WixUI_InstallDir UI, i.e. wizard with Welcome, License Agreement, Installation Directory selection, Install Confirmation, Installation and Finish pages. 2. Branding support for customizing Start/Finish and Header banners. 3. MSP creation support - Pass the source paths to the previous and current versions of the product and in the configuration file identify the upgrade versioning info, the tool will generate temporary MSIs for each version and then merge them into an MSP using MsiMsp.exe 4. Package installation files from source directories with MSI Component GUID tracking support - Component GUID tracking is implemented by creating an entry in the ini file for each subdirectory traversed with a sub-directory path to GUID mapping the first time the tool is run for a product. This ini file should be under source control and subsequent MSI creation for the same product should make this ini file available to the tool. It will generate the MSI reading the GUIDs from the ini file. 5. Common Public MSI Property support - Create MSI properties for common public MSI properties such as ALLUSERS, ARPCOMMENTS, ARPREADME, ARPURLINFOABOUT etc based on configuration info provided. 6. Registry entry creation support - Create registry entries based on configuration info provided. 7. INI/Conf file generation support - Create ini file key-value pairs based on configuration info provided. 8. Shortcut creation support - Create short cuts based on configuration info provided. 9. Service Management support (install/uninstall/start/stop) 10. Custom Action support - callout to user defined executables, bat files etc at configurable points during installation sequence 11. COM DLL Registration support *Long Term:* Support UI code generation, possibly through a visual designer. The Wix source file generation is performed by substituting variables into Wix source templates, the values being extracted from the XML configuration file through XPath. The files source generation is by traversing the specified source directory, similar to tools like Tallow, but with Component GUID tracking. Currently the tool is built around the latest stable Wix 2.x build, this can later be upgraded to work with Wix 3.0 If the question is why another XML Schema to describe installation tasks on top of Wix, I see the Wix Schema as being a wrapper over MSI database tables and operations on them and requires the developer to know and understand the various tables, their columns and what the purpose of each of those are. The Schema in the tool, is more functional in nature, it captures the installation tasks the developer would like to perform through its elements and attributes and does not require the developer to know some of the windows installer complexities for simple installation scenarios. Sorry for the long post, if you have gotten here and feel such a tool would be useful to you, please let me know directly (no need to spam the list). I would
