Doron's .NET Space

Why I Like My Job

Recently I've been reflecting on my life's choices. Just a reflective kind of mood, I guess. I chose to become a programmer when I was 18 years old. That was 6.5 years ago, and a pretty young age to make life-changing choices - at least in my country. That choice pretty much set the course for me for the next 9 years, as I was going to study in the university for 3 years and then work in the same place for the following 6 years. That's a lot of burden on 18-year old shoulders.

So I got to thinking - if I had to make the same decision again, would I choose the same way?

And what I answered myself was - Hell yeah! I love being a programmer, and the main reasons are:

• It's challenging work. I get to use my brain to solve problems.
• I get to create stuff. At first there is nothing, but after some creation there is something that people can use, and it makes their life easier. Well, most of the time.
• I'm no artist, and can barely draw an image of a person without him looking like he just fled Chernobyl, but after writing software I can sometimes look at it and say: "Hey, I just made something pretty".
• I get to work with some really smart people, and learn from them.
• I get to learn so much about myself, as a person. Debugging one of these random-looking bugs can really tell you what you're made of.
• The pay isn't bad.
• I'm pretty good at it, or so I'd like to think.

It's hard work, but I guess I wouldn't have it any other way. I can't really think of anything else I would have preferred to do. I like to write, but I don't think I could have done it full-time as a reporter. Blogging pretty much scratches that itch for me.

Speaking of scratching itches, if only I could write some software that killed all mosquitos, I'd be a much happier person now. Probably richer too. The bastards are driving me crazy.

Visual Studio Setup Project Annoyance

Lately I've become uncomfortable with the setup project that comes with Visual Studio 2005. We've been using it to deploy a web application and a windows service, and we hit all sorts of snags.

For instance:

1. You can only build it inside Visual Studio, so our build server can't produce MSI's for us.
2. You can't attach .bat files to the installation actions, only .vbs files. I really can't understand why.
3. CustomAction parameters syntax is not the prettiest thing.

But our latest issue with the setup project had me really puzzled for a while. It involved the deployment of the windows service I mentioned - specifically, its app.config. For some reason, the setup project regarded the actual app.config file as that project's output, instead of the service.exe.config that is generated by MsBuild. In order to deploy that service to different environments we change the .exe.config according to the current build configuration, by using an MsBuild task called XmlMassUpdate. We change the .exe.config file directly, not the app.config, since the latter is usually protected by source control, and therefore marked as read-only. Anyway, it makes a lot of sense for us to change only the output the build produces and not the source.

Thing is, you can't change the setup project view of what the output is (at least we couldn't find a way to do this, even by manually editing the project file), and since it decided that app.config is it, it left us with no choice but to change that source file directly.

I really think the output should simply be regarded as the entire /bin/debug or /bin/release directories, and not just the .exe + app.config files. Go figure.