Sampy's Blog : VB

Dark - Day 1

misampso — Tue, 15 Mar 2005 01:50:00 GMT

Fixed 3 bugs today, not bad. I spent most of the afternoon banging my head up against a build problem having to do with my Win Forms designer created resx files. If I can't get it going in the next hour or so, I'll probably just work with my team tomorrow to get it fixed.

Today's Bugs:
Publish Property pages should be disabled when the output type is changed to a non-publishable type (like class library)
FxCop Violation: The ResolveKeySource MSBuild task is too complicated
Signing Property Page UI clean up (the divider lines look wrong)

Do you like this sort of day by day, blow by blow account of my day? You find it interesting? Let me know!

Gauntlet - Measuring success one checkin at a time

misampso — Mon, 14 Mar 2005 18:23:00 GMT

On the VB team, we don't checkin to our source control system (Source Depot or sd) ourselves like mere mortals, we use the automated checkin system called Gauntlet. Gauntlet runs as an .hta app that collects your unsubmitted changelist, asks for some information for the checkin email it will send if things go well, and the bugs it should close in our issue tracker (Product Studio or PS). You run the app from inside our build environment so it has all the right environment variables and stuff it needs to collect you change. After it gets all this data, it uploads it as XML to a server where you wait in the queue.

Once your job gets picked up, it is passed to a build machine which builds your fix and outputs it to a known path on that machine. The controller machine then picks up those changes and puts them on a public share and instructs the test machines to begin. These machines pick up your private fixes and run a pre-defined set of tests you picked when you submitted the job to Gauntlet (you pick what sub-team you work on and it runs all of those tests). If the tests pass, your code is checked into the depot, the bugs are resolved, and the checkin mail goes out (woohoo!). If the tests fail, you get mail indicating which suites failed, what build flavor (debug or release, checked and retail in our language), and links to the logs output by the tests.

When I got in this morning I got a bunch of suite failure mails for 2 checkins that I started over the weekend. Shortly after I parsed through all of them, I got a mail from our Gauntlet admin letting me know we had some machine issues and that's why all the suites failed. Thankfully, it's easy to re-activate a failed job through Gauntlet's web UI. Unfortunatly, I'll be at the back of a long line :P

Unhooking Events from WithEvents/Handles

misampso — Tue, 27 Jul 2004 23:57:00 GMT

A while back when I was working on the publish property page, I need to unhook an object from it's event handlers. That object was declared with Dim WithEvents and the handlers were wired up with Handles clauses on the methods of the object. While I love this event paradigm, I didn't know the right way to unhook the handlers in this case. This was causing the object to remain in memory and bad things were happening.

So I cracked open Ildasm (a key tool for any hardcore VB developer) to figure out how the handles clause wires up the events (and how it unhooks them). It turns out that every WithEvents field is compiled into a property by the VB compiler. In the setter of that property, a null value will cause the events hooked up via Handles to be unhooked and setting another value will do the same for the old instance and hook up the new instance.

Armed with my ildasm evidence, I walked down the hall and talked to a compiler dev to confirm my theory. I told him what I thought was going on and he thought for a second and replied, "Yeah, that'll work." So there you go. Use the super-handy WithEvents/Handles syntax and use this little trick when you need to manage your objects carefully.

I hope to get another tech post up tomorrow and make it 3 days in a row :)

Deployment Chat today!

misampso — Tue, 06 Apr 2004 17:41:00 GMT

Today at 1pm Pacific time (4pm Eastern) check me out talking about deployment!

MSDN Chats Main Page

Direct Link to Chatroom

I hope to see you there!!

If foo Is Something Then ...

misampso — Tue, 24 Feb 2004 21:49:00 GMT

VB Whidbey is getting some long overdue keywords: IsNot and Using being my personal favorites. However, there are some keywords that we don't have yet but I could see coming...

Something - Basically this just means Not Nothing. All this really buys you is the ability to say If foo Is Something Then which is pretty cool. A C# friend of mine was hoping that you could somehow say Do Something ... End Loop and as cool as that would be, I can't really think of a way we could pull that off.

You - We have a Me, why not a You? Perhaps this could be equal to the calling object (Nothing if called from a Static method or interop) and allow you to guard your methods from external callers.

Any of you have ideas for keywords you'd like to see in VB? No promises on gettings these two (or any others) added to the language but I'll bring up any really good ones.

Welcome to the wonderful world of Deployment!

misampso — Wed, 18 Feb 2004 08:45:00 GMT

Hi. My name is Mike Sampson and I'm a developer here at Microsoft on the VB team and I work on deployment. Specifically, I work on Setup and Deployment projects (MSI's, Cab files, and MSMs) as well as the cool new web-ish ClickOnce deployment. In VB, we work on the tool side of ClickOnce rather than the runtime but I'm going to try and shed some light on that part of ClickOnce as well. Also, I'm going to work to extole the virtues of our cool Generic Bootstrapper to help install prerequisites for your ClickOnce or MSI app. But enought about the technology, here's a little about me:

I was born in Virginia Beach, Virginia about 22 years ago. My parent still live there and so did I until I went off to college at Wake Forest University in Winston-Salem, NC. While there, I got my Computer Science degree with a minor in Japanese (I even spent a semester in Japan). I also did 2 interships at Microsoft on the Visual Basic team, my first as a SDE in test and my second as an SDE in development. After graduation, I moved to Bellevue, Washington and started full-time at Microsoft as an SDE on, you guessed it, the Visual Basic team. I've been at that for almost a year now and I love it. Hopefully, I can share some of the wisdom that I've gained here on this blog. I look forward to blogging!