tag:blogger.com,1999:blog-985159635193633235.post797996196305832972..comments2024-03-25T00:30:02.127-07:00Comments on ISWIX: Software EntropyChristopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-985159635193633235.post-31663217808884938232011-02-14T07:16:44.596-08:002011-02-14T07:16:44.596-08:00Chris, I largely agree with your post here, but i&...Chris, I largely agree with your post here, but i'm interested in one of the items you specifically call out - osql. We use SQLCMD, which is by and large the same.<br><br>I understand the rationale for the rest - don't implement something as a CA which is going to require its own unique transactional behavior when MSI can do that for you. <br><br>But sadly, MSI doesn't provide you with anything for SQL - we've found it to be an entirely roll-our-own process. Granted, I can use a managed CA instead of SQLCMD, but I perceive that as shades of grey on the same ultimate problem. If there's something large we're missing out on, enlighten the masses, please! :)JohnWnoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-48294257865428689982011-02-14T07:34:56.392-08:002011-02-14T07:34:56.392-08:00I don't know what tools you use or what databa...I don't know what tools you use or what database engine you are connecting to so I'll just say in our environment we use InstallShield to handle our SQL Script processing. Basically they are well tested data driven custom actions written in unmanaged code and support MSSQL, Oracle and MySQL. WiX provides a similiar concept except that they only upport MSSQL.<br><br>With InstallShield the IDE exposes the concepts of SQL Connection/Requirements, SQL Script and SQL Text Replace. This maps to 7 custom tables that allow you to describe the SQL story for the installer.<br><br>I call these types of patterns 'quasi-standard actions' as the infrastructure is developed and maintained to high standards by someone else. I only have to focus on the details related to the setup I'm working on.<br><br>http://kb.flexerasoftware.com/doc/Helpnet/installshield12helplib/SQLServer.htm<br><br>http://wix.sourceforge.net/manual-wix3/sql_xsd_index.htm<br><br>So basically I would change your rule to include things that your tools can do for you not just what MSI can do for you.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-15829847191635873212011-02-14T07:56:56.719-08:002011-02-14T07:56:56.719-08:00I also largely agree with what you said IF everyth...I also largely agree with what you said IF everything "further down the process" is dependent on what has been built "upstream" in the build process - and that may be the actual scope of your build process.<br><br>Where I'm at now, the install build is separate from the core product source code builds. It contains both Windows Installer packaging builds, the generation of Linux RPM and tarballs, as well as the creation of ISO and download files. Our build engineers don't want me stopping the entire build because an MSI package doesn't build properly. They want the entire build to run to completion and then report all build failures so that the MSI, Linux, and media portions of the build are always run. Basically, they don't want an MSI break to stop the build process and potentially hide the fact that there's also a problem with either the Linux or media portions of the build that wouldn't be found otherwise because an "upsteam" part of the build stopped the overall build process.Colby Ringeisenhttp://www.blogger.com/profile/08696301684260588101noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-52620117316897923012011-02-14T08:47:52.199-08:002011-02-14T08:47:52.199-08:00Chris, thanks. We use SQL 2008 and InstallShield, ...Chris, thanks. We use SQL 2008 and InstallShield, but we actively stay away from anything proprietary, to the point that we'd rather roll our own that find out we have vendor lockin - at least, beyond MSFT.JohnWnoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-70506373858208882822011-02-14T09:13:20.182-08:002011-02-14T09:13:20.182-08:00I guess I'm a little confused by the proprieta...I guess I'm a little confused by the proprietary comment and the fact that you use InstallShield to build the install. It seems like you are saying we'd rather not have functionality that we paid for because one day we might want to use something else so instead we'll just go write our own and pay for it twice.<br><br>Eitherway The WiX SQL stuff is ultimatly just some custom actions and custom tables so it's really easy to 'borrow' it and use it inside InstallShield. It's FOSS so shouldn't be any concerns there.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-55438863917774555172011-02-14T10:09:59.281-08:002011-02-14T10:09:59.281-08:00My thought against using the InstallShield CA'...My thought against using the InstallShield CA's for database tasks is that it creates a new system (and point of failure) that not everyone understands. <br><br>My preference is to use the same tool that developers/technical support/etc. are using to build the databases so we're all able to troubleshoot any issue. <br><br>We built a custom, relatively easy-to-use tool in managed code that I call in a managed CA, but if the process is a batch script that calls SQLCMD I would use that in 'black box' form to avoid having InstallShield have its tentacles in yet another area.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-19412682566193026702011-02-14T10:35:03.841-08:002011-02-14T10:35:03.841-08:00Well, you do have a pattern so that's good. N...Well, you do have a pattern so that's good. Now imagine someone coming up with a competing pattern and then injecting it into the MSI. How would you feel about that? :-) That's kind of the real point of this post.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.comtag:blogger.com,1999:blog-985159635193633235.post-67824936068156483852011-02-14T18:58:24.418-08:002011-02-14T18:58:24.418-08:00Chris, what I mean by proprietary is that we use i...Chris, what I mean by proprietary is that we use installshield primarily as a way of manipulating the MSI. Should we choose to go to Wise or even WIX, we could do so without the baggage of having to find a replacement for any vendor's IP (again, other than MS). What one sees as paying for twice, another sees as insurance. :)JohnWnoreply@blogger.com