[WiX-users] АРХИВНОЕ ЗАКОНОДАТЕЛЬСТВО
Семинар-практикум для работников кадровых служб 27 мая 2008 г. АРХИВНОЕ ЗАКОНОДАТЕЛЬСТВО: требования и порядок подготовки документов для сдачи в архив Тел для справок: (495) 66З-2I-59 С 10:00 до 17:00 1. Нормативно-правовое законодательство, регулирующее вопросы организации архивного дела в компании. -Федеральный закон от 22.10.2004 #8470; 125 #171;Об архивном деле в Российской Федерации#187;. -Смежное законодательство, регламентирующее вопросы архивного дела. 2. Ответственность должностных лиц нарушения архивного законодательства. -Ответственные должностные лица за соблюдение законодательства. -Санкции, налагаемые за нарушения в области архивного законодательства. 3. Порядок оформления документов в архив. -Порядок подготовки приказов по личному составу для сдачи документов в архив. -Номенклатура дел: задачи в организации работы с документами, порядок оформления. -Порядок формирования личного дела работника. 4. Организация работы архива юридического лица. -Виды архивов в зависимости от формы организации. -Документы, определяющие работу архива (Положение об архиве, должностные инструкции работников). -Взаимоотношения архива юридического лица с государственным архивом. -Требования к помещению и оборудованию архива. -Виды работ, выполняемые архивом (комплектование, учет) Стоимость участия: 5900 руб.+ НДС 18% В стоимость входит: обед, методические материалы, +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
Re: [WiX-users] Building localized versions of an installer
OK, that's good to know about what the various tools are designed to output. Unfortunately in this case calling torch on the wixmst file returns an error similar to the one light gave me: Ø Torch.exe en-us.wixmst -out en-us.mst C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje\File.idt : error TRCH0136 : There was an error importing table 'File' from this file. Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje'. Unbinder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje'. Torch temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\-2sfc210'. From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 8:13 PM To: Fairweather, James; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer Yeah, this is easy but the error message didn't help you (I've given it to Peter and he'll try to fix it tonight). light is for creating MSI/MSM files. torch is for creating MST files. pyro is for creating MSP files. Armed with that knowledge, hopefully it is clear that your final command-line should be torch en-us.wixmst. smile/ In the future, the error messages should point you in the right direction. From: Fairweather, James [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 15:08 To: Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer Thank-you , Rob and Josh. That looks like it should work, but it fails with a not-very-helpful error message: I have produced a .wixmst file from torch like so: Ø torch.exe -t language -v -p -xi -xo C:\eao neutral.wixout en-us.wixout -out en-us.wixmst Now call light on the wixmst file to create the transform: Ø light.exe en-us.wixmst Microsoft (R) Windows Installer Xml Linker version 3.0.3907.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w\File.idt : error LGHT0136 : There was an error importing table 'File' from this file. Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w'. Validator temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\ihybiq-8'. I will debug this further, but before I do, is there something obvious that I'm doing wrong? From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 2:01 PM To: Fairweather, James; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer You're right on track. Last step is to take the .wixout (should have been named .wixmsi to match the other things but .wixout came first) and feed it back into light.exe. Light will finish processing the .wixout into MSI. Is that detailed enough or am I missing a step? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fairweather, James Sent: Thursday, May 15, 2008 13:12 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Building localized versions of an installer Many of our companies' products are localized into several languages. To build the an installer to handle this, we first build a neutral MSI, then for each culture, we build an MSI, then use msitran to build a transform, and finally msidb to merge the transform back to the neutral MSI. This works, but it's really slow because of all the file copying and cabinet building. The fileset is the same for all cultures, so it would be really handy if there were a way to tell light to not build the cabinet file (after the first one). There is a -reusecab option, but it's still pretty slow (I think due to a lot of file copying), and it sometimes crashes on large filesets. The approach we are exploring is to use the XML format (-xo option to light), then use the torch tool to build the transform from that. While this is great from a speed point of view, I don't see a way of getting from the XML format back to MSI/MST. Am I missing something, or has that simply not been implemented to date? James Fairweather Lead developer and support engineer Core Team 604.456.3911 (x13911) http://eatech.ea.com/ image001.jpg- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 2-х комнатная квартира 25 000 Евро
НЕДВИЖИМОСТЬ В ЧЕХИИ ! ! ! Полный спектр услуг. Открытие фирмы от 980 Евро. Уникальное предложение 2-х комнатная квартира 25 000 Евро, г. Мост на границе с Германией. 3- х комнатная квартира в Праге 85 кв.м. 85 000 Евро - 15 минут до центра. Кредиты 15-25% первоначальный взнос, 5-7% годовых. Огромный выбор недвижимости в любой ценовой категории. С Уважением Дунаевский Дмитрий. Специалист компании Кредитный союз PDW, Praha. tel/fax +7 (495) 508 97 43 tel. mobil +7 (420) 774 414 593 http://dom.pd-web.cz e-mail: [EMAIL PROTECTED] ICQ: 453 319 803 Skype: PDW_Holding - 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] Temporary files in WiX?
There isn't anything built into the Windows Installer that supports temporary files during the install. Thus, you will need a Custom Action to manage the temporary files. If you're requiring these temporary files for consumption by a deferred Custom Action then you have to be very, very careful to avoid an elevation of privileges (because if the temporary files are placed in a location writable by the user they could be modified before being executed elevated). The WiX toolset doesn't currently have such a Custom Action but there is a new Custom Action coming in the next build that might be helpful. If you chose to write the Custom Action yourself, you can extra binary data out of the MSI (such as the Binary table) and marshal it over to a deferred Custom Action (in the CustomActionData property) and write it to a secure location before executing it. Another option, and the Custom Action that was just added tonight, is to create something of a self-extracting DLL that contains the deferred Custom Action and all of the temporary files. When the deferred Custom Action is executed it extracts the contained flies to a secure location and then does its thing and cleans up when done (or maybe later need the end of the InstallExecuteSequence). The new CA is called SfxCA but there isn't much documentation about using it by itself. Anyway, it isn't supported natively by MSI and the story isn't complete in the WiX toolset. A few people were asking about this same thing the other day so if you end up with a nice solution it might be a nice thing to add to the WiX toolset. Maybe just need to create a friendly extension on top of the SfxCA. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Thursday, May 15, 2008 15:37 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Temporary files in WiX? Is there such a thing as temporary files during a wix install? We're shipping some redist installers as part of our installer, and they only need to be on the end user's machine for the duration of install. What's the right way in WiX to indicate they're temporary and should be cleaned up after install is finished? 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] Problem with XMLConfig Element (empty xmlns attribute)
Hi Stefan, I had the same problem. A simple but unpretty solution I found was to add a second step to populate the empty namespace attribute. e.g. util:XmlConfig Id=oms.webconfig.stateserver File=[INSTALLLOCATION]web.config Action=create Node=element ElementPath=//configuration/system.web Name=sessionState On=install Sequence=1 / util:XmlConfig Id=oms.webconfig.stateserver File=[INSTALLLOCATION]web.config Action=create Node=value ElementPath=//configuration/system.web/sessionState Name=xmlns On=install Value=http://add-your-toplevel-schema-namespace-here; Sequence=2 / Which results in sessionState xmlns=http://add-your-toplevel-schema-namespace-here; / Like I said, definitely not pretty, but it does allow your document to be read in to memory by whatever consumes and validates your xml. Rod P Stefan Gauter wrote: When adding a new element to my web.config with XmlConfig I'll get an empty xmlns attribute. util:XmlConfig Id=oms.webconfig.stateserver File=[INSTALLLOCATION]web.config Action=create Node=element ElementPath=//configuration/system.web Name=sessionState On=install Sequence=1 / Resulting in: sessionState xmlns= / -- View this message in context: http://www.nabble.com/Problem-with-XMLConfig-Element-%28empty-xmlns-attribute%29-tp16747847p17274312.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
Re: [WiX-users] Temporary files in WiX?
While this is a great observation, I can't help question the severity of the concern since: 1) There are about a dozen easier ways to own a Windows box 2) The elevated installation story is hardly used out in the real world. It's certainly not used in the home space and in the corp space most shops either a) don't lock down their environments or b) push out their installs with elevated invocation through tools like SMS. #2 is evidenced by the fact ( sadly ) that most packages aren't even authored or tested to support the elevated story. Virtually nobody ( including Microsoft who's own VDPROJ generates Impersonated Deferred CA's ) bothered to care about the implications of the `saw tooth diagram` until UAC hit the streets and even then most people were just looking for a way to get around it or otherwise cope. So fine, document the risk and let the person consuming the resource know he should card against malicious code injection.But don't let that be a reason for failing to provide a capability that other tools have provided for years. Rob Mensching [EMAIL PROTECTED] wrote: There isnt anything built into the Windows Installer that supports temporary files during the install. Thus, you will need a Custom Action to manage the temporary files. If youre requiring these temporary files for consumption by a deferred Custom Action then you have to be very, very careful to avoid an elevation of privileges (because if the temporary files are placed in a location writable by the user they could be modified before being executed elevated). The WiX toolset doesnt currently have such a Custom Action but there is a new Custom Action coming in the next build that might be helpful. If you chose to write the Custom Action yourself, you can extra binary data out of the MSI (such as the Binary table) and marshal it over to a deferred Custom Action (in the CustomActionData property) and write it to a secure location before executing it. Another option, and the Custom Action that was just added tonight, is to create something of a self-extracting DLL that contains the deferred Custom Action and all of the temporary files. When the deferred Custom Action is executed it extracts the contained flies to a secure location and then does its thing and cleans up when done (or maybe later need the end of the InstallExecuteSequence). The new CA is called SfxCA but there isnt much documentation about using it by itself. Anyway, it isnt supported natively by MSI and the story isnt complete in the WiX toolset. A few people were asking about this same thing the other day so if you end up with a nice solution it might be a nice thing to add to the WiX toolset. Maybe just need to create a friendly extension on top of the SfxCA. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Thursday, May 15, 2008 15:37 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Temporary files in WiX? Is there such a thing as temporary files during a wix install? Were shipping some redist installers as part of our installer, and they only need to be on the end users machine for the duration of install. Whats the right way in WiX to indicate theyre temporary and should be cleaned up after install is finished? 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] Temporary files in WiX?
Thanks for the details, Rob. It sounds like from you write below that the security issue exists regardless of whether the files are temporary, correct? Any time you have an installer that writes files to a disk, then executes them via a deferred custom action, the vulnerability owuld be there? In our specific case, the files we're laying down on disk are the DirectX 9.0c redist files we need, then we execute them at the end of our setup. It sounds like some tweaks to SfxCA just might do the trick. Neil From: Rob Mensching Sent: Friday, May 16, 2008 2:36 AM To: Neil Enns; wix-users@lists.sourceforge.net Subject: RE: Temporary files in WiX? There isn’t anything built into the Windows Installer that supports temporary files during the install. Thus, you will need a Custom Action to manage the temporary files. If you’re requiring these temporary files for consumption by a deferred Custom Action then you have to be very, very careful to avoid an elevation of privileges (because if the temporary files are placed in a location writable by the user they could be modified before being executed elevated). The WiX toolset doesn’t currently have such a Custom Action but there is a new Custom Action coming in the next build that might be helpful. If you chose to write the Custom Action yourself, you can extra binary data out of the MSI (such as the Binary table) and marshal it over to a deferred Custom Action (in the CustomActionData property) and write it to a secure location before executing it. Another option, and the Custom Action that was just added tonight, is to create something of a “self-extracting DLL” that contains the deferred Custom Action and all of the temporary files. When the deferred Custom Action is executed it extracts the contained flies to a secure location and then does its thing and cleans up when done (or maybe later need the end of the InstallExecuteSequence). The new CA is called “SfxCA” but there isn’t much documentation about using it by itself. Anyway, it isn’t supported natively by MSI and the story isn’t complete in the WiX toolset. A few people were asking about this same thing the other day so if you end up with a nice solution it might be a nice thing to add to the WiX toolset. Maybe just need to create a friendly extension on top of the SfxCA. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Thursday, May 15, 2008 15:37 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Temporary files in WiX? Is there such a thing as temporary files during a wix install? We’re shipping some redist installers as part of our installer, and they only need to be on the end user’s machine for the duration of install. What’s the right way in WiX to indicate they’re temporary and should be cleaned up after install is finished? 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] Generate MSI during install
Check out the windows installer SDK there are api's to allow you to edit an MSI. I would suggest just creating the client MSI and then using a custom action to edit some properties during the server install. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Sayers Sent: Friday, May 16, 2008 9:06 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Generate MSI during install I'm doing some planning for moving from our existing xcopy based deployment to msi (hopefully with wix) based installs. Our application is written in .net framework 2.0 We have a client server that need to be deployed with separate MSI's. The server side of the application consists of a bunch of dll files and an IIS hosted remoting server. I'd love to be able to touch or generate the client MSI as part of the server installation, based on information entered by a network admin as part of the server MSI install. This way the client side of the application would already have server name, ip address, remoting endpoints written into it's config file and the end user woudln't need to enter that info as part of the client install. I'm new to Wix, but I have been lurking on this list for the last 6 months or so. Is this something i can do with Wix? Has anyone done something like this? Thanks Phil - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
I must say, you have all made my day. I've spent months banging my head and feeling like I'm not worth a damn despite all my non-deployment development experience. And worse, feeling like no one would understand why this installer is sucking up so many staff hours even if I tried my technical best to explain it! Now I feel validated. John McFayden does raise a good point in bringing up the perspective of the MSI user over that of the developers. I try to believe that even ridiculous-seeming things we encounter might actually have a very good reason behind them if we only knew the actual requirement that they were intended to fulfill. Yes, I know, 8.3 file names and such do not provide a compelling example of this in 2008. But it's still more likely that there is (or once was) a good reason for it than that there are a bunch of dunces writing the software we depend upon. Each trade-off made was probably well reasoned, and yet we still have MSI as we know it today. Who is to say that we would not have made the same decision at the time? As for writing the installer first (SDD), I think it is a good idea but impractical to most people's minds who aren't trained to think that way. (It's hard enough to get them to do TDD!) But I agree with Neil's (and Rob's) together we can make it happen thinking. Good practice suggests having a reasonable base infrustructure for development, CM, etc early on. So it should be with the MSI. After all the work my group has done to get my current project humming (albeit somewhat out of tune at times), I'd be very disappointed if my client did not end up distilling this work (especially this mysterious MSI thing) into a repeatable process for future use. Capitalize on the experience! Ultimately, there are usability concerns all over everything we've been discussing: The usability of MSI severely impacts the usability of WiX. Perhaps WiX can improve the usability of of MSI. Maybe a future version, or a layer on top of WiX will achieve that. Similarly, the process of developing software has usability issues. If you make it easy to consider the installer at the outset by making a canned build project that has a ready-to-go target for MSI-generation, it'll be that much easier. Much like refactoring support and easy-to-use continuous integration have been a significant enabler for agile development. But it takes time, research, and conversations like this to determine what that canned build project should provide. Votive and the MSBuild parts for WiX go a long way toward helping with this. I thank you all for the discussion, validation, and the continuing support! Raj From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Thursday, May 15, 2008 1:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] yep - back to being 100% frustrated I think we've covered the whole gambit of issues on this thread. I am going through all of them and will try to collect all the issues raised here and attempt to answer some the open questions over time. However, this particular comment made me chuckle: They solved the 8.3 filename issue in WiX V3.. I believe they can do more. Heh. They is *us*. You and you and you and you over there who doesn't talk much. This mailing list, this place where we talk about what we do with the WiX toolset and the Windows Installer, this is where we live. This is where we get work done. This is where we make the world a better place one line of code or one question answered or one piece of feedback at a time. You may think that's all flowery language or complete and utter bullshit but that is how I see what we (all of us) are doing here. We are a community built around using the WiX toolset and making it better. The WiX toolset isn't done. Nobody here is arguing that there isn't more that we can do to make the experience better. Just look at our bug list and you can see literally hundreds of places where we are *clearly* not done. IMHO, there is so much work to do the real question is about what gets done next. All I ask is that you remember that there are people here. We work on code, we talk about code, but this place is about people. I understand that the technology (both MSI and WiX) can be frustrating. Trust me, we all know that. I also appreciate that sometimes you just have to rant to get it out of your system. It's fine if you want to do that here (I always read rants about actual problems since they almost always point at some pain point we have yet to address). But don't make it personal. I can assure you that no one here is actively working to make your life harder. Instead, I encourage you to consider yourself a member of this community and frame your feedback such that it can help us improve the toolset or the community itself. Finally, I disagree with the sentiment that this thread was doomed from the beginning. Open
[WiX-users] checkbox didn't set an property
hello, i'd try to build an installer who had an checkbox. when it is set the property TESTDATA should be xyz. if it is not set TEXTDATA should be abc. Control Type=CheckBox Width=50 Height=17 X=145 Y=160 Id=Testdata Property=TESTDATA CheckBoxValue=xyz i also set an property Property Id=TESTDATAabc/Property so that i have an value if the checkbox is not set...but it didn't work. can anybody help me please? thanks a lot norbert - 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] Generate MSI during install
Thanks for the info. I'm sure this can be done. I'm trying to work out the best way to move forwards and be able to produce a proof-of-concept that shows it. If the wix toolset will get me 80% (or more) of the way there then I can most likely hammer away at the remaining small issues until I get them worked out. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gendelman, Yuri Sent: Friday, May 16, 2008 10:38 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Generate MSI during install Hello Phil, You can create 2 separate WiX projects, for a server, and for a client. Than add a Custom Action to the first one (server), which will launch a batch file for compiling and linking the second one (client). MBR, Yuri -Original Message- Date: Fri, 16 May 2008 10:05:47 -0400 From: Phil Sayers [EMAIL PROTECTED] Subject: [WiX-users] Generate MSI during install To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I'm doing some planning for moving from our existing xcopy based deployment to msi (hopefully with wix) based installs. Our application is written in .net framework 2.0 We have a client server that need to be deployed with separate MSI's. The server side of the application consists of a bunch of dll files and an IIS hosted remoting server. I'd love to be able to touch or generate the client MSI as part of the server installation, based on information entered by a network admin as part of the server MSI install. This way the client side of the application would already have server name, ip address, remoting endpoints written into it's config file and the end user woudln't need to enter that info as part of the client install. I'm new to Wix, but I have been lurking on this list for the last 6 months or so. Is this something i can do with Wix? Has anyone done something like this? Thanks Phil - 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] Generate MSI during install
Hello Phil, You can create 2 separate WiX projects, for a server, and for a client. Than add a Custom Action to the first one (server), which will launch a batch file for compiling and linking the second one (client). MBR, Yuri -Original Message- Date: Fri, 16 May 2008 10:05:47 -0400 From: Phil Sayers [EMAIL PROTECTED] Subject: [WiX-users] Generate MSI during install To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I'm doing some planning for moving from our existing xcopy based deployment to msi (hopefully with wix) based installs. Our application is written in .net framework 2.0 We have a client server that need to be deployed with separate MSI's. The server side of the application consists of a bunch of dll files and an IIS hosted remoting server. I'd love to be able to touch or generate the client MSI as part of the server installation, based on information entered by a network admin as part of the server MSI install. This way the client side of the application would already have server name, ip address, remoting endpoints written into it's config file and the end user woudln't need to enter that info as part of the client install. I'm new to Wix, but I have been lurking on this list for the last 6 months or so. Is this something i can do with Wix? Has anyone done something like this? Thanks Phil - 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] Exclusive Installation of Features
Hello All, In the 'yep - back to being 100% frustrated' thread, someone mentioned it is impossible to installtwo features exclusively from one another. Is this true? I would like to create an installer that is capable of installing my certs, and/or my rich client, and/or my web application, and/or my full server. But judging from the use of feature level, it seems impossible to arbitrarily choose one of these and not install any of the others. Is this correct? Is there no workaround using conditions on my features? My initial experiment suggests not. With best regards, Raj Tanikella - 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
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
Re: [WiX-users] removing components marked with the Permanent attribute
John Lalande wrote: Is there a way to remove components that were marked with the Permanent attribute when installed? No. Also, can a permanent component be upgraded? Yes, if the key file is upgraded (i.e., with a higher version number). -- 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
Re: [WiX-users] Allow installer to install over itself
Colin Bleckner wrote: Yeah you're right, updating the build number is probably a good idea. Does WiX support a way to update build numbers automatically? I'd like to make building my installer as idiot proof as possible so that there are fewer ways I can accidentally screw things up the future. Having to remember to change a version number property before each build sounds like an easy thing to forget. :) You can pass in a preprocessor variable from your build environment and refer to it as $(var.BuildNumber). You can also use binder variables to get the version number from a file. See http://www.joyofsetup.com/2008/01/13/highlights-of-wix-v303711/. -- 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
Re: [WiX-users] WiX3 DIFxApp extension on x64
Kevin Richardson wrote: Is x64 support not yet in the WiX DIFxApp extension? Is there a workaround? Not today. We probably need to add an attribute to distinguish the type of component (x86, x64, ia64) to plug in the right version of difxapp.dll. -- 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
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
Re: [WiX-users] Installshield decompiling
Jody Belka wrote: Ah, doh! Should have thought about that. Orca had completely slipped my mind for some reason. That let dark get further. Complained about some stuff with the CustomAction table, but removing the table completely let it continue, and for what I'm after that's fine. You can also use dark's -sct switch to suppress compiling custom tables. As I recall, InstallShield's _Validation bugs only affected its custom tables, not the stock tables. -- 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
Re: [WiX-users] wixunit?
Richard wrote: - start/reset the VMware guest machine image - launch the built install in the VMWare image - monitor the VMware image for failures - report back via email to the developers any failures Me too, in a previous life. The challenge is to test your product (or just its setup) rather than testing MSI itself. We had an ongoing issue where the test was a simple does the product run? which meant that the setup devs were tier-1 support for every failure. Guess what? Most of the failures were in the product code, not the setup. Yet another reason why centralized setup is risky. -- 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
Re: [WiX-users] WiX v3 and 64-bit version of DIFXAPP.DLL
Demyn Plantenberg wrote: Is something missing, or is WiX 3 not yet ready for x64 drivers? It currently supports only x86. -- 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
Re: [WiX-users] problem with repair in v2
Kunal Desai wrote: I have a website that serves msi packagesat the point of downloading the file if I select run instead of save I can install the file successfully...but if I do it again and select the repair button for the same package the repair fails giving a network error...any ideas anyone??? If you choose Run, the browser saves the .msi file in its cache and it probably will be cleaned up. Repair requires the original .msi package to get to the original files; MSI looks for it in the original directory it installed from (the browser cache). The general approach is to offer .exe downloads that know how to cache the .msi in a localappdata directory. (The WiX setupexe chainer does that, for example.) -- 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
Re: [WiX-users] Uninstalling a Feature where the Level condition has changed since installation
John Lalande wrote: Our product contains a feature to integrate with Lotus Notes. The feature's Level is set to 0 (so that it is not selectable), and conditionally set to 1 if Lotus Notes is installed. If later, Notes is uninstalled, then our product won't uninstall the Notes integration feature, leaving files in the Notes install folder and the product entry in the ARP. Wix3.msi had the same problem with Votive: If you uninstalled a version of Visual Studio, the Votive feature for that version of VS would be orphaned. The simple fix: Add OR REMOVE to the condition, so that the feature is always enabled during an uninstall or feature-removal maintenance mode. -- 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
Re: [WiX-users] questions about 64 bit installs
Scott Sam wrote: 1.Is it possible to have one installer, that recognizes whether the OS is 64 bit or not. Then installs either the 64 bit or the 32 bit version of our software accordingly? Or do we have to have two separate installers, one to install the 32 bit version, and another for the 64 bit version? You need two. MSI, for whatever reason, doesn't allow multi-platform or platform-neutral packages. 2. From what I've read, you have to set x64 or intel64 in the installer for 64 bit. What if you don't know at compile time what type of processor is being used? If you support both IA64 and X64, you need two packages (three if you also support X86). -- 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
Re: [WiX-users] Temporary files in WiX?
Ah. So let's make sure we're clear, there's a difference between asking for can I write files during install to a temporary location vs. can I clean up some files I've installed to program files after install :) Good point on the repair, I guess we'll leave the files around. Neil From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: May-16-08 8:42 AM To: Neil Enns Cc: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Temporary files in WiX? Neil Enns wrote: Thanks for the details, Rob. It sounds like from you write below that the security issue exists regardless of whether the files are temporary, correct? Any time you have an installer that writes files to a disk, then executes them via a deferred custom action, the vulnerability owuld be there? No, because Program Files is a secure location. To write to it, you'd already need to be admin. In our specific case, the files we're laying down on disk are the DirectX 9.0c redist files we need, then we execute them at the end of our setup. In FlightSim, I leave the files installed so I can run repair. FWIW. -- 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
Re: [WiX-users] questions about 64 bit installs
That's what I was afraid of. Thanks for the info. 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: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 12:31 PM To: Scott Sam Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] questions about 64 bit installs Scott Sam wrote: Is it possible to have one installer, that recognizes whether the OS is 64 bit or not. Then installs either the 64 bit or the 32 bit version of our software accordingly? Or do we have to have two separate installers, one to install the 32 bit version, and another for the 64 bit version? You need two. MSI, for whatever reason, doesn't allow multi-platform or platform-neutral packages. From what I've read, you have to set x64 or intel64 in the installer for 64 bit. What if you don't know at compile time what type of processor is being used? If you support both IA64 and X64, you need two packages (three if you also support X86). -- 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
Re: [WiX-users] Exclusive Installation of Features
If you use the custom dialog you should be able to pick and choose which features get installed. Or use the feature tree template. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanikella, Rajanikanth (SCR US) Sent: Friday, May 16, 2008 12:23 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Exclusive Installation of Features Hello All, In the 'yep - back to being 100% frustrated' thread, someone mentioned it is impossible to installtwo features exclusively from one another. Is this true? I would like to create an installer that is capable of installing my certs, and/or my rich client, and/or my web application, and/or my full server. But judging from the use of feature level, it seems impossible to arbitrarily choose one of these and not install any of the others. Is this correct? Is there no workaround using conditions on my features? My initial experiment suggests not. With best regards, Raj Tanikella - 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] XmlConfig setting I should use to replace just the address attribute value in the following parts of an app.config using a public property defined value?
Any tips on the XmlConfig setting I should use to replace just the address attribute value in the following parts of an app.config using a public property defined value? I'm thinking something like the following based on the samples provided for using XmlConfig but am concernted that I'm trying to delete and replace a block of xml when there may be an option to just replace the address attribute which is really the only thing I need to change on a per deployment case. Product.wxs File Id=MyTool1.exe.config Name=MyTool1.exe.config Source=$(var.MyTool1.TargetPath).config / util:XmlConfig Id=Tool1IMyWcfServiceEndpointDelete File=[#MyTool1.exe.config] ElementPath=/configuration/system.serviceModel/client/endpoint VerifyPath=/configuration/system.serviceModel/client/[EMAIL PROTECTED]quot;WSHttpBinding_IMyWcfServicequot;[\]] Name=Child Action=delete Node=element On=install Sequence=1 / util:XmlConfig Id=Tool1IMyWcfServiceEndpointCreate File=[#MyTool1.exe.config] ElementPath=/configuration/system.serviceModel/client/endpoint VerifyPath=/configuration/system.serviceModel/client/[EMAIL PROTECTED]quot;WSHttpBinding_IMyWcfServicequot;[\]] Name=Child Value=[IMYWCFSERVICEENDPOINT] Action=create Node=element On=install Sequence=1 / MyTool1.exe.Config configuration . . . system.serviceModel client endpoint address=https://localhost/MyWcfService/MyWcfService.svc; binding=wsHttpBinding bindingConfiguration=WSHttpBinding_IMyWcfService contract=ServiceReference1.IMyWcfService name=WSHttpBinding_IMyWcfService /endpoint endpoint address=https://localhost/MyOtherWcfService/MyOtherWcfService.svc; binding=wsHttpBinding bindingConfiguration=WSHttpBinding_IMyOtherWcfService contract=ServiceReference2.IMyOtherWcfService name=WSHttpBinding_IMyOtherWcfService /endpoint /client /system.serviceModel /configuration - 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] Temporary files in WiX?
A repair is really just another (re)install. You could extract them again. If you call installed files, it can sometimes get tricky if you need to reference them late during the uninstall... the files could be gone by the time you need them.This scenario, the desire to hide/not persist the files while not installing and the desire to consume files during the UI sequence prior to installation are the three main triggers that drive me to use this type of pattern. Also it should be noted that the code injection risk can also occur if a SysAdmin either enables the always elevate policy or grants non-priv users modify to the file share containing the MSI. I still feel that the risk is minimal and that's it's much easier to to just boot off of a usb key or cdrom and run ntpassword then build the MSI domain knowledge needed to pull off this type of exploit. Neil Enns [EMAIL PROTECTED] wrote: Ah. So lets make sure were clear, theres a difference between asking for can I write files during install to a temporary location vs. can I clean up some files Ive installed to program files after install J Good point on the repair, I guess well leave the files around. Neil From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: May-16-08 8:42 AM To: Neil Enns Cc: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Temporary files in WiX? Neil Enns wrote: Thanks for the details, Rob. It sounds like from you write below that the security issue exists regardless of whether the files are temporary, correct? Any time you have an installer that writes files to a disk, then executes them via a deferred custom action, the vulnerability owuld be there? No, because Program Files is a secure location. To write to it, you'd already need to be admin. In our specific case, the files we're laying down on disk are the DirectX 9.0c redist files we need, then we execute them at the end of our setup. In FlightSim, I leave the files installed so I can run repair. FWIW. -- 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] 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
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
Re: [WiX-users] Exclusive Installation of Features
Date: Fri, 16 May 2008 09:22:57 -0700 From: Tanikella, Rajanikanth (SCR US) [EMAIL PROTECTED] Subject: [WiX-users] Exclusive Installation of Features In the 'yep - back to being 100% frustrated' thread, someone mentioned it is impossible to install two features exclusively from one another. Is this true? I would like to create an installer that is capable of installing my certs, and/or my rich client, and/or my web application, and/or my full server. But judging from the use of feature level, it seems impossible to arbitrarily choose one of these and not install any of the others. Is this correct? Is there no workaround using conditions on my features? My initial experiment suggests not. Yes, it can be done. I only have two features (Hub and Edge) that are exclusive so my example is a bit simplistic compared to something with more exclusive features, but you'll get the idea. I created a custom error dialog, MG_FeatureError, that says; One, and only one, of the sub-features may be selected. Then in the UI section of the project I have this; UI [snip] !-- If multiple NewDialog and SpawnDialog control events are selected for the same control, -- !-- only the event with the largest value in the Ordering column gets published -- !-- when the control is activated. -- !-- http://msdn2.microsoft.com/en-us/library/aa368037(VS.85).aspx -- Publish Dialog=CustomizeDlg Control=Next Event=NewDialog Value=MG_FeatureError Order=3![CDATA[Hub=3 AND Edge=3]]/Publish [snip] Your conditions will likely get large/messy, but it can be done. ( FeatA=3 AND (FeatB=3 OR FeatC=3 OR FeatD=3) ) OR ( etc... ) This does not enforce the restriction on installs with no UI, but hopefully the people invoking from the command line read the documentation... Dale Dale Quigg ||| Senior Build / Configuration / Installation Engineer MessageGate ||| Enterprise Email Governance - 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, 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
Re: [WiX-users] DTF in WiX
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
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
Re: [WiX-users] Generate MSI during install
To expand on some of the earlier suggestions, I would offer the following: * As suggested earlier, create two WiX projects--one for the server and one for the client. * Create the client so that all options (or at least a many as possible) will be used as properties. To get the client WiX project to compile, you may need to define default properties and values in your WiX source files. * As was also suggested, take a look at the Windows Installer SDK. Specifically, I would take a look at the %ProgramFiles%\Microsoft SDKs\Windows\v6.1\Samples\SysMgmt\Msi\scripts directory if you have the lastest Windows SDK installed. In this folder, you will find a number of Wi prefixed VBScript files for interacting with Windows Installer. Of particular interest might be WiRunSQL.vbs. There are a few caveats, but you can essentially perform basic queries against an MSI file. If you have defined all your configurable options as properties, you can simply UPDATE the Properties table with the custom values. If you adapt the WiRunSQL vbScript file and embed it in the MSI to use as a VBScript CustomAction, you can use Session.Property(PropertyName) to set and/or retrieve property values from the currently-running setup process. Feed those values to your MSI queries, and you should be able to update the client MSI file. * There are some quirks in VBScript while running under Windows Installer. For example, from my experience, timed dialog boxes always seem to spike the CPU and then just hang. So, just forewarning you that a VBScript that behaves one way as a standalone script might behave differently under Windows Installer. * Install Orca.msi from the %ProgramFiles%\Microsoft SDKs\Windows\v6.1\bin directory if you have not done so already. This will allow you to view the MSI database structure and view/edit table contents, which can be helpful in verifying that an MSI file was configured correctly. Though your desired process is a little different, I am essentially doing other steps similar to those describe above to achieve a similar result. Hope this helps, Matthew Phil Sayers wrote: I'd love to be able to touch or generate the client MSI as part of the server installation, based on information entered by a network admin as part of the server MSI install. This way the client side of the application would already have server name, ip address, remoting endpoints written into it's config file and the end user woudln't need to enter that info as part of the client install. -- View this message in context: http://www.nabble.com/Generate-MSI-during-install-tp17275539p17283646.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
Re: [WiX-users] DTF in WiX
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
[WiX-users] Heat question
I am a new user of Heat.exe. I would like to exclude a directory or files with specific extensions from Heat. An example would be, exclude directory .svn from Heat selection. An example of a file extension .log. Is it possible to do this from the commandline or is this being considered as a future enhancement. Mark E. Eva - 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 v3 and 64-bit version of DIFXAPP.DLL
And a bug is open to add x64 support... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Friday, May 16, 2008 09:18 To: Demyn Plantenberg Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX v3 and 64-bit version of DIFXAPP.DLL Demyn Plantenberg wrote: Is something missing, or is WiX 3 not yet ready for x64 drivers? It currently supports only x86. -- 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
Re: [WiX-users] Building localized versions of an installer
Okay, there is clearly something fundamentally busted. Can you open a bug with as much information as possible? There is a way through this process (I know plenty of people are successfully using it) but you have obviously found a case that doesn't work. From: Fairweather, James [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 01:01 To: Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer OK, that's good to know about what the various tools are designed to output. Unfortunately in this case calling torch on the wixmst file returns an error similar to the one light gave me: Ø Torch.exe en-us.wixmst -out en-us.mst C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje\File.idt : error TRCH0136 : There was an error importing table 'File' from this file. Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje'. Unbinder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\nkwvmsje'. Torch temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\-2sfc210'. From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 8:13 PM To: Fairweather, James; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer Yeah, this is easy but the error message didn't help you (I've given it to Peter and he'll try to fix it tonight). light is for creating MSI/MSM files. torch is for creating MST files. pyro is for creating MSP files. Armed with that knowledge, hopefully it is clear that your final command-line should be torch en-us.wixmst. smile/ In the future, the error messages should point you in the right direction. From: Fairweather, James [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 15:08 To: Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer Thank-you , Rob and Josh. That looks like it should work, but it fails with a not-very-helpful error message: I have produced a .wixmst file from torch like so: Ø torch.exe -t language -v -p -xi -xo C:\eao neutral.wixout en-us.wixout -out en-us.wixmst Now call light on the wixmst file to create the transform: Ø light.exe en-us.wixmst Microsoft (R) Windows Installer Xml Linker version 3.0.3907.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w\File.idt : error LGHT0136 : There was an error importing table 'File' from this file. Binder temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\ail5es2w'. Validator temporary directory located at 'C:\Documents and Settings\jamesf\Local Settings\Temp\ihybiq-8'. I will debug this further, but before I do, is there something obvious that I'm doing wrong? From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2008 2:01 PM To: Fairweather, James; wix-users@lists.sourceforge.net Subject: RE: Building localized versions of an installer You're right on track. Last step is to take the .wixout (should have been named .wixmsi to match the other things but .wixout came first) and feed it back into light.exe. Light will finish processing the .wixout into MSI. Is that detailed enough or am I missing a step? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fairweather, James Sent: Thursday, May 15, 2008 13:12 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Building localized versions of an installer Many of our companies' products are localized into several languages. To build the an installer to handle this, we first build a neutral MSI, then for each culture, we build an MSI, then use msitran to build a transform, and finally msidb to merge the transform back to the neutral MSI. This works, but it's really slow because of all the file copying and cabinet building. The fileset is the same for all cultures, so it would be really handy if there were a way to tell light to not build the cabinet file (after the first one). There is a -reusecab option, but it's still pretty slow (I think due to a lot of file copying), and it sometimes crashes on large filesets. The approach we are exploring is to use the XML format (-xo option to light), then use the torch tool to build the transform from that. While this is great from a speed point of view, I don't see a way of getting from the XML format back to MSI/MST. Am I missing something, or has that simply not been implemented to date? James Fairweather Lead developer and support engineer Core Team 604.456.3911 (x13911) [cid:image001.jpg@01C8B77B.37BECA10]http://eatech.ea.com/ inline: image001.jpg- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
Re: [WiX-users] questions about 64 bit installs
You don't need to worry about Intel64. You don't have one. Neither do your customers. Intel64 refers to the Itanium processor family, not Core or Xeon processors, which come under x64. It's badly named but for historical reasons - Intel produced Itanium processors, referred to as IA-64 for Intel Architecture, 64-bit, several years before AMD extended the x86 instruction set to 64 bits. (Itaniums are very rare and expensive. Architecturally they're superior if you're starting from a clean slate and comparing clock-for-clock, but as x86/x64 clock speeds have ramped up they're faster for less money. Itanium still has the edge on floating-point performance of native Itanium code, but is still pretty poor - despite JIT-compiling x86 code - on 32-bit code.) -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: 16 May 2008 18:37 To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] questions about 64 bit installs That's what I was afraid of. Thanks for the info. 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 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] then delete this email from your system. From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 12:31 PM To: Scott Sam Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] questions about 64 bit installs Scott Sam wrote: Is it possible to have one installer, that recognizes whether the OS is 64 bit or not. Then installs either the 64 bit or the 32 bit version of our software accordingly? Or do we have to have two separate installers, one to install the 32 bit version, and another for the 64 bit version? You need two. MSI, for whatever reason, doesn't allow multi-platform or platform-neutral packages. From what I've read, you have to set x64 or intel64 in the installer for 64 bit. What if you don't know at compile time what type of processor is being used? If you support both IA64 and X64, you need two packages (three if you also support X86). -- 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
Re: [WiX-users] Installing .NET 3.5 redist?
It’s an MSI philosophy and it’s a consequence of .NET’s installer. You cannot nest MSI installs. That’s a property of Windows Installer. The Framework’s installer is itself an MSI. .NET has to ship one component, Fusion.dll for managing the GAC, that Windows Installer depends on as of Windows Installer 2.0, and recursively .NET’s installer has to install items to the GAC, so it actually stops the Windows Installer service in the middle of installing to upgrade that one file. You can see why this is a problem. “.NET 3.5” is an appalling name for a set of additional libraries and components for .NET 2.0. In fact the .NET Framework 3.5 installer downloads and installs: .NET 2.0 SP1, either complete or as an MSP patch if .NET 2.0 RTM is installed, a Windows patch on Windows Vista “.NET 3.0” SP1, either complete or as an MSP patch if .NET 3.0 RTM is installed, a Windows patch on Windows Vista The .NET 3.5 new libraries MSI. For 64-bit systems it has two copies of all of that. That lot all told takes 197MB if you download the full package (http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe). Therefore Microsoft recommend you supply the 2.7MB install starter package which detects what OS you’re on, whether you have a 64-bit architecture (and which one), and which components you already have, so it can download only the updates that are required. Be prepared to warn Vista users not to click the Reboot button from Windows Update when the .NET 2.0 and 3.0 patches have been applied. That will wreck the Windows Installer transaction for .NET 3.5 and you’ll be spending time with MsiZap to clean it up. Reportedly there is a plan for a 20MB or so client-only installer in .NET 3.5 SP1/VS2008 SP1. See http://msdn.microsoft.com/en-us/vstudio/products/cc533447.aspx for details. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: 16 May 2008 02:28 To: Neil Enns; Kelly Leahy Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing .NET 3.5 redist? 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. Neil Enns [EMAIL PROTECTED] wrote: That's what I was afraid the answer would be :( Thanks. Neil _ From: Kelly Leahy [EMAIL PROTECTED] Sent: Thursday, May 15, 2008 4:50 PM To: Neil Enns [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net; [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [WiX-users] Installing .NET 3.5 redist? You need a bootstrapper for this. You won't be able to nest the installers in any way that works. Neil Enns [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/15/2008 04:45 PM To wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Subject [WiX-users] Installing .NET 3.5 redist? Has anyone had any experience with installing the .NET 3.5 redistributable as part of a WiX installer? We are a Vista-only application, and know we’ll need to install .NET 3.5 to run. There’s a standalone exe (netfx35_x86.exe) that installs the redist, but we’re not sure how to integrate that into our installer. Calling it from our installer with a /q flag results in an error because there’s already another install (ours) running. Thanks for any tips or pointers! 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 communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless otherwise noted in this email or its attachments, this communication does not form a Statement of Actuarial Opinion under American Academy of Actuaries guidelines. ** - This SF.net email is
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
Re: [WiX-users] DTF in WiX
Well, unfortunatly that's all the free time I have for tonight. I can see you've got a custom CSPROJ but the targets and tools references are invalid for me. I'm searching through the source,binaries and MSI distribs but don't see what it's looking for. I did manage to build a CA and see it's function exported in depends but when it runs in my install it blows up. Hopefully I'll figure it out in the morning. Christopher Painter [EMAIL PROTECTED] wrote: 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
Re: [WiX-users] DTF in WiX
Sorry, one last post for the night. I noticed that my call to MakeSfxCA.exe is failing with this exception: Searching for custom action entry points in ClassLibrary1.dll Loaded dependent assembly: ExternalAssemblies\Microsoft.Deployment.WindowsIn staller.dll Error: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.D eployment.Resources, Version=3.0.0.0, Culture=neutral, PublicKeyToken=36e4ce08b8 ecfb17' or one of its dependencies. The located assembly's manifest definition d oes not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'Microsoft.Deployment.Resources, Version=3.0.0.0, Culture=neutral, Pu blicKeyToken=36e4ce08b8ecfb17' I've looked at assemblies in wix-3binaries/msi and they have a different public key token (ce35f76fcda82bad) ... is this intentional or is something wrong? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] yep - back to being 100% frustrated
Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. If you understand that, a lot of the features and the ICE error reports make sense. The trouble is that this corporate deployment environment is so rare even large corporations rarely use it, largely because many MSIs dont work right in that environment and so far away from the common case that most of us are dealing with, namely installing applications one time for all users of a personal computer that isnt on a managed network and doesnt roam. Why is a per-user install the default? Because in these corporate environments, multiple users on the same machine might not be allowed access to the same applications. Why are advertised shortcuts the default? Because in these environments, you might advertise the product only so that only those users who actually need to use it actually invoke the installer. (Never mind that users will typically browse to see whats available, what does this do?, so invoke the installer almost by accident.) That comes from a corporate desire to fit smaller, cheaper disks but theres a lower limit as to how small you can make a disk with a given technology. For example an 80GB Seagate SATA drive costs £24.20 from a site Im looking at now, but a 160GB drive, double the space, costs only £6 or 25% more. The disk as a fraction of the system cost has fallen over the last ten years. Why are advertised shortcuts and icons so complex? To support Windows 95 and NT 4.0 without the IE4 Desktop Update. Why do the Class and TypeLib (etc) tables create an advertised link? Because someone thought it would be a good idea to support on-demand installs of COM objects, when it was a tenet of architecture astronauts that wed stop buying pre-assembled applications and instead assemble our applications ourselves from libraries of pluggable components. (This one keeps coming back, only now its called a mash-up, but everyone always overlooks the testing matrix, which suffers combinatorial explosion with even a few different components.) In some cases the ICE tests indicate a smell in the core installer engine ICE38, keying the installation of a shortcut from the absence of a registry key, should have been fixed in Windows Installer itself somehow. And now, time for a confession. I havent built any installers with WiX. Everything were shipping were still shipping with Visual Studio deployment projects. I havent been given the time to invest in improving the installer for our application server product, which is really our only product (in that the same object code is shipped to every customer) for which I was evaluating WiX. (I work for a small contract development house owned by a value-added reseller, mainly of handheld devices, but were all generalists and do some management consoles, Web- and Windows-based, for handheld-driven systems, plus this application server and some comms servers.) The application server is nearly exclusively sold as part of a larger solution while plug-in applications can be written by anyone (you write a COM object with a couple of defined entry points), in practice weve sold to very few companies doing their own application development. As such any investment in the application server tends to be to fix issues experienced by one or more customers or to add features for an upcoming system. Having been on this mailing list for a long time Im torn between replacing the installer for this with a WiX-based installer with a huge amount of pain that will go with that, and the knowledge that few of my colleagues will be able to maintain it and ditching it for something like NSIS. We dont install many shared components, which in my view is the area in which Windows Installer-compliance is necessary. Im considering going registration-free COM, a tricky prospect with VB6 applications (no investment in migrating from VB6 ), but better than installing shared components. Shared-nothing components and application initialisation of configuration make for very simple WiX installs, but theyre so simple that theres no need to do component reference-counting (which is a good thing, since thats where Windows Installer is complicated) so you might as well have used xcopy. The only thing Windows Installer is doing for you is allowing you to create shortcuts and register services! Its not very compelling. With my database administrators hat on, I find applications that install their own databases tiresome. They inevitably seem to make mistakes in their installers. Reporting Services service packs dont quite line up with schema versions, so you seem to end up scrapping the existing database and recreating. SourceGears Vault accidentally inserted a backslash before the data file name when there was already one at the end of the path, then SQL Servers
Re: [WiX-users] yep - back to being 100% frustrated
It's true for simple applications, but those simple applications are just anything that can be written to be statically linked into a single binary. You could do this on Windows if you were prepared to stick to those rules - and you can produce quite powerful applications that way, if you cared to do it. But you'd have to forgo anything that needs a shared library or framework or fonts - basically anything bigger than a single file. Apple's page Installs for Product Developers says: For anything that requires something shared, it's a myth. The icon you drag-and-drop is an installer. It's just that drag-and-drop invokes the installer, the same way that double-clicking invokes an MSI installer. See 'Managed Installs' in Apple's Software Delivery Guide at http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareD istribution/Managed_Installs/chapter_5_section_1.html. I think the difference really is that there isn't such a prevalence of shared libraries on the Mac as on Windows, and of things like multiple disk volumes. To upgrade your Mac, you buy a new one, you don't start adding disks (because on most Macs, you can't add internal disks). It makes for a far simpler environment. Also, the pace of support for new operating systems is much faster, most Mac apps won't install on the OS earlier than one version before current. A lot of us are still writing software to work on Windows 2000 (I hope no-one here is still building ANSI apps for Windows 9x though!) There are also many, many places where Windows allows plug-ins (e.g. Explorer context menus) that just aren't there on the Mac. Microsoft's approach tends to be to offer many new features even on down-level operating systems. Imagine if your customers had to update to XP.3 in order to get .NET 2.0, or Windows Vista 6.1 to get .NET 3.5! But that makes deployment much more complicated, because you have to deploy the framework you depend on, and its dependencies, to get your program to work at all. Also Mac apps tend to be less configurable. The million-questions approach taken by most Windows install packages is ridiculous when you consider that most users just go with the defaults. Clicking through Windows Installer wizards is a pain in the neck. It's not as if selecting a reduced install of Office 2003 or 2007 actually reduces the disk space used, because (to prevent problems with finding original media when patching or repairing) a complete copy of the install is cached on your hard disk anyway. You might as well install the whole thing to begin with. And a repair is only necessary when some shared component has been stomped on with an incompatible version anyway. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: 13 May 2008 19:58 To: Josh Rowe Cc: WiX Users Subject: Re: [WiX-users] yep - back to being 100% frustrated On a Mac you would just drag and drop the application icon. The very existence of an installer is frowned upon for most things. Why doesn't Microsoft rip-off that instead of the desktop eye-candy? :-) - 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
