Home arrow Blog arrow De-emasculating VB.NET...
Wednesday, 21 August 2019
Main Menu
Web Links
Blog Links
Musical Links
Nerdery Links
Other Neato Links
De-emasculating VB.NET...
User Rating: / 5
Written by WATYF on Friday, 18 November 2005 (19152 hits)
Category: .NET Programming

Is it just me, or has VB always seemed like a C language with its nads cut off? (that's a rhetorical question, btw... I know it's not just me ) The thing is... they always try to give you little features and "productivity" advantages, but when it really comes down to it, there are always those "manly" programming functions that you just can't perform with VB. (That is, if you consider anything in programming to be "manly".)

When .NET came around, they made it sound like VB was finally getting some cahones and that it would be on par with its corresponding C language (C#)... and in a lot of respects, that was true... but you know... there must have been a bitter, old C coder working on the .NET project who just couldn't stand VB.NET being put on the same level as C#... because it looks like he decided to castrate a few features out of VB.NET just to stick it to us poor, lowly VB coders...

In this case, I'm talking about Pre and Post Build Events. These are obviously very handy tools... and they're available by default in C# projects... so why on earth would they not be available in VB.NET projects as well? There's just no rhyme or reason to it... (other than my bitter C coder theory)...

And yes, I know that they're adding VB.NET Build Events to VS.NET 2005 and blah blah blah... but what about all us folks who don't get to upgrade to the latest and greatest IDE the minute it gets released?

Well.... we hack things up.... like any respectable VB coder would.

So here's how to hack a Pre or Post Build Event into your VB.NET Project.

First off... this solution involves using VS.NET macros. My entire deployment of TaskRunner is completely automated using a combination of a VS.NET macro and a VB.NET application, so this meets my needs quite well... I just throw a line of code into the existing macro, and it sets the Build Event. But if you're not using macros during your build process, then this approach won't do you any good (unless you intend to start using macros just for this reason).

Secondly, I can only guarantee that this will work for VS.NET 2003.... actually... I take that back... I can't guarantee that this will work at all... but you probably have a slightly higher chance that it will work on VS.NET 2003.

That said, let's get down to the nuts and bolts of it. Basically, the deal is... the Build Events do exist in VB.NET projects... you just can't see them in the Project Properties GUI. It's not like they didn't put them in at all... they just added them, and then made it so you had no way of knowing they were there. (further proof of my bitter C coder theory)

So... all you have to do is create a macro that will set the event using the DTE class and exposing a Property of the Project class. Unfortunately.... they don't make it obvious which Property it is... but I'm going save you the trouble of enumerating them all and just tell you which ones they are.

Here's how your code would look:


'Set the event...
DTE.Solution.Projects.Item(1).Properties.Item(32).Value = "C:\My Crap\SomeBatFile.bat /argumentsandstuff"
'Then build the project...


Post Build:

'Set the event...
DTE.Solution.Projects.Item(1).Properties.Item(33).Value = "C:\My Stuff\SomeBatFile.bat /argumentsandstuff"
'Then build the project...


As you can see, the only difference between the two is which Property Item you reference (32 for Pre, 33 for Post). There are a couple of things to keep in mind when doing this. The Project Item collection is not zero based (like... well... every other collection in .NET ), so if you think you can set it to "Projects.Item(0)" to reference your first Project, you'll be stuck scratching your head, wondering what's wrong. Chances are, though, that you only have one Project in your Solution, so it shouldn't be that difficult to set. But there are about 5 Projects in the TR Solution, so I had to figure out which Project was which when I set this up. Also keep in mind that setting the Build Event this way is NOT persisted when you close your Solution. In other words, you can't just run this code once and then forget about it. You have to reset your Build Event after every time you re-open your solution.

So there you have it... now you're playin' with the big boys... and you should act like one too. I suggest finding a coder who uses a lesser language (like Action Script) and belittling them on a public message board... that always seems to work for C guys.



< Prev   Next >


You must javascript enabled to use this form

TaskRunner Spam-a-lot


  TaskRunner 3.3!!

Click here to get the brand spanking new version of TaskRunner... 3.3!!
Who's Online

Recent Posts
Most Popular
© 2019 Musical Nerdery