The WiX Toolset team did their first v3.10 weekly release: v3.10.1124.0
Weekly releases are basically developer beta test builds and are not final releases. This release is interesting to me because it includes Visual Studio 2015 support. I've tested this build with VS2015 Preview and IsWiX 2.5.14324.3 and I find everything is working just fine. I can now relax knowing that I'm well ahead of the curve in supporting the next release of Visual Studio.
Tuesday, November 25, 2014
Thursday, November 20, 2014
IsWiX 2.5.14324.3 Released
When IsWiX was first developed, we targeted Visual Studio 2008. I dove into VS extensibility trying to figure out how to get the addin story to work. I got it to work but the solution left a little bit to desire. The first problem was very embarrassing: the icon was a big smiley face.
The API / method that registered the addin with the menu supported 2 techniques. One was an orginal index from a Microsoft Office icon library and the second involved creating a resources dll. I didn't have the skill or the time to go down the second road so I stuck with the smiley face telling myself that I'd go back and fix it. As the days, weeks, months, years went by I failed to do so.
The second problem was that occasionally Visual Studio would just decide to drop the addin from the menu. You had to run a devenv /resetaddin command to get it back.
Today a new version of IsWiX is released that solves these problems. I've scoped the "old" addin to VS 2008, 2010 and 2012 and created a "new" addin using VSIX extension that targets VS 2013 and 2015. This new extension registers IsWiX in Help | About and Tools | Packages and Extensions and gives a nice blue flame icon with the new text "Launch IsWiX" under the tools menu.
That's right, IsWiX now supports VS2015! There is a caveat though. The IsWiX multiproject solution templates ride on top of WiX infrastructure. WiX as of v3.9 does not yet support VS2015 so although IsWiX has correctly registered with VS2015 the project templates will not show up until WiX is ready to support VS2015. We are way ahead of the curve though so I expect all of this will come together prior to VS2015 shipping next year.
I'm sorry for letting the yellow icon live for so long and for doing back to back weekly releases. I finally get a fired up on this issue making it now or never.
The API / method that registered the addin with the menu supported 2 techniques. One was an orginal index from a Microsoft Office icon library and the second involved creating a resources dll. I didn't have the skill or the time to go down the second road so I stuck with the smiley face telling myself that I'd go back and fix it. As the days, weeks, months, years went by I failed to do so.
The second problem was that occasionally Visual Studio would just decide to drop the addin from the menu. You had to run a devenv /resetaddin command to get it back.
Today a new version of IsWiX is released that solves these problems. I've scoped the "old" addin to VS 2008, 2010 and 2012 and created a "new" addin using VSIX extension that targets VS 2013 and 2015. This new extension registers IsWiX in Help | About and Tools | Packages and Extensions and gives a nice blue flame icon with the new text "Launch IsWiX" under the tools menu.
That's right, IsWiX now supports VS2015! There is a caveat though. The IsWiX multiproject solution templates ride on top of WiX infrastructure. WiX as of v3.9 does not yet support VS2015 so although IsWiX has correctly registered with VS2015 the project templates will not show up until WiX is ready to support VS2015. We are way ahead of the curve though so I expect all of this will come together prior to VS2015 shipping next year.
I'm sorry for letting the yellow icon live for so long and for doing back to back weekly releases. I finally get a fired up on this issue making it now or never.
Saturday, November 15, 2014
Development using Free Tools
Three and a half years ago, I wrote an article titled Installation Collaboration Workflows using Free Tools. I'd like to add a few comments based on recent events.
Over the past couple of years Microsoft has been doing some really cool things to help out the community. The first was making Visual Studio Online ( Cloud hosted Team Foundation Server ) free to teams of 5 or less. This is a really big deal because now you have "process in a box" infrastructure provisioned in minutes that features high availability, monitoring and disaster recovery all for the low, low price of.... FREE!
In the past Microsoft had Visual Studio Express for free but it lacked the ability to extend the IDE. At the same time they had the Visual Studio Shell which did. This created a way of developing .NET applications and packaging installers for them but in a very disjointed manner. Now Microsoft has released Visual Studio Community Edition which is on par with Visual Studio Professional. Now you can do both your application coding, installer coding and connect to that shiny TFS cloud instance for the low, low price of.... FREE!
Additionally Microsoft has open source the .NET core libraries. Awesome!
Windows Installer XML has been free and open source for 10 years. IsWiX has been free and open source for nearly 5 years. Combine all of above and a independent consultant like myself now has everything needed to be productive without spending a whole lot of money. A laptop, internet connection and aguest bedroom corner office is all you need to either start a business or give back to your favorite open source project.
Looking back over the past year, I've written 95% of my installers using WiX and 5% using InstallShield. I still like InstallShield but the ROI just isn't there for most of my customers. I've been approached by many customers who were about to purchase InstallShield and after a needs analysis I explained to them that I could author their MSI using WiX for a fraction of the cost of the InstallShield license alone. To do setup development collaboration with InstallShield you have to invest thousands of dollars in multiple licenses of DRM laden proprietary software. To do it using WiX and IsWiX is free and integrates into a development ecosystem (Visual Studio) already understood by your customer.
Thanks for reading. Please feel free to reach out to me if you want more information on this topic.
Over the past couple of years Microsoft has been doing some really cool things to help out the community. The first was making Visual Studio Online ( Cloud hosted Team Foundation Server ) free to teams of 5 or less. This is a really big deal because now you have "process in a box" infrastructure provisioned in minutes that features high availability, monitoring and disaster recovery all for the low, low price of.... FREE!
In the past Microsoft had Visual Studio Express for free but it lacked the ability to extend the IDE. At the same time they had the Visual Studio Shell which did. This created a way of developing .NET applications and packaging installers for them but in a very disjointed manner. Now Microsoft has released Visual Studio Community Edition which is on par with Visual Studio Professional. Now you can do both your application coding, installer coding and connect to that shiny TFS cloud instance for the low, low price of.... FREE!
Additionally Microsoft has open source the .NET core libraries. Awesome!
Windows Installer XML has been free and open source for 10 years. IsWiX has been free and open source for nearly 5 years. Combine all of above and a independent consultant like myself now has everything needed to be productive without spending a whole lot of money. A laptop, internet connection and a
Looking back over the past year, I've written 95% of my installers using WiX and 5% using InstallShield. I still like InstallShield but the ROI just isn't there for most of my customers. I've been approached by many customers who were about to purchase InstallShield and after a needs analysis I explained to them that I could author their MSI using WiX for a fraction of the cost of the InstallShield license alone. To do setup development collaboration with InstallShield you have to invest thousands of dollars in multiple licenses of DRM laden proprietary software. To do it using WiX and IsWiX is free and integrates into a development ecosystem (Visual Studio) already understood by your customer.
Thanks for reading. Please feel free to reach out to me if you want more information on this topic.
IsWiX 2.4.14319.1 Released
I'm sorry that I haven't been blogging or working on IsWiX much this year. There just isn't a lot of time left over after my day job, consulting, passion for SCUBA diving and family time. Still, I've managed to get a small release of IsWiX released on our CodePlex site today. This release adds support for authoring 64bit components, parses the MSI Product Version automatically when using TFS 2013 and has some minor improvements to the Files and Folders UI.
Friday, June 27, 2014
WiX DTF Behavior Alert
I was troubleshooting an installer today when I came across what I consider to be a bug in Windows Installer's DTF managed custom action pattern. First a little backstory:
WiX DTF Managed Custom Action projects allow you to add project items as content. During the build this all gets packed into a self extracting custom action that then gets stored in the Binary table of your MSM/MSI. At runtime the binary is extracted to an MSI determined temp directory and a native hook is invoked. This native code then extracts the contents of the self extracting CA into another temp directory and then launches a routine that eventually results in your managed code running. It also sets the current directory of the process to this temp directory so that your content resources can be referenced.
That's how it's supposed to work. Or at least that's how it's always worked. The WiX team doesn't really document this so I'm sure the "functions as designed" or "functions as coded" door is cracked slightly open.
Ok, so the behavior I want to alert you in is if the Microsoft.Deployment.WindowsInstaller.dll (interop library that DTF uses to marshal MSI API calls to the custom action) is in the GAC the current directory won't be the temp directory as expected, it'll be the directory in the GAC (C:\windows\assembly\GAC_MSIL\Microsoft....) that the assembly is stored in. This means any relative path references to your content files will now fail.
Ok, so how do you protect yourself? Add this line to the beginning of your custom action:
Environment.CurrentDirectory = new FileInfo(Assembly.GetExecutingAssembly().Location).Directory.FullName;
This will ensure that the current directory is set to the directory that your assembly was extracted to. I believe this is the first DTF bug I've seen in about 3 years. The last was a race condition fixed in 3.6 or 3.5 that randomly prevented a CA from firing. The only before that was back around 2008 and involved custom action sandboxes being recycled and previous custom actions changing the current directory to a directory you wasn't expecting. I believe it was back then that DTF added a current directory initialization pattern and it generally works well except for the gotcha I just noticed.
Update 6/28/2014: Just one day after reporting the bug, Sean Hall has submitted a pull request and the issue has been marked as fixed for WiX 3.9. I'm not sure when 3.9 is going to ship but I'm very thankful and impressed with how quickly this bug was addressed. Thanks guys!
Friday, April 18, 2014
Visual Studio Installer Resurrection
Like a late really, really bad April Fool's joke, Microsoft announced the day before Good Friday that Visual Studio Deployment Project have been raised from the dead. See:
Visual Studio Installer Projects Extension
I guess the thousands of ignorant developers at User Voice (Bring back the basic setup and deployment project type Visual Studio Installer) and the departure of all the Windows Installer experts from Microsoft was finally too much to keep a bad thing dead.
Sigh.
If you read this and decide to use this tool anyways, keep in mind:
1) .VDPROJ doesn't support MSBuild so don't expect a decent TFS Build story without some custom plumbing to call DevEnv to build the project. Also don't expect this extension to be the Visual Studio Online build servers.
2) Read my old article Redemption of Visual Studio Deployment Projects for tips on how to get the most out of the tool without letting it suck the life out of your soul. (A little bit of VDPROJ and a whole lot of WiX / IsWiX!)
Think I'm being dramatic? Read Change Change Change. I literally spent a year banging my head against the wall trying to make this technology create installers that rival anything and everything that MSFT DevDiv puts out. I know this tool better then they do and I can say with complete confidence that it sucks.
But Chris.... you didn't even try it!
Actually, yes, I did try it. Installed the extension, created an empty installer and attempted to build it. Every time I do Windows Installer kicks off a Visual Studio 2013 repair and the application log indicates:
Detection of product '{9C593464-7F2F-37B3-89F8-7E894E3B09EA}', feature 'Visual_Studio_Professional_x86_enu' failed during request for component '{CBB86C09-565A-43CF-9120-9D45AE3374CA}'
But Chris.... why do you care what other developers use?
Because I care passionately about the state of the setup industry and at my day job we often receive poor quality installers from third parties that we are then expected to somehow deploy without any issues.
Still don't believe me? Go read the comments in this old blog post: WiX in Visual Studio Nearly 8 years have gone by and none of the problems in the tool mentioned in the 100+ comments have been fixed.
Just consider that the $.02 of an 18 year industry veteran who is the Windows .NET ALM & Deployment Architect for a Fortune 35 retailer with $70B a year in revenue. We probably have a store very near you and we work hard to make sure that software is delivered to the business flawlessly and on schedule every time.
Subscribe to:
Posts (Atom)