I've been spending a lot of time lately thinking about use cases for source file location abstractions. Some tools like Visual Studio Deployment Projects provide no abstraction and other tools such as InstallShield provide abstractions (Path Variables) based on environment variables, registry values and/or command line arguments.
Then there is Wix can use different types of compiler inferences and preprocessor variables and/or extensions.
Obviously this can get very complicated so I'm curious, what is your favorite way to roll and why? What do you need and what could you live without?
Historical archive 2003-2016
Monday, August 24, 2009
Sunday, July 26, 2009
Maybe I Should Roll My Own Part II
Just over a year ago I played around with .NET object serialization for a day and came up with a simple little program that could build a WiX element tree, set the attributes and write the XML out. I blogged about it here.
Since then I've taken a .NET 3.5 / WCF / WPF / LINQ class and I now realize that LINQ to XML is perfect for this task. For example, consider the simple example of a tool that can switch between designer view and xml view. It can all be done in 10 simple steps:
1) Create a couple of tab pages. Put your designers on one and a richtext box on another.
2) Use XElement.Load() to load the WiX document into an in memory object model.
3) Use XElement.ToString() and pass it off to the RichTextBox.
4) Create an event handler and wire it up to the XElement changd event so that any time something changes in the object model you can refresh the XML view.
5) Use LINQ to query the object model and feed the data into your UI components.
6) Use your UI components to manipulate the objects using LINQ.
7) Wire up the RichTextBox TextChanged event to refresh your UI if the XML changes.
8) Use XElement.Save() to save your changes.
9) Use visual studio integration to wire the tool up to Votive. The concept is to not reinvent the wheel. Just edit the WXS/WXI files out of process and let votive reload the documents after you save your changes.
10) Profit! ( Sorry, Slashdot joke )
Sure, there's a lot of work to do it all correctly but the basic pattern is actually quite simple. So here's a couple screenshots of a (mostly working) program I was able to write in one day.
Since then I've taken a .NET 3.5 / WCF / WPF / LINQ class and I now realize that LINQ to XML is perfect for this task. For example, consider the simple example of a tool that can switch between designer view and xml view. It can all be done in 10 simple steps:
1) Create a couple of tab pages. Put your designers on one and a richtext box on another.
2) Use XElement.Load() to load the WiX document into an in memory object model.
3) Use XElement.ToString() and pass it off to the RichTextBox.
4) Create an event handler and wire it up to the XElement changd event so that any time something changes in the object model you can refresh the XML view.
5) Use LINQ to query the object model and feed the data into your UI components.
6) Use your UI components to manipulate the objects using LINQ.
7) Wire up the RichTextBox TextChanged event to refresh your UI if the XML changes.
8) Use XElement.Save() to save your changes.
9) Use visual studio integration to wire the tool up to Votive. The concept is to not reinvent the wheel. Just edit the WXS/WXI files out of process and let votive reload the documents after you save your changes.
10) Profit! ( Sorry, Slashdot joke )
Sure, there's a lot of work to do it all correctly but the basic pattern is actually quite simple. So here's a couple screenshots of a (mostly working) program I was able to write in one day.
Friday, July 10, 2009
Austin meets Heat
Whew it's been hot in Texas lately. AFAIK it's been 100f+ for the last several weeks with no end in sight. Accordign to weather data, the max temp for last month was 106f with an average of 99f and a min of 90f. This month we are tracking for 106f, 102f and 93f. Whew.
So what does this have to do with setup? Well, I've been playing with WiX's Heat a lot lately. I got tired of running heat from a command prompt and then repeating my same cleanup tasks over and over so I decided to automate it a little with a C# winforms application. While I was at it, I added an interesting feature that I thought was a bit gimmicky at first until I started getting feedback on how cool it was.
What did I add? Simple: a FileSystemWatcher that monitors a directory for updates and then dynamically regenerates the wix document, cleans it up and then refreshes the display to show the new WiX code. With multiple monitors you just stage the dirctory on one screen while watching the program write the code for you on the other screen.
It's really a simple concept but everyone finds it quite informative. Once you have what you want you just cut and paste it into your Votive project.
So I was going to call this new tool "Blow Torch" but when I asked a coworker who is also named Chris how he liked the name he just said that he'd call it Austin.
Austin? Hmmm.... Sure, Why not? I like the sound of it.
So the hear finally destroyed our HVAC plant at work and everyone was sent home for the weekend early. This gave me a few hours to work and now I have Austin built and packaged. For now I'm just going to tease everyone with a screenshot but hopefully in a week or so I'll pass all of quality checks and release this tool for others to play with. That process might go faster if people actually bug me for a copy. ( Hint Hint! )
BTW, in case your wondering why the screenshot has a refresh button, I'm working on making it a feature to scan automatically or manually.
Saturday, July 4, 2009
WiX 3.0 Ships
Wix 3.0.5419 has been promoted to Production Stable quality on SourceForge.net and can be downloaded here.
I've been fairly critical of WiX over the years but today marks a turning point in that believe. With the release of 3.0, many features are now in place that begin to make a really strong case for seriously considering the use of WiX over legacy tools. While WiX still lacks a 1st class bootstrapper/chainer and proper IDE GUI design tools that other tools have, I believe that the core foundation of WiX is much better positioned for the future.
Hopefully we'll see WiX 3.5 ( featuring Burn )in 6-12 months to address these concerns. I also hope to see Votive explode into a fully featured visual studio add-in. Finally, I expect a market of WiX based designer tools to appear. Hopefully WiXAware 3.0 will be released ( and even more hopefully that it actually work! ) and I also anticipate InstallShield will eventually bring tools to market based on WiX. IMO it is inevitable and the InstallShield brand as a packaging tool will not survive if they do not.
So there it is: WiX 3.0 is shipped and I now see the road that I will travel towards over the coming months. With dozens of installers composed from hundreds of merge modules and tens of thousands of files, it'll take us awhile to get there from sure. But I am no convinced that the effort will be worthwhile.
I've been fairly critical of WiX over the years but today marks a turning point in that believe. With the release of 3.0, many features are now in place that begin to make a really strong case for seriously considering the use of WiX over legacy tools. While WiX still lacks a 1st class bootstrapper/chainer and proper IDE GUI design tools that other tools have, I believe that the core foundation of WiX is much better positioned for the future.
Hopefully we'll see WiX 3.5 ( featuring Burn )in 6-12 months to address these concerns. I also hope to see Votive explode into a fully featured visual studio add-in. Finally, I expect a market of WiX based designer tools to appear. Hopefully WiXAware 3.0 will be released ( and even more hopefully that it actually work! ) and I also anticipate InstallShield will eventually bring tools to market based on WiX. IMO it is inevitable and the InstallShield brand as a packaging tool will not survive if they do not.
So there it is: WiX 3.0 is shipped and I now see the road that I will travel towards over the coming months. With dozens of installers composed from hundreds of merge modules and tens of thousands of files, it'll take us awhile to get there from sure. But I am no convinced that the effort will be worthwhile.
Thursday, June 25, 2009
Two Blog Articles on Windows 7 Compatibility Shims Every Install Developer Should Be Aware Of
Both of these were referenced on Stefan's InstallSite blog but I thought I'd reference them too. Both blog articles are on Chris Jackson's Semantic Consonance blog:
Wednesday, June 24, 2009
DRM Activation Question
ShadowWolf recently commented:
This comment made me wonder, is this true? I work in an environment with airgaps around our network connections for security purposes and I can't think of a single tool that we use besides InstallShield that requires activation and/or reactivation.
Sure, Windows does (once) but they also offer a volume license key that doesn't require activation. Microsoft Office works the same way. Visual Studio, TFS and so on. Even our IBM/Rational products don't give us this problem and trust me, those are some pretty darn expensive tools. The only product that we use that I can think of is Robohelp.
So I'm curious, what are some of the products my readers use that require activation?
Activation ( and reactivation ) are pretty par for the course in the business tool world from what I've seen. I don't know that anyone really "likes" it, but it definitely serves a legitimate purpose.
This comment made me wonder, is this true? I work in an environment with airgaps around our network connections for security purposes and I can't think of a single tool that we use besides InstallShield that requires activation and/or reactivation.
Sure, Windows does (once) but they also offer a volume license key that doesn't require activation. Microsoft Office works the same way. Visual Studio, TFS and so on. Even our IBM/Rational products don't give us this problem and trust me, those are some pretty darn expensive tools. The only product that we use that I can think of is Robohelp.
So I'm curious, what are some of the products my readers use that require activation?
Thursday, June 18, 2009
InstallShield 2010 vs WiX 3.0
It's been no secret that I've favored InstallShield over WiX for many years. I've used InstallShield products since 1997 and I've shipped hundreds of installers using this versatile tool. InstallScript, XML Locator, Setup Prerequisites, Multiple Instance Support, COM Extraction, MySQL, Dialog/Control editors, Product/Release configurations and Component authoring wizards/views have made me a very productive and profitable person over the years.
Unfortunatly, there are also things I dislike about InstallShield. The DRM activation ( and now reactivation with IS2010 ) is horrible, difficulty in trying to get updates in an offline scenario (which we always are for security purposes), the random crashes, the horrible DTD/XML transformation, sequenced primary keys and of course, the removal of the stand alone build from Professional and totally useless collaboration tool combined with the really high price of the product.
If I'm hurting anyones feelings, I'm sorry. It's hard for me too since I've used this tool for so long and I do believe it's still a very good tool for many development shops. Just not for mine.
At my day job, I lead a team of 4 ( going on 6! ) setup developers. We collectively maintain dozens of installs that generate and consume hundreds of merge modules from a software product line. Our typical installer ships 10,000 - 15,000 files and includes countless databases, services, webservices and many chained packages of programs that we integrate with. All of this occurs on many active branches.
Unfortunatly InstallShield with it's DTD XML and incremented primary keys just doesn't work well in this environment. Merging branches back together in clearcase is a nightmare since you always end up with unresolved conflicts. Enter WiX. The XSD XML is 95% smaller then DTD XML and is way more expressive. Also thanks to deterministically unique primary keys and guids, changes done on multiple branches can actually merge back together easily.
The problem with WiX of course is the lack of gui designer abstractions and visualizations. Fortunatly I finally have a solution for that. I've recently had an internal tools developer assigned to me to come up with our own collaboration tools to sit on top of votive. Once complete we are hoping to once again try decentralized setup development. I'm not sure it'll work ( it didn't last time ) but we are going to give it a try again. The reality is our environment is growing so fast that we need to retool and try new strategies to keep up. Hiring more and more people just doesn't seem to work anymore.
Unfortunatly, there are also things I dislike about InstallShield. The DRM activation ( and now reactivation with IS2010 ) is horrible, difficulty in trying to get updates in an offline scenario (which we always are for security purposes), the random crashes, the horrible DTD/XML transformation, sequenced primary keys and of course, the removal of the stand alone build from Professional and totally useless collaboration tool combined with the really high price of the product.
If I'm hurting anyones feelings, I'm sorry. It's hard for me too since I've used this tool for so long and I do believe it's still a very good tool for many development shops. Just not for mine.
At my day job, I lead a team of 4 ( going on 6! ) setup developers. We collectively maintain dozens of installs that generate and consume hundreds of merge modules from a software product line. Our typical installer ships 10,000 - 15,000 files and includes countless databases, services, webservices and many chained packages of programs that we integrate with. All of this occurs on many active branches.
Unfortunatly InstallShield with it's DTD XML and incremented primary keys just doesn't work well in this environment. Merging branches back together in clearcase is a nightmare since you always end up with unresolved conflicts. Enter WiX. The XSD XML is 95% smaller then DTD XML and is way more expressive. Also thanks to deterministically unique primary keys and guids, changes done on multiple branches can actually merge back together easily.
The problem with WiX of course is the lack of gui designer abstractions and visualizations. Fortunatly I finally have a solution for that. I've recently had an internal tools developer assigned to me to come up with our own collaboration tools to sit on top of votive. Once complete we are hoping to once again try decentralized setup development. I'm not sure it'll work ( it didn't last time ) but we are going to give it a try again. The reality is our environment is growing so fast that we need to retool and try new strategies to keep up. Hiring more and more people just doesn't seem to work anymore.
Subscribe to:
Posts (Atom)