Re: [WiX-users] Using .NET 2.0 Managed Custom Actions
Rob, have you taken a look at the method that Christopher Painter alluded to in his comment on your blog post regarding Managed CA's? He seems to have built something that implements a helper process to load the CLR and communicates with the installer via IPC. This seems to be more of the architecture that you suggested would like be the way to do this if you were going to do this. I also commented on your blog (and many others did as well) that the strategy as expressed to you by the architects you spoke to doesn't seem to hold water for many of us now. I think we all understand that CAs are hard to get right and create instability, so they are best avoided. Unfortunately, they happen to be unavoidable in many cases. Telling us that a future version of Windows and the installer may make it such that we won't need as many CAs is nice, but it doesn't help anyone get any work done now. Some part of you must agree with that assessment, as you spend a lot of your time developing CAs to address these gaps now. I'm sure you've also realized by now that WiX is never going to create a big enough CA library to take care of everyone's needs (although please don't stop trying on my account--I'm happy to use yours whenever I can!). Why not a managed code IPC invoker CA for WiX? Perhaps Christopher would even contribute? It can't be much dirtier than the silent execution CA and offers the advantage of richer integration with the installer. Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Mailinglist [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, April 20, 2007 12:42 PM Subject: Re: [WiX-users] Using .NET 2.0 Managed Custom Actions I wish you the best of luck. As long as you know that you are doing things that are not supported (and in a way actively discouraged) then may your code work for a very long time. I also hope your install does not create future compatibility problems for the Windows Installer team (from what I've heard they have their hands full enough as it is). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mailinglist Sent: Friday, April 20, 2007 6:06 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using .NET 2.0 Managed Custom Actions Hi Johan, How does this work around the technical reason for managed custom actions not working that Rob Mensching blogged about recently? Well, it works, though we have not testet calling managed custom actions for different framework versions. We roll out our software, entirely written for .NET 2.0 as well as the custom actions are. Greetings Oliver Friedrich Consultant - Software Solutions - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] dot Net Custom actions
Also, if the CA is an EXE instead of a DLL-type CA or something, then you can launch it with an EXE CA. Joe K. - Original Message - From: DEÁK JAHN, Gábor [EMAIL PROTECTED] To: WiX-users wix-users@lists.sourceforge.net Sent: Friday, April 06, 2007 6:13 AM Subject: [WiX-users] dot Net Custom actions On Fri, 6 Apr 2007 13:21:35 +0700, Igor Lemsky wrote: Igor, http://www.tramontana.co.hu/wix/lesson3.php#3.5 lists the reasons while you shouldn't do it, although it is technically possible using an undocumented DLL. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
I think reasons people want to write managed CAs are the same ones that motivate them to write other pieces of code in managed code. It is more productive and potentially much less error prone. It is really just as simple as that. As I said before, managed code doesn't solve very many of the problems of writing good CAs in the first place. It doesn't address the how to design good table-driven, declarative authoring for the CA or the whole transactional aspect of the model. It does (hopefully) make many of the memory management problems disappear and give you this huge library of useful code to draw from that is very well integrated compared to most other options out there. My instincts tell me most of the time, CAs are needed for doing configuration of server software more than client software. Server software often includes the need to do IIS stuff, SQL, XML, perf counters, event logs/sources, WMI sinks, message queues, local security policy changes, COM+, etc, in order to get the software deployed and working without lots of manual steps post installation. A lot of these setups are for internal IT stuff and not just packaged commercial installers, as the internal IT guys are trying find ways to make their software easier to deploy and get more mileage out of their investments in their automated build processes. As a result, some of these setups may only ever need to run on a handful of machines. To this end, I think WiX has actually done a very admirable job of rising to meet this challenge by attempting to provide CAs that meet a lot of these needs. My impression is that people often resort to CAs when they encounter a functionality gap in WiX or a bug in the existing implementation. As WiX continues to evolve and improve, these gaps and bugs will slowly fade and will hopefully make a lot of the need for CAs fade as well. I would much rather see the WiX community continue to improve these areas than to get tied up in any sort of general purpose framework for implementing managed CAs. I completely agree with Rob that feedback regarding managed CAs should go to the WI team at MS and not the WiX community. Still, the discussion came up here, so I wanted to throw in my thoughts so that others participating in the discussion could understand my perspective. :) My overall points are: - Managed CAs make at least as much sense as script CAs (if not more!) and should be supported in WI as first class constructs (NOT WiX's problem!). - There is is clearly some dissonance within MS in terms of how setup ought to be done with the existing tension between managed installer classes, installutil.exe and the VS setup project installutillib thingy/hack and the right way to do things are prescribed by the WI team. Setup developers are the victim as they are receiving mixed messages on what they really should do. - WiX is doing the right thing by continuing to build a robust library of CAs to support the common tasks. Joe K. - Original Message - From: DEÁK JAHN, Gábor [EMAIL PROTECTED] To: WiX-users wix-users@lists.sourceforge.net Sent: Saturday, March 24, 2007 4:08 PM Subject: [WiX-users] C# .dll On Sat, 24 Mar 2007 20:38:16 +, Fredrik Grohn wrote: First to all, please, clear out all the participants from the To: and CC: lines and keep the discussion on the list itself. I guess we all monitor it regularly so it's really not beneficial to receive every posting twice, both directly and from the list. Fredrik, What I don't understand is why people are so eager to build managed custom actions in the first place. That's what bothers me, too. If somebody really wanting to write a managed (or unmanaged) custom action could tell us why he or she needs it in the first place. I completely agree with Richard Foster, me, too: the only real custom action I ever wrote was to check the product key entered by the user. I have a suspicion that the need for custom actions stem from sloppy programming of the application to be installed rather than any real, legitimate need for something WI can't solve. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
FWIW, I'm totally with Dhaval on the idea that managed custom actions would be a good thing. It just makes a lot of sense. I think it makes a lot more sense than supporting scripts, which as Rob has pointed out many times, are just asking for trouble if you try to use them. Having C++ as the only viable alternative is very limiting. I also agree with some of the other points raised that CAs in general are hard to write because they require you to design for the compensating transaction programming model and that isn't easy to get right. That doesn't make managed CAs any less appealing though. It just means they aren't a slam dunk, any more than the current supported approaches to writing CAs are. Still, anything that is hard to do in managed code is likely even harder to do well in native C++. The number of skilled C++ developers is likely to be dwarfed by the number of skilled managed code developers. The real issue (as Rob mentioned) is that WI doesn't support it and until the product does, it isn't too appealing to try to support them in WiX. It is very hard to get right for the reasons Rob stated and therefore probably not worth doing at all. The other problem with WiX adding its own support is that the approach would be proprietary to WiX and therefore would not translate to future WI implementations, leaving the current WiX users stranded. The whole thing makes me sad though. :( Joe K. - Original Message - From: Dhaval Patel [EMAIL PROTECTED] To: Wilson, Phil [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Monday, March 19, 2007 7:02 PM Subject: Re: [WiX-users] C# .dll Thanks for those words of wisdom :) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# .dll
Hi Rob, Would you care to elaborate on this part a bit? If you already blogged it, I apologize. I've followed the evolution of this issue for a while now and I am always curious to learn more about it. To my knowledge, I don't remember you or anyone else discussing any specific issues regarding loaded the CLR into the installer process. I'm definitely of the opinion that these things are best avoided for now due to the lack of support for it at the WI level. On the other hand, I also believe it is just a matter of time before this needs to happen in a fully supported way. Basically, I'm trying to understand what the solution might look like in order to overcome some of the more subtle issues. What's so neat? :) Thanks! Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Levi Wilson [EMAIL PROTECTED]; Dhaval Patel [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Friday, March 16, 2007 12:43 PM Subject: Re: [WiX-users] C# .dll More importantly, the Windows Installer doesn't support it today. There are actually neat problems you can introduce by loading the .NET Framework into the Windows Installer process. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Friday, March 16, 2007 10:40 AM To: Dhaval Patel Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# .dll I don't know for certain, but my guess would be that there's no guarantee that the .NET Framework has been installed on the client. On 3/16/07, Dhaval Patel [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Will WIX 3.0 be adding the capability to call C# .dll files? If not, WHY? :) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.netmailto:WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supressing the command window onExeCommand custom action
ADAM is a Microsoft directory service product. Don't you work there? :) It stands Active Director/Application Mode and is basically a stand-alone LDAP directory server. I think the school solution to this is that he should be using a bootstrapper. Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Jon LeCroy [EMAIL PROTECTED]; Will Qian [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, February 16, 2007 8:07 PM Subject: Re: [WiX-users] Supressing the command window onExeCommand custom action I'm not sure there is a standard pattern. There are many different ways you can do something like that depending on how you want things to work and what you are trying to do. What does embedding ADAM in my installer mean? From: Jon LeCroy Sent: Friday, February 16, 2007 6:01 PM To: Rob Mensching; Will Qian; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] Supressing the command window on ExeCommand custom action To hijack this a little as that should answer Will's question.. When using QtExec, what's the standard pattern for getting files on the box to execute? In my case I'm embedding ADAM in my installer and need to unpack it so that I can call it with QtExec.. Cheers, Jon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, February 16, 2007 5:06 PM To: Will Qian; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Supressing the command window on ExeCommand custom action That's what QtExec (http://wix.sourceforge.net/manual-wix2/qtexec.htm) is for in the WiX toolset. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Qian Sent: Friday, February 16, 2007 4:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Supressing the command window on ExeCommand custom action Hi, I've got a problem and I was hoping someone could help me out. I'm trying to run a command line program, and I've got it working with a custom action: CustomAction Id='Action' Execute='deferred' Return='check' Property='EXEPATH' ExeCommand='PARAMS' HideTarget='yes' Impersonate='yes' / The only problem is I don't want that command window popping up and disappearing all the time. Is there some way I can get this custom action to not pop up the command window? Thanks Will - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Verify user?
Luckily, I've had that problem relatively recently so it came to mind. :) Like I said in my other mail, it would be a nice feature for WiX to support modifying local security policy to handle things like this, especially as a compliment for the support for user and group creation. It would really help connect these dots and enable a few scenarios. Joe - Original Message - From: Matthew Janulewicz [EMAIL PROTECTED] To: Rob Mensching [EMAIL PROTECTED]; Joe Kaplan [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, December 15, 2006 5:49 PM Subject: RE: [WiX-users] Verify user? From Joe Kaplan: 'I think you'd also need to check to see if the authenticated user has at minimum log on as a service privilege.' Thanks, Joe! That was it! I knew this in the back of my mind, too, but failed to remember that I was using a different user than myself. Thanks for all the help, guys! -Matt -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Friday, December 15, 2006 3:06 PM To: Matthew Janulewicz; Joe Kaplan; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Verify user? No difference that I know of. That's a built-in MSI action. A verbose log file should be able to show you more details about why it isn't installing. -Original Message- From: Matthew Janulewicz [mailto:[EMAIL PROTECTED] Sent: Friday, December 15, 2006 14:57 To: Joe Kaplan; Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Verify user? As a follow-up question, is there a difference in how this action (ServiceInstall) acts in an XP environment vs Windows 2k3? The installer I've developed on XP seems to install the service just fine in the dev environment, but when I take the same installer over to a 2003 server it seems to mostly skip that part altogether. It does write the registry entries I would expect, but even a reboot of the 2003 server will not get it to 'pop' into the services list. Any ideas? My code snippet looks like this: ServiceInstall Id=DomainTestService Account=[SERVICE_DOMAIN]\[SERVICE_USER] Description=TestService DisplayName=TestService ErrorControl=ignore Interactive=no Name=TestService.exe Password=SERVICE_PASSWORD Start=auto Type=ownProcess / ServiceControl Id=DomainServiceControl Name=TestService.exe Stop=uninstall Remove=uninstall / Earlier in the component I have the .exe set as a keyfile, etc. As I said it works just fine on XP, seems to not work on 2K3. Note that I do not want the service to start upon install, so I left the 'Start' key out of the ServiceControl item. Is this okay to do? -Matt -Original Message- From: Joe Kaplan [mailto:[EMAIL PROTECTED] Sent: Friday, December 15, 2006 2:16 PM To: Rob Mensching; Matthew Janulewicz; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Verify user? I think you'd also need to check to see if the authenticated user has at minimum log on as a service privilege. It might not. The service could still fail to start due to other ACL problems, so all in all, it is a pretty difficult thing to get 100%. A custom action that does LogonUser would at least validate the credentials though. Perhaps that could be added as a feature request for the service control CA stuff? Add a ValidateCredentials attribute or something... The privilege thing reminds me that it would be cool to have local security policy changes to handle things like user rights assignment as a CA in WiX (log on as service, act as part of the operating system, etc.). Another feature request. :) Joe K. - Original Message - From: Rob Mensching To: Matthew Janulewicz ; wix-users@lists.sourceforge.net Sent: Friday, December 15, 2006 12:13 PM Subject: Re: [WiX-users] Verify user? You'd need a CustomAction to try to logon that user (or something to verify it is a valid user/password). There isn't anything in the WiX toolset for that today, but it'd be cool if there was. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Janulewicz Sent: Friday, December 15, 2006 09:48 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Verify user? We're using Wix 3. One of our installers installs a service, but it may run under different users in different environments. The installer will prompt the user for the domain, username and password to apply during the ServiceInstall step. However, if they enter in an invalid user or password the installer just sort of uninstalls itself and stops. Is there a way to verify a domain/user/password is valid before ServiceInstall fires off? -- Matthew Janulewicz SCM Engineer Green Dot Corporation [EMAIL PROTECTED] (626) 775-3857 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your
Re: [WiX-users] Installing cert using WiX 3.0
Yes, that's currently the issue. The build in CAs do not support your scenario, so you'll need to write this yourself. This is why I posted the note I posted on Sunday night. So far, no feedback from the community though... Joe K. On 12/5/06, Rennie Sawade (Volt) [EMAIL PROTECTED] wrote: All I want to do is install the cert. I don't want to do anything with configuring IIS. Does that mean that I should do it in a custom action instead of using the IIS extension? Rennie From: Joe Kaplan on behalf of Joe Kaplan Sent: Mon 12/4/2006 9:03 PM To: wix-users@lists.sourceforge.net Cc: Rennie Sawade (Volt) Subject: Re: [WiX-users] Installing cert using WiX 3.0 It looks like you are missing the culture switch. Does your command line look something like this: light -ext wixiisextension.dll -cultures:en-US -out xxx.msi xxx.wixobj Note that the current IIS CA does not install certificates unless you have other IIS stuff defined as the CA that schedules all of the IIS actions exits out if there are no IIS configuration entries defined in the msi. See my email from yesterday regarding my complaint about that. Joe K. - Original Message - From: Rennie Sawade (Volt) To: wix-users@lists.sourceforge.net Sent: Monday, December 04, 2006 7:18 PM Subject: [WiX-users] Installing cert using WiX 3.0 I tried to install a CA certificate using: iis:Certificate Id='CertRA' StoreLocation='localMachine' StoreName='root'/ I then get quite a few LGHT0102 errors from the linker for different localization variables. Such as The localization variable !(loc.ConfigureIIs) is unkown. Please ensure the variable is defined. The error repeats for other variables such as (loc.StartMetabaseTransaction, loc.RollbackMetabaseTransaction, loc.CommitMetabaseTransaction,.). Can I not just install a certificate using the IIS extension? Or is this a known issue? Thanks, Rennie - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing cert using WiX 3.0
It looks like you are missing the culture switch. Does your command line look something like this: light -ext wixiisextension.dll -cultures:en-US -out xxx.msi xxx.wixobj Note that the current IIS CA does not install certificates unless you have other IIS stuff defined as the CA that schedules all of the IIS actions exits out if there are no IIS configuration entries defined in the msi. See my email from yesterday regarding my complaint about that. Joe K. - Original Message - From: Rennie Sawade (Volt) To: wix-users@lists.sourceforge.net Sent: Monday, December 04, 2006 7:18 PM Subject: [WiX-users] Installing cert using WiX 3.0 I tried to install a CA certificate using: iis:Certificate Id='CertRA' StoreLocation='localMachine' StoreName='root'/ I then get quite a few LGHT0102 errors from the linker for different localization variables. Such as The localization variable !(loc.ConfigureIIs) is unkown. Please ensure the variable is defined. The error repeats for other variables such as (loc.StartMetabaseTransaction, loc.RollbackMetabaseTransaction, loc.CommitMetabaseTransaction,.). Can I not just install a certificate using the IIS extension? Or is this a known issue? Thanks, Rennie - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] RFC: Change to WiX3 CAs to decouple Cert support from IIS ext
Hi all, I'd like to get some comments from the community on an idea I had regarding the WiX 3 CA support for certificate installation. Basically, I don't like it because it is strongly coupled to the IIS extension, even though certificates are a much more general OS level resource like users and groups. As some of you have discovered, if you attempt to use the Certificate element to install a certificate but do not do so in the context of configuring other IIS features, it actually doesn't do anything at all (this behavior really should be documented, btw!). This is because the CA function that actually schedules the various deferred IIS actions exits out if there are not IIS* tables in the database. My suggestion is to remove the certificates support from the IIS extension and move it into the utility extension with the other functions that install things like users and groups. To support the SSL configuration metabase stuff that the IIS extension does, my suggestion is to create a new element (perhaps SslConfiguration?) that contains a reference to the certificate hash for the certificate to be use and perhaps other flag settings. This would completely decouple the two extensions. I'd also recommend getting rid of the CertificateRef element which was previously used in a similar capacity. I think this change would make good overall sense in terms of how the CAs are factored and how Windows and IIS actually works. I think the biggest problem would that this is obviously a backward breaking change. This would obviously only be done on WiX 3 and my overall feeling is that this is the time to make such suggestions and changes while it is still under active development. Based on the feedback I receive from the user community, I'll log a feature request. Given that I have a vested interest in having a feature like this, I'm also tempted to try my hand at implementing it myself. We'll see how that goes. :) Thanks for your thoughts. Joe K. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to use floating Publish element to skip EULA dialog in WixUI V3
Hi guys, I assume Bob will answer this one if anyone does, but perhaps someone else knows. Basically, I'm hoping that the support for floating Publish elements in WiX 3 provides a neato trick that can be used to skip the default EULA dialog in WiX UI V3. A lot of us build installers for internal use only and don't want/need a EULA. I've seen other people ask for this in the past. I know people have gone in and chopped up WiX UI to do this in the past, but I was hoping for a straightforward authoring approach that would work. Alternately, if there isn't an easy way to do this, perhaps it would make sense for me to enter a feature request so that this could be selected via a private property or something. Obviously, it wouldn't be good to have a public property, as then people could skip the EULA via the correct command line args and that would be badness. :) Sorry if this has been discussed before, but I didn't see it. Thanks! Joe - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Create Event Log
Bob has added support to WiX 3 for custom event sources, but I don't think the custom log is in there yet. It is on the list. Luckily, both event logs and sources are simply a bunch of registry keys. This is bread and butter for WiX/MSI, so it is not difficult to implement this natively with no CAs at all. The trick is to get the authoring for the keys. You can easily go into the registry, export those nodes and use heat or tallow to convert the .reg files to WiX authoring though. The biggest trick in my mind is what to do about the event message DLL file. If you are using .NET and its eventlog support, you are almost certainly using the event message DLLs that come with .NET. In my mind, the main problem is picking the appropriate DLL from various possible .NET Framework installs that might be on the box. All of the event message DLLs will work and do the same thing though, so I don't think you really need to pick a specific one. I think you can use any. The file always has the same name, so you just need to get the right path. An alternate approach would be to put their DLL in your own installer so it is self-contained and reference it from your own install dir. That bloats your installer a bit and is a little evil, but should work. You can also write your own message dll. The MSDN reference talks a little about how. :) I think the first thing to do is look at the registry keys created for your custom log so you can start to understand how it works. MSDN also documents all the registry keys. Joe - Original Message - From: Peter Stokes To: wix-users@lists.sourceforge.net Sent: Thursday, September 14, 2006 9:05 PM Subject: [WiX-users] Create Event Log Hi, Is there a way to create an event log without resorting to installer files and Custom Actions. Cheers Stokesy Be one of the first to try Windows Live Mail. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] System.Security.SecurityException when runningcandle
LOL! Well said. CAS is nothing if not quite confusing. Most of them time we can code along with full trust and it never rears its head, but sometimes we brush up against it and it is not fun. Your caspol command line to create the policy change is very helpful here. Joe K. - Original Message - From: Jeremy Farrell [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, September 12, 2006 1:24 AM Subject: Re: [WiX-users] System.Security.SecurityException when runningcandle If Ben's like me, he'll find that Joe's and Bob's excellent explanations lead him to a cliff edge in a new world about which he knows nothing, and perhaps needs to know nothing other than what's needed to get WiX to work. If that's the case, just following this formula should do the trick. It should at least point in the right direction. If the tools are on a network filesystem, the system must be configured (once) to allow execution of the WiX toolset from a network filesystem. This can be done by a user with administrator privileges using the following command %WINDIR%\Microsoft.NET\Framework\v1.1.4322\CasPol -q -m -ag All_Code -strong -file path\wix.dll -noname -noversion FullTrust -name WiX_Strong_Name -levelfinal on where path\wix.dll is the path to any copy of wix.dll (including a local copy). The path to CasPol might be different, but this one is usually right. This command works for me, but I'm using a fairly old version of WiX 2; more recent versions might need a different version of .NET, but that's beyond my knowledge. Thanks again to whoever spelled this command out for me previously - it saved having to do a lot of learning when I was in a last-minute rush. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] re : votive with visual c# 2005 express edition
FWIW, I like that idea, simply because that's the only VS integration feature I really like to use. I think that's where the big productivity gain comes in with the Intellisense support you get for WiX schema. I usually copy the schema file by hand, but having some MSI support for it would be nice. You also have to associate the WiX extensions with the XML editor, which I also usually do by hand. Anyone who is editing WiX by hand (most of us I assume) and isn't taking advantage of this VS feature is crazy (IMHO). :) Joe K. - Original Message - From: Bob Arnson To: [EMAIL PROTECTED] Cc: Ali-Akber Saifee ; wix-users@lists.sourceforge.net Sent: Tuesday, September 12, 2006 1:54 PM Subject: Re: [WiX-users] re : votive with visual c# 2005 express edition Rob Mensching wrote: Also, Bob, we might consider allowing the Votive MSI install the .xsd's even if we can't install the full plug-in. Sound reasonable? Well, it's not unreasonable.g But it's not trivial, so I entered it as a feature request: http://sourceforge.net/tracker/index.php?func=detailaid=1557370group_id=105970atid=642717 -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] System.Security.SecurityException when runningcandle
In this particular case, CAS is complaining because candle is signed, but isn't marked with the APTCA (AllowPartiallyTrustedCallersAttribute) in the assembly level attributes. As such, when it is launched from a partially trusted context (like a network share), it fails instantly. To get around this, you would need to grant the assembly FullTrust. This is easy to do in a granular, secure way though, because WiX is signed. You can use a strong name membership condition with the WiX public key token to grant FullTrust. It might be possible to code WiX so that it could safely include APTCA and actually could run partially trusted, but I'm pretty sure it does a lot of COM interop which requires Full Trust anyway and given that it is a development tool, this is probably not worth doing. The WiX team has plenty of other stuff to work on. :) If it were a downloadable control, then that would be a different story... Joe K. - Original Message - From: Bob Arnson To: Ben Weatherman Cc: wix-users@lists.sourceforge.net Sent: Monday, September 11, 2006 10:43 PM Subject: Re: [WiX-users] System.Security.SecurityException when runningcandle Ben Weatherman wrote: I have WiX installed on a shared drive .NET doesn't support running assemblies from a network by default. Caspol is the only workaround I know of. -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallUtil considered harmful... What next?
Tallow won't reverse engineer Installer classes. You'll need to figure out how the service is actually installed and create the authoring for the ServiceInstall elements. That should not be too hard though. You'll also get a lot more functionality this way, as you can set a lot of things that aren't even exposed by the installer classes such as the service restart behaviors and the friendly description. There is a gotcha though with the managed service installer classes. Not only does it create a service in the service database, but it also installs an event source for you in the application log for the service to write to. In order to support this behavior, you'll need to create some WiX authoring to create an Event Source. This is done by setting the proper registry elements in HKLM to create an Event Source. I'm not sure if anyone has created a sample of this or not. You might be able to get tallow to help you here by saving the registry key settings to a file and reverse engineering that into WiX authoring. There is another trick to be aware though, in that .NET event sources use the message DLL that comes with the .NET framework, and the registry will contain a path to that. You may need to make that dynamic based on the version of the .NET framework you are supporting. It could get a little tricky, but should not be too hard. I hope that helps some. Luckily, you aren't doing perf counters or WMI or you would be looking at something much more difficult. :) Joe K. - Original Message - From: Eric Fesh [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 12:06 PM Subject: Re: [WiX-users] InstallUtil considered harmful... What next? So tallow works for .NET assemblies? I thought it would only capture that information from COM objects... Or do I need to go to 3.0.x for that? I'd been holding off upgrading until 3.0 stabilized, but I may not have a choice... -- Eric Fesh Customer Support Engineer/Software Test Engineer Verari Systems Software, Inc. 110 12th Street North, Suite D103 Birmingham, AL 35203 Phone +1-205-397-3141 ext. 3149 Fax +1-205-397-3142 [EMAIL PROTECTED] http://www.verarisoft.com/ The information contained in this communication may be confidential and is intended only for the use of the recipient(s) named above. If the reader of this communication is not the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you are not a named recipient or received this communication by mistake, please notify the sender and delete the communication and all copies of it. John Ludlow wrote: Depending on the version of WiX, you would use either tallow (in 2.0.x) or heat (3.0.x) to generate the registration information. This dumps a load of stuff into the registry table, essentially mimicking what self-registration does but within the MSI transaction (meaning it gets rolled back during an error, and removed during an uninstall). On 8/25/06, Eric Fesh [EMAIL PROTECTED] wrote: I've seen it said often enough that use of InstallUtil (and self-registering components in general) in custom actions isn't a good idea. In my google searches, I have found this quote from Rob to the effect that My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. I accept this and want to do the right thing. Problem is, I'm not clear on what the right thing is... I'm trying to repackage an installer a co-worker built with VS.NET because there's some manual setup that needs to be automated once it's been installed. Unfortunately, it's got a number of .NET assemblies that need to be installed (of which one or more are services), and VS.NET uses the InstallUtil hack. How would one go about doing the right thing in this situation? Is this a matter of having to know how to write .NET code that plays nice with Windows Installer? How would one use the ServiceInstall and ServiceControl elements on .NET assemblies instead of InstallUtil? Is that even possible? I don't mean to come off as rude here... I just can't seem to formulate the correct Google search to get at this information. Even pointers on where to look for the information would be useful... And as always, I greatly appreciate any help you all could provide. -- -- Eric Fesh Customer Support Engineer/Software Test Engineer Verari Systems Software, Inc. 110 12th Street North, Suite D103 Birmingham, AL 35203 Phone +1-205-397-3141 ext. 3149 Fax +1-205-397-3142 [EMAIL PROTECTED] http://www.verarisoft.com/ The information contained in this communication may be confidential and is intended only for the use of the recipient(s) named above. If the reader of this
Re: [WiX-users] Search for a GAC component
This sounds like a slightly hard problem. I think you might need to either have a CA that calls GACUTIL -l and tries to capture the output of it somehow to determine if the assembly is there or have a .NET CA that attempts to load the assembly based on its full name and see if that works, returning a value based on that. Ick. Let us know what you come up with. This does sound like a helpful feature for the WiX 3 NetFx extension to support. :) Joe K. - Original Message - From: Kevin Dente To: Bob Arnson Cc: Wix Users Sent: Friday, August 25, 2006 11:49 AM Subject: Re: [WiX-users] Search for a GAC component Sorry, bad choice of words there. I really should have said assembly, not component. The check would be for a third-party assembly, to ensure that the prerequisites for our product our installed before they can run our installer. Sounds like there's nothing there for that right now. Thanks, Kevin On 8/24/06, Bob Arnson [EMAIL PROTECTED] wrote: Kevin Dente wrote: Is there a recommended way to verify that a specific component is installed in the GAC as a pre-requisite for an install? All I'm seeing right now is a FileSearch, and that seems a little hack-ish (since the structure of the GAC is supposedly opaque). When you say component, are you asking about an MSI component or are you looking to detect any assembly regardless of how it was installed? For the former, ComponentSearch will do. There isn't a way to detect assemblies generically -- though if you wanted to write one, I'm sure it would be appreciated.g -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Any idea what might cause this 1603 error or howto figure it out?
Thanks Phil. Google turned that one up, as well as something seemingly relevant from the MS KB, but I couldn't find a way to use any of that advice to fix it either. Pretty vexing. We ran out of time to deal with it, so we just moved on. I'm just hoping it doesn't happen again. Joe K. - Original Message - From: Phil Wilson [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 12:40 PM Subject: Re: [WiX-users] Any idea what might cause this 1603 error or howto figure it out? This is a list of some of the possible causes for 1603: http://support.installshield.com/kb/view.asp?articleid=Q107182 Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Thursday, August 24, 2006 9:22 PM To: Joe Kaplan Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Any idea what might cause this 1603 error or how to figure it out? Joe Kaplan wrote: Nope, nothing much more interesting (although I like those log flags and may use those from now on). '/l*v' is full detail. Adding the '!' causes the file to get flushed after every line; it slows down logging (sometimes a lot) but it guarantees the order's as correct as you can get in a multithreaded app. I tried regmon and filemon too and didn't see any obvious errors in there (although I did see a lot of activity that did not seem to get logged in the msi log such as all my files being deployed and then deleted). I'm pretty close to giving up on this one for now though, so unless you can think of something else, don't worry about it. Thanks for trying. Well, normally there's a more concrete error if the client-side process can't contact the server. But if it helps, blame the gnomes.g -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallUtil considered harmful... What next?
Reading existing performance counters and WMI stuff is one thing. Creating new counters and schema is another. If you just need to read, you are fine. You can assume that the counters you need to read are already there. I think you'd know if you had to install any perf counters or WMI, as there would be PerformanceCounterInstaller classes and such in the assembly that contains your Installer classes. Joe K. - Original Message - From: Eric Fesh [EMAIL PROTECTED] To: Joe Kaplan [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 1:28 PM Subject: Re: [WiX-users] InstallUtil considered harmful... What next? I hope that helps some. Luckily, you aren't doing perf counters or WMI or you would be looking at something much more difficult. :) Actually, I may well be... The service in question is an OS monitoring agent. -- Eric Fesh Customer Support Engineer/Software Test Engineer Verari Systems Software, Inc. 110 12th Street North, Suite D103 Birmingham, AL 35203 Phone +1-205-397-3141 ext. 3149 Fax +1-205-397-3142 [EMAIL PROTECTED] http://www.verarisoft.com/ The information contained in this communication may be confidential and is intended only for the use of the recipient(s) named above. If the reader of this communication is not the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you are not a named recipient or received this communication by mistake, please notify the sender and delete the communication and all copies of it. Joe Kaplan wrote: Tallow won't reverse engineer Installer classes. You'll need to figure out how the service is actually installed and create the authoring for the ServiceInstall elements. That should not be too hard though. You'll also get a lot more functionality this way, as you can set a lot of things that aren't even exposed by the installer classes such as the service restart behaviors and the friendly description. There is a gotcha though with the managed service installer classes. Not only does it create a service in the service database, but it also installs an event source for you in the application log for the service to write to. In order to support this behavior, you'll need to create some WiX authoring to create an Event Source. This is done by setting the proper registry elements in HKLM to create an Event Source. I'm not sure if anyone has created a sample of this or not. You might be able to get tallow to help you here by saving the registry key settings to a file and reverse engineering that into WiX authoring. There is another trick to be aware though, in that .NET event sources use the message DLL that comes with the .NET framework, and the registry will contain a path to that. You may need to make that dynamic based on the version of the .NET framework you are supporting. It could get a little tricky, but should not be too hard. I hope that helps some. Luckily, you aren't doing perf counters or WMI or you would be looking at something much more difficult. :) Joe K. - Original Message - From: Eric Fesh [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 12:06 PM Subject: Re: [WiX-users] InstallUtil considered harmful... What next? So tallow works for .NET assemblies? I thought it would only capture that information from COM objects... Or do I need to go to 3.0.x for that? I'd been holding off upgrading until 3.0 stabilized, but I may not have a choice... -- Eric Fesh Customer Support Engineer/Software Test Engineer Verari Systems Software, Inc. 110 12th Street North, Suite D103 Birmingham, AL 35203 Phone +1-205-397-3141 ext. 3149 Fax +1-205-397-3142 [EMAIL PROTECTED] http://www.verarisoft.com/ The information contained in this communication may be confidential and is intended only for the use of the recipient(s) named above. If the reader of this communication is not the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you are not a named recipient or received this communication by mistake, please notify the sender and delete the communication and all copies of it. John Ludlow wrote: Depending on the version of WiX, you would use either tallow (in 2.0.x) or heat (3.0.x) to generate the registration information. This dumps a load of stuff into the registry table, essentially mimicking what self-registration does but within the MSI transaction (meaning it gets rolled back during an error, and removed during an uninstall). On 8/25/06, Eric Fesh [EMAIL PROTECTED] wrote: I've seen it said often enough that use of InstallUtil (and self-registering components in general) in custom
Re: [WiX-users] Fwd: Detecting if IIS installed after .NET framework
Additionally, if you search the archives of this group, you may be able to find some examples of people who have actually implemented the necesary IIS modifications in WiX to get ASP.NET working. It is essentially just an installation of the ISAPI (if ASP.NET isn't installed at all), installation of the various script maps for the ASP.NET extensions that point to the right version of ASP.NET web service extension, and installation of the ASP.NET web service extension globally (IIS 6 only). If you just want to verify whether a particular virtual directory is set up with ASP.NET, finding a way to check the script maps to see if the aspx mappings are registered might be the way to go. This still sounds a little icky. Best of luck. :) Joe K. - Original Message - From: John Ludlow To: wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 3:57 PM Subject: [WiX-users] Fwd: Detecting if IIS installed after .NET framework Ooops... -- Forwarded message -- From: John Ludlow [EMAIL PROTECTED] Date: Aug 25, 2006 9:56 PM Subject: Re: [WiX-users] Detecting if IIS installed after .NET framework To: Kevin Dente [EMAIL PROTECTED] The reason for this is that when you install the .NET framework, it runs aspnet_regiis if IIS is installed. If not, it skips that step. This tool creates a bunch of registry entries, registering extensions such as .aspx as MIME types. I can't for the life of me remember where exactly they are, but you could use a installation snapshot tool such as InstallWatch ( www.epsilonsquared.com) to get a better idea of what this tool is doing. Hope that helps On 8/25/06, Kevin Dente [EMAIL PROTECTED] wrote: Our Wix-created MSI creates IIS virtual dirs and registers .NET 2.0 as the handler for those web apps. Generally, it works great. However, there's an obscure error condition where if the user has installed IIS after the 2.0 runtime was installed, ASP.NET is not registered correctly in IIS, and the install rolls back with no real indication of why it failed (except in the log). I'd like to put a check in for this condition. Anyone know what exactly to check for? I'm not sure how to detect this state. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallUtil considered harmful... What next?
Bob, you are my hero. :) Here is a WiX fragment produced by tallow of a registry dump of a custom event log and two sources that were produced by a .NET installer class run against the .NET 1.0 from a fairly old VS.NET install project I used in the past with names sanitized: Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment Registry Root=HKLM Key=SYSTEM\CurrentControlSet\Services\Eventlog\Auth Module Registry Name=Sources Value=AuthorizationModule[~]Auth Module[~][~] Type=multiString / /Registry Registry Root=HKLM Key=SYSTEM\CurrentControlSet\Services\Eventlog\Auth Module\AuthorizationModule Registry Name=EventMessageFile Value=C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.0.3705\\EventLogMessages.dll Type=string / /Registry Registry Root=HKLM Key=SYSTEM\CurrentControlSet\Services\Eventlog\Auth Module\Auth Module Registry Name=EventMessageFile Value=C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.0.3705\\EventLogMessages.dll Type=string / /Registry /Fragment /Wix The .NET event source message DLL has the same name in each version of the framework and is probably interchangeable, but you'd probably want some reasonaable way to substitute in the path there. In .NET 2.0, there are more options on the EventLogInstaller class create more full-featured event logs. .NET 1.0 and 1.1 were pretty sparse and missed some core features. Are you planning to add some authoring for custom logs as well as sources? That too would be great! I haven't used WiX 3.0 yet (still using 2.0; was waiting for the green light from Derek), but I'll definitely check this out in the latest build and tell you what I think! It may take a few days. Joe K. - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Joe Kaplan [EMAIL PROTECTED] Cc: Eric Fesh [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, August 25, 2006 9:45 PM Subject: Re: [WiX-users] InstallUtil considered harmful... What next? Joe Kaplan wrote: There is a gotcha though with the managed service installer classes. Not only does it create a service in the service database, but it also installs an event source for you in the application log for the service to write to. In order to support this behavior, you'll need to create some WiX authoring to create an Event Source. This is done by setting the proper registry elements in HKLM to create an Event Source. Interestingly, this week's release of WiX v3 (3.0.2023.0) includes this note in history.txt: BobArnso: Add EventSource strongly-typed authoring to WixUtilExtension Very new, so any feedback would be appreciated. There is another trick to be aware though, in that .NET event sources use the message DLL that comes with the .NET framework, and the registry will contain a path to that. You may need to make that dynamic based on the version of the .NET framework you are supporting. It could get a little tricky, but should not be too hard. Could you post what your registry looks like with that? I wasn't able to find any examples of managed event sources on any of my dev machines. -- sig://boB http://bobs.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Stop IIS on uninstall
What I've done in the past is just include a ServiceControl element in the component: ServiceControl Id=iis5ServiceControl Name=w3svc Start=both Stop=both / You might change the Start and Stop attributes to get what you want. I was installing an ISAPI filter. The schema might be a little different in WiX3, but you get the idea. You shouldn't need your own CA for this--the built in one in WiX should do what you want. You might also need to put a condition on it to ensure that IIS is installed or something. Joe - Original Message - From: John Hidey (The C# Junkie) To: wix-users@lists.sourceforge.net ; wix-devs@lists.sourceforge.net Sent: Thursday, August 24, 2006 9:55 AM Subject: [WiX-users] Stop IIS on uninstall All How to I ensure that IIS gets stopped on and uninstall. I'm installing a site (web service) and also a windows service. The windows service uses the web service that I installed and the windows service is started on install. When uninstalling, the web services bin directory and its contents are left behind. If I manually stop IIS and then uninstall everything is fine. Can I have the uninstall process stop IIS during uninstalled and if so how do I go about this. Thanks in advance everyone. John - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Enterprise Library MSM at GotDotNet
I doubt you are missing anything obvious. I just noticed it on GDN and thought I'd point it out to the people using EL on the list. I'm still convinced that a better installer for EL could be made that actually did the instrumentation features declaratively, but it is a starting point and might help someone solve an immediate need right away. I'm not sure how the installutil thing works on the GACed assemblies. I was under the same impression as you. There must be something missing here. Joe K. - Original Message - From: Rob Mensching [EMAIL PROTECTED] I looked into the MSM a bit. If I understand the code correct, it appears that I was wrong and you can call InstallUtil on GAC'd assemblies (although reaching into the GAC to SelfReg a file seems even more sketchy than SelfReg normally feels smile/). However, it doesn't appear that the Merge Module supports uninstall at all. Am I missing something obvious? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Enterprise Library MSM at GotDotNet
Since this question has come up recently, I thought it worth mentioning here that someone has already created such a beast at gotdotnet: http://gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=e14336d7-1b7b-4287-8e20-51fe07cb12aa It uses installutil. Joe K. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Have any of you seen WixTrim?
This is a pretty neat looking GUI editor for WiX. http://ny.firetongue.com/twix/download/ Joe K. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
I used a similar approach to deal with migration of an app that was originally built with non-MSI WISE and then did the same basic thing again when my first MSI version was (mistakenly) installed per-user instead of per-machine. AppSearch for traces of the old stuff and LaunchCondition that prevents install until the old stuff is gone. Sad (especially the per-user goof!), but basically functional. Joe K. - Original Message - From: Rob Hamflett [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Friday, July 28, 2006 3:24 AM Subject: Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller When we moved over to MSI we had to deal with existing InstallShield installs. I got round the problem by looking in the registry for the key InstallShield writes under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall using a RegistrySearch. I then used the set property as the condition for a custom error telling the user to uninstall the existing version. This might seem crude, but it does the job and each customer only has to do it once. Rob Rick Glos wrote: Hello, I’ve spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks updating our installer (we have a custom C# installer). I can see our *new* customers instead using a new .msi for later versions (5.5, 6.0, etc). What do I do about our existing customers when they wish to upgrade? They’ve never installed originally with a Windows Installer. How do I get them on the same track? Thanks for any advice, Rick Glos - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] GAC and call Custom Action
This is actually the primary reason why I started the thread about WiX and support for installation of Windows instrumentation features. I too use Enterprise Library and have suffered with some of these very issues. All EL does is install some event sources, performance counters and WMI schema for instrumentation. In order to do this in WiX, it varies from not too bad to . Event logs are really just a set of registry entries and are pretty straightforward. .NET event sources (for the most part) always use the messages dll that comes with the .NET framework, so you don't even need to install a messages dll. You just need to point to the existing one. The rest of the registry stuff is easy. It is actually easy to do a better job than .NET does at creating event sources this way, especially with .NET 1.1, as you get more control over how they are created and behave. Perf counters are harder. WiX has support for perf counters and has some documentation on how to do them. I think we also determined that .NET perf counters can be installed this way. The problem is that the .NET perf counter install mechanism actually dynamically generates some of the files (the .h and .ini), and there isn't a very straightforward way to harvest those that I know of besides installing with the installer classes once and finding the resulting files. It is a little ugly. I had a suggestion for Derek that it would be cool if Heat could reverse engineer a perf counter installer to make it easier to generate the authoring for this stuff. WMI seems to be a bit of a black hole. I've never bothered to reverse engineer those installer classes to see what they actually do, but it does not seem to be very well understood. One other thing that could be done for EL specifically would be to harvest all of the installer classes from the actual EL source (which they give you) and create your own little assembly that just has the installer stuff in it, but gets installed to the file system instead of the GAC. You'd still be using InstallUtil to install the various components, but you at least wouldn't have the GAC problem. Ideally though, you'd just create the appropriate authoring and do it that way. And BTW, a wixlib or merge module for EL would be a nice contribution to the EL community. I think the EL team at Microsoft actually looked at WiX for a while, as I know Peter Provost was posting here and was asking questions (although that could have been for the Smart Client block instead), but it doesn't look like they ever decided to package things as an MSI for whatever reason. Joe K. -Original Message- From: Rob Mensching [mailto: [EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:01 AM To: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right. The problem is that Assemblies going to the GAC aren't committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing. My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway? From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:36 PM To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John -- csharpJohn Hidey/csharp[EMAIL PROTECTED] -- csharpJohn Hidey/csharp[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list
Re: [WiX-users] WiX and web applications
Tallow (for WiX 2.0) and Heat (for WiX 3.0) are the standard ways of creating WiX authoring based on existing data like directories full of files and such. Note that to do this the right way is somewhat non-trivial. The thing about WI is that you shouldn't be changing component GUIDs all the time for files that you've previously installed, so you don't necessarily want to regenerating your authoring from scratch every time. As I recall, Tallow sidesteps this issue by not creating GUIDs for your components and making you do that by hand (or with some sort of script you write). It isn't an easy problem to solve. Another thing you might consider doing is generating the authoring dynamically from the existing source for the initial build and then just tweaking the authoring by hand thereafter. Typically, this isn't too hard to keep on top of if you do it as you go. Other people on this list have created some really sophisticated build systems that do automate this task while keeping track of existing components and such. There is probably a significant investment in time to get something like this, but it might pay off. Perhaps someone else will share their solution. The email archives probably have some pointers as well. Joe K. - Original Message - From: David Keaveny To: wix-users@lists.sourceforge.net Sent: Thursday, July 27, 2006 8:30 PM Subject: [WiX-users] WiX and web applications Is there an equivalent in WiX to Visual Studio 2003's web deployment project? In other words, a simple way of adding all the .ascx, .config, .jpg etc files to my MSI without having to hand-code each individual entry? VS can take the output from a project, and build an MSI from that; I don't see an obvious way to do it in WiX. I've had no problem with WiX for packaging Windows services, since the file counts are relatively low; but my web application contains hundreds of files, and is under constant development, so there must be some way of automating things. Regards, David - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features?
That's good to know. It sounds like this would be easy to do in WiX with explicit Registry tags and would be not that much work to add explicit schema support for WiX as well (like event log stuff). No CA needed or even any custom tables. I suggest someone (John? :)) adds a feature request for this to go along with my feature requests for event log, perf counter and WMI support. Joe K. - Original Message - From: John Vottero [EMAIL PROTECTED] To: Bob Arnson [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 7:32 AM Subject: Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features? I posted this exchange and a number of questions on the PowerShell newsgroup and here's the response: Posting on behalf of the feature developer. Does the PowerShell team feel that PSSnapin is suitable for professional Cmdlet installers? Or, is it intended to be a tool for developers to use to quickly get a Cmdlet working? This is mostly tool for developer to get the cmdlet working. Release setup should set the registry keys explicitly. Does the PSSnapin do anything other than creating registry entries? No. Will the inner workings of PSSnapin be documented? It just sets series of registry keys. We need to document the keys which vendors need to set for registering snapins. I will open a bug for this. Will the PowerShell team create a WiX extension? There is no plan for V1. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Who uses Installer classes for custom CAs? (was Re: Should WiX add support for installingWindowsinstrumentation features?)
As the person who started this thread, I never had any intention of dragging up the installer classes are evil thread. Sorry about that. My only real intent was to suggest the creation of WiX alternatives to the obvious stuff. However, I am curious about this now. For the people who use installer classes, how many people use them with the built-in Installer-derived classes (event log, perf counter, WMI, service install), and how many use them for implementing custom CAs for doing tricky product-specific stuff? Like I said before, I'm not morally opposed to managed code CAs and I see them as potentially must more robust and powerful than the script CAs that already exist. There is also nothing that prevents them from being declarative and table-driven and all that other goodness that defines a well-designed CA. However, I wonder if the Installer class is the blueprint I'd use for a good design, or if I'd keep the attribute model for locating the classes but use something more more simple (or an interface driven design, so I don't have to use someone else's base class)? The composite pattern that Installer implements is kind of interesting, but I'm not sure that a feature that allows creating nested trees of installers is also a good thing or not from the MSI perspective. What would make a good managed CA? Joe Kaplan - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: John Vottero [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Sent: Sunday, July 23, 2006 9:15 PM Subject: Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features? John Vottero wrote: Reposting this message at regular intervals (either manually or automatically) does no good whatsoever. That doesn't change the fact that it's a well-written message. If there are problems with the Installer based classes they should be reported to Microsoft so that the problems can be fixed. Easy fix: Make Installer sealed.g Running arbitrary code during installation is bad. It's self-reg, except worse. The entire design of MSI is based on the idea of describing your setup and letting MSI interpret the description. Running code is bad and should be avoided whenever possible. If you read the documentation for the Installer classes, it never implies that they are merely developer hacks that shouldn't be used in a production environment. In fact, Visual Studio provides the InstallUtilLib custom action to call Installer classes from an MSI. True. And it's an excellent example of why many folks suggest avoiding .vdproj. Don't all custom actions have the potential to break reference counting? Why use the reference counting argument against one custom action but not others? Yes they do -- and QuietExec is often abused. But there's a difference between running arbitrary code in a CA and running a well-designed CA whose operations are described via data in tables in the package. Quite simply, it's hard to do good CAs. Even if you were to argue that there's too much coding overhead to do declarative setup, it's hard to argue against uninstall and rollback CAs. Yet often it's exactly that kind of resilience that people skip when writing one-off CAs. We see it all the time, even inside Microsoft. (That's why but VS does it isn't much of an excuse.) Installer classes have way too much momentum and too many supporters within Microsoft to be ignored, it's time for WiX and Windows Installer to figure out how to support them. Or lobby the supporters to come to their senses. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] UI authoring question
Hi all, This isn't necessarily a WiX question per say (althoughI am authoring in WiX obviously), but I thought I'd give this a shot. I'm trying to add a dialog to my UI sequence during install that provides the user the ability to enable a CA to migrate some settings from an existing text file on the file system to a file installed by the installer. I was hoping to use the existing Browse dialog that is tied to the standard feature tree dialog to provide UI to select the file. However, based on what I've read so far in the MSDN docs, it looks like the browse dialog is tied to modifying the installable location of a feature. I don't have a feature per say for this CA, so I don't really want this. I was hoping to just capture the result of the browse dialog in a property and pass it to the deferred CA later if a file was selected. MSI UI = hard. :( Thanks in advance for any hints. Joe K. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Should WiX add support for installing Windows instrumentation features?
Hi all, Does anyone think that WiX should try to add explicit support for installing Windows instrumentation features such as event logs, performance counters (custom .NET ones) and WMI schema? It seems to me that one of the primary attractions for using installutil.exe for .NET-based apps is that there are very easy ways to do these things with installer classes in .NET and it isn't as straightforward or even possible to do that in WiX. I realize that event log sources are just a bunch of registry entries and maybe a message dll file, but it would be convenient if there was explicit schema in WiX to support this. I expect it would be easy to translate that schema internally into the appropriate registry and file table entries to make this work. My understanding is that perf counters, especially the .NET ones, are tougher. I do realize that there is already some support in WiX for native perf counters, so perhaps this could be extended? I don't really know anything about installing WMI schema, so I don't know what's involved with making this happen. I also think it would be interesting if Heat supported reverse engineering WiX authoring for they types of installer classs embedded in .NET assemblies, similar to the way it can harvest stuff like COM registration now. I don't mention Windows services in this list as I'm pretty happy with the support these things have in WiX so far. Reverse engineering service installer classes into WiX authoring would be cool though. Thoughts? I started this discussion with Derek offine a few months ago and he asked me to post here. I just finally got around to bringing up with the community. Joe Kaplan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] (OT) Screwed up on per machine install; what should I do?
Hi guys, This is more of a general Windows Installer issue than a WiX issue, butI thought I'd solicit the feedback of the list as many of you will certainly have useful opinions. Essentially, last year when I was still quite newwith WiX and WI,I built an installer that really really should have been per machine and should have specified ALLUSERS=1, but I didn't know about that and got a per user install instead. The software installs an IIS add-on and is definitely machine specific. Now, I'm having the problems you would expect with major upgrades and even simple uninstalls, in that only the user who installed the software can uninstall it or detect that it is installed properly. What would you do? I plan to change future versions to do per machine installs, but it would be nice if I had a way to fix the mess I've created. This software is for internal consumption and hasn't been installed broadly, so I have a reasonable chance of chasing down most of the installs. All insights are greatly appreciated. Joe Kaplan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
