The first was from Aaron Stebner ( MSFT ) talking about YEt Another Hack ( sarcasm `YEAH` /sarcasm ) describing how to do some crazy postbuild step to get a VDPROJ installer to do something as simple as set the In-Script Execution Context for a custom action. I'm sorry, but I've been down this road before. In no time at all you will have dozens of these build automation hacks just to get a tool set to do something that it specifically wasn't designed to do despite that it's painfully obvious that it should.
Then I read this posting from Phil Wilson...
The design of installer class methods does not pass the MSI handle through to managed code, mainly because the design (as a deferred custom action all) means that there's not actually much you can do with it.
Based on this and what little support for custom action attributes VDPROJ exposes, it seems pretty obvious what Microsoft ( Visual Studio Team ) wanted to design Visual Studio to support.
Finally I read a story over on SlashDot entitled Microsoft vs TestDriven.NET. It seems that the author ( Jamie Cansdale ) of TestDriven.NET royally offended Microsoft by coming up with extending Visual Studio Express editions with Unit Test Add-In's. A response from the VSE team can be read here.
So setting the threshold level to 5 on SlashDot ( as I always do ) I discovered this gem:
It seems that Microsoft is claiming a EULA violation on the basis:
...you may use the software only as expressly permitted in this agreement. In doing so you must comply with any technical limitations in the software that only allow you to use it in certain ways... You may not work around technical limitations in the software.
So I ask you, if VDPROJ specifically didn't provide for immediate context CA's, ServiceControl/ServiceInstall support and a host of other things, and assuming that Microsoft's bizarre EULA is enforceable, isn't writing articles that encourage developers to work around these ( obvious ) limitations simply an invitation to disregard their own EULA?
Just like teaching developers how to modify .NET Framework Redistributables to run silently even when their own EULA says that you may not.
BTW, did I mention that Microsoft yanked the MVP status of Jamie? Also of interest is that Jamie wrote the Installer for TestDriven.NET using all Microsoft tools including WiX.
Times like this makes me really happy that I don't owe anything to Microsoft... I prefer to have an unbiased outside opinion without worrying about things like will I get shunned from some conference, lose MVP status or worse, lose my lively hood.
Days like this, I miss my Amiga.
On a somewhat related EULA topic, the other week I saw an interesting setup. The EULA was hosted in a text control which was not marked as read-only. So of course I selected-all and deleted everything, and then added my own EULA stating that I had free rein over the software, and that the company may not spy on me, or transmit any data from my computer. I’m pretty sure they violated the EULA I agreed to. :) This was for www.joost.com
ReplyDeletePreface: I'm a loyal WIX user and will never go back to VS setup junk.
ReplyDeleteFrom my perspective you're mixing the hammer and the plywood. The scripts Aaron provides are customizing your source code for you application on windows. These aren't hacks. They're just scripts that make all of our lives easier. Aaron's blog has saved me on numerous occasions when I didn't realize that I needed saved and his stuff works with or without VS.
The TestDriven product is hacking on Visual Studio to make it do things Microsoft didn't intend. A bunch of people are posting Jamie's code with descriptions of what's happening and they're harshing on him pretty bad. Over at CodeProject they were calling him dillusional.
Worse go check out Markle's post.
http://executioniseverything.blogspot.com/
This guy is dreaming this whole mess.
Sorry, I'm not sure I see a diference. The postbuild scripts are still making Visual Studio (VDPROJ) do things that Microsoft didn't intend. There are technical limitations to VDPROJ ( many ) and these scripts workaround these limitations.
ReplyDeleteEitherway, I commend your decision to not use VDPROJ.
Microsoft provided the mechanism for post-build scripts to be run. Aaron didn't hack anything - he used the functionality given to provide post-build events. He didn't work around any technical limitation: he used the feature provided. There's a big difference.
ReplyDeleteIf the scripts modified the .vdproj to enable functionality that were otherwise not available, then your argument might be interesting. They don't. They modify the output of a build -- your code, as it were. Even the free Express SKUs don't place restrictions on what you do with your code.
ReplyDeleteI guess my real point is when you have such a general statement in a EULA that you'll never really know what it means until you end up in court. That is assuming you have enough money to even consider taking it to court.
ReplyDeleteEitherway I'm not impressed by either VDPROJ or postbuild hacking of MSI's to get around stupid toolset limitations.
I say this because I speak from experience. As a few of the readers of my blog could witness, I once worked for a company that had over 1000 VS merge modules and about twice as many Installer Class CAs. It was a big yucky mess that required many postbuild hack scripts ( which we did using C# NAnt tasks rather then vb/jscript ) that were much more complicated and strange then the examples we've seen from Aaron and Phil.
When you choose VDPROJ and your requirements are more then xcopy deployment, it'll bite you in the end. The right choice is to choose a different toolset such as InstallShield or WiX and just forget about VDPROJ and roll your own workaround hacks.