It may be a Law Of Nature regarding the evolution of software that every popular software tool eventually increases in complexity until it becomes so complicated to use that the only users who can deal with it effectively are those who use it as a full time job. In fairness, that’s in large part because they’ve evolved to do some very complicated things, but it does have the effect of squeezing the amateur out of the game.

I have been a huge fan of Microsoft Visual Basic, once it became a full-fledged language under .NET. I have written many thousands of lines of code in a variety of programming languages, and taught college level CS-1 courses in five of them (C, C++, Java, Visual Basic, and Perl). Of those five, Visual Basic (in my experience at least) is by far the easiest learning curve for students. And for any program requiring a GUI, Visual Basic is by far the quickest of the five for getting a working prototype up and running, and always my first choice (Python would be first choice if all I need is a console program). Microsoft has made things even better by opening up the full, non-crippled version of Visual Studio 2013 for free.

There is, however, one aspect of the Visual Studio experience that hasn’t improved, in my opinion — in fact it’s gotten worse. And it’s a big enough issue that I’m probably going to hold my nose and switch to single page javascript apps as my go-to platform for quick and dirty GUI programs. I’m referring to the problem of deployment.

As long as you’re running a VB.NET program inside Visual Studio, everything works perfectly and predictably. Visual Studio is (again, in my opinion) a masterpiece of software design, and by far the best IDE I’ve worked with — much more intuitive, predictable, annoyance-free, and glitch-free than Eclipse, NetBeans, or even Komodo.

But sooner or later, you want to be able to use the program without having to fire up Visual Studio and run it in the debugger. Heck, you might even want to run it on a different machine, or give a copy to someone. That is precisely the point at which Visual Basic starts to be a whole lot less convenient.

In the old days, when you compiled a program on a Windows system, the compiler turned your code into a *.exe file. That’s all you needed. You could copy it to any Windows machine and it would run. (With Python, you don’t even need to compile — you just write your code into a text file and it runs. You can’t beat Python for simple and elegant.)

Visual Basic hasn’t been that simple for quite a while now, ever since Windows got all obsessive-compulsive about programs having to be installed properly, with registry entries and such, and only after multiple warnings that you’re installing a program which might do bad things, and are you sure you want to do this, and do you have a note from your Mom? (ok I made that last part up).

So to deploy a VB.NET program you have to produce a “setup” file, which would — you guessed it — handle the vexing problem of copying a *.exe file into a directory so you could run the program. Which is a perfectly reasonable way to go, if you’re writing programs with a lot of moving parts and optional components and settings. But if your program actually isn’t of AutoCAD-like complexity — which, let’s face it, most amateur efforts aren’t — you still had to build the setup file.

In the versions of Visual Studio up to and including 2010, Microsoft provided a “Setup Wizard” that made this process fairly simple once you figured it out. (The “once you figured it out” part wasn’t trivial, as I can testify from going through that learning curve with numerous students.)

So now, with Visual Studio 2013 (also, I believe with 2012, but I skipped that one so not sure), Microsoft has decided to do away with the Setup Wizard, which leaves us with a single option for coming up with a freestanding setup file that someone can actually install on a computer: InstallShield.

I will not chronicle the details of figuring out how to get that to work except to say that I’m not exactly a newbie at such things and it took me several hours to figure out how to get it to do most of what I wanted. To create the InstallShield installer (which is what you give to someone who wants to install your program) requires a separate project in Visual Studio, which looks like this in the Solution Explorer pane:


As some point, this crosses over the line from “complicated but doable” to “you can’t be serious”. Yes, I realize that all those options, settings, etc. are there for a reason and that they’re very useful, maybe even indispensable in some applications. But I’m skeptical that the vast majority of software projects done in VB.NET, even professional ones, need most of that complexity. I worked for several years in a large university lab where we built a lot of software for various in-house tasks, and I can’t recall any that would have needed any functionality that wasn’t available with the older, simpler Setup Wizard.

There is one other alternative to InstallShield, and that is Microsoft’s ClickOnce deployment. I did look into that and it seemed even harder to get to work than InstallShield. See, for example, this very good youtube video by Joseph Bolen — he describes ClickOnce as “an easy and professional method to distribute your finished program.” The youtube video is 27 minutes. I didn’t count all the steps, but among other things they involved manifest signing and assembly signing, which is not my idea of “simple”. And good as the video is, I couldn’t get ClickOnce to work by following his steps, which illustrates the problem with this sort of thing — it only takes one wrong selection somewhere and nothing works, and you have no idea where you went wrong.

It’s a dilemma. Obviously, if one’s purpose is to attain professional level skills at writing and deploying .NET applications, one needs to master these complicated tools. But it isn’t very practical for students and amateurs to devote the time it takes to get proficient with them. Anyway, what I want to do is write programs, not spend hours wading through cryptic documentation trying to figure out how to package them for deployment. Purely as a matter of software design, I don’t quite understand why Microsoft doesn’t fix this. In Visual Studio, setting up a basic Windows Forms Application project takes about four clicks and doesn’t ask the user to select from unexplained options and such — it’s pretty much impossible to screw up, even for students. How hard would it be to do the same for the task of turning it into a setup.exe when it’s done?

It may not matter that much. The complexity of both ClickOnce and InstallShield appears to be, in significant part, aimed at automating the updating of software once it’s installed, and at reassuring users that the software they’re downloading hasn’t been altered. Both worthy goals, and both inherently complicated to solve.

But the world seems to be looking in a different direction for solutions to the updating and code authentication problems: browser-based applications. With a browser-based application, the code is always up to date, and the code authenticity problems become issues for the folks who engineer the browsers and the web connections instead of issues that every coder has to get into the weeds on with every program.

So, not-very-eager though I am to dig into yet another technology stack, I think the next exciting episode of the continuing saga of yours truly desperately trying to stay at least somewhat current with the tech will consist of an effort to upgrade my javascript/jQuery/css/php/mysql/ajax skills. This is something I’ve already experimented with some, see for example this program to check patent applications for orphan callouts. Seems like a more useful place to invest time than trying to figure out the intricacies of code signing and automatic updating of installed applications.



Leave a Reply

Your email address will not be published. Required fields are marked *