Fowl Coder

Constructors for VB.NET Modules

2009-08-04T12:15:00.003-04:00

Did you know that you can have a constructor on a module? I first got the notion to try this after thinking about static constructors in C#. In C#, you can do something like this:

class Class1
  {
      private static int _magicNumber;

      static Class1()
      {
          _magicNumber = 4;
      }
  }

So the next thing to try was to test this out in VB.NET:

Module Module1

Sub New()
   Debug.WriteLine("New")
End Sub

Public Sub Test()
   Debug.WriteLine("Test")
End Sub

Public Sub Test2()
   Debug.WriteLine("Test2")
End Sub
End Module

Running this and calling the methods Test / Test2 (in that order) yields this:

New
Test
Test2

So as you might expect, the construct only gets called once, but is called before any members are accessed in the module. Handy!

Gettinginto MSBuild / TFS Build

2009-06-30T14:07:00.005-04:00

As you will no doubt agree, it's handy as heck to be able to get a fresh installer for your app on demand. Right now our build is a relatively manual process that takes a number of hours to complete. It's inefficient and error prone. The answer - automation of course!

I've already set up our environment so that it will automatically build our code whenever somebody checks in - this is a good thing. However, we're thinking about moving to the next step and getting our installer to be automatically built. We're not sure exactly how we're going to do this yet, but the components are:

Our .NET solution (most of our code is here).
Some VB 6 code (just enough here to have to make the build interesting).
An InstallShield installer (and dealing with the InstallShield licensing nonsense).

Our main options are:

Create our own MSBuild setup with custom tasks. Getting this to happen on our build server would be ideal because then anyone on the team could make an installer through the TFS build interface.
Write a .NET app from scratch. Not quite as slick as using MSBuild (considering MSBuild was sort of designed to do just this sort of thing), but I'll take whatever works.

Just to keep track of the resources, here are some of the pages I'm looking at:

This deals with incorporating VB6 and MSBuild
This has some links for creating custom build steps
This is getting started with MSBuild

We need to check in some files, so here are some links for that:

This is some basic info for automating the TFS Version Control.
Creating a label

More to come as we narrow down the solution.

OPC at RVNUG: The code and the slides

2009-05-10T21:31:00.005-04:00

First things first: Here is the code and here are the slides.

Thanks to everyone who attended (and participated in) my resent presentation on the Open Packaging Convention (OPC) at the Roanoke Valley .NET User Group (RVNUG). It was a rowdy group (my favorite kind) and it was a blast.

Besides coming up with various connotations for the words 'Package', 'Parts' and 'Stream', we discussed some handy ways to use OPC:

Exporting / backing up data
Storing a gallery of images with additional metadata (geocoding, timestamp information,etc)
Grouping together log files. This application seemed to generate the most interest.

OPC is a dirt simple way to store data in one place without needing a database.

DebuggerStepThroughAttribute

2009-04-20T12:08:00.002-04:00

Let's say you have some code that often throws an exception, but you just swallow it and carry on. This is usually fine, unless you have your debugger set to break on. So take some code like this:

Public Shared ReadOnly Property IsInstalled() As Boolean
 Get
    Dim isInstalled As Boolean = False

    Try
       Dim temp as Object = CreateObject("Some.ActiveX")
       isInstalled = True
    Catch ex as Exception
    End Try
  
    Return isInstalled

 End Get
End Property

If the COM object doesn't create properly, it will generate an exception. This sort of code is usually in the start up of an application, so you might have to hit this every time you debug your app. It's annoying.

However, if you add the handy attribute DebuggerStepThrough just before the Get clause:

Public Shared ReadOnly Property IsInstalled() As Boolean
   <DebuggerStepThrough()> _
   Get
      Dim isInstalled As Boolean = False

      Try
         Dim temp as Object = CreateObject("Some.ActiveX")
         isInstalled = True
      Catch ex as Exception
      End Try
      
      Return isInstalled

   End Get
End Property

Then Visual Studio just runs over the code like nothing ever happened.

Roanoke Code Camp 2009 - The Code

2009-04-18T21:38:00.000-04:00

Apologies for not getting this published sooner... Between getting ready to move houses and my normal level of laziness and procrastination, I haven't done it. It also took some Googling to figure out how to include code in a BlogSpot post. Enough whinging, here's the code for the OPC (Open Packaging Convention) class I did.

By the way, here is my DevX article on the same subject that got published recently.

Here is the code to create a package:

'Open the package
      Using package As Package = package.Open("c:\Example.zip", IO.FileMode.OpenOrCreate)

          'Create the uri for the text file
          Dim uri As New Uri("/TextFiles/MyTextFile.Text", UriKind.RelativeOrAbsolute)

          'Create the part for the text file
          Dim part As PackagePart = package.CreatePart(uri, System.Net.Mime.MediaTypeNames.Text.Plain)

          'Get the stream for the part
          Using stream As Stream = part.GetStream()

              'This is the text we'll put in the part
              Dim myText As String = "This is an ugly picture of a flower - Roanoke!"

              'We need to get the string into a byte array to make it easy to write to the part stream
              Dim buffer As Byte() = System.Text.ASCIIEncoding.ASCII.GetBytes(myText)

              'Write to the part stream
              stream.Write(buffer, 0, buffer.Length)

          End Using

          'This is the uri for the flower
          Dim uri2 As New Uri("/Images/Flower.jpg", UriKind.RelativeOrAbsolute)

          'Create the part for the image
          Dim part2 As PackagePart = package.CreatePart(uri2, _
                                                        System.Net.Mime.MediaTypeNames.Image.Jpeg)

          'Get the stream for this part
          Using stream As Stream = part2.GetStream()

              'Read the data from the file
              Dim buffer As Byte() = File.ReadAllBytes("c:\Flower.jpg")

              'write the data to the part
              stream.Write(buffer, 0, buffer.Length)

          End Using

          'Create a relationship between the parts
          Dim relationship As PackageRelationship = _
             part2.CreateRelationship(part.Uri, TargetMode.Internal, "flower_to_text")

      End Using

And here is the code to read that package:

 'Create the package
       Using package As Package = package.Open("c:\Example.zip", IO.FileMode.Open)

           'We know the Uri for the flower, so let's start there
           Dim flowerUri As New Uri("/Images/Flower.jpg", UriKind.RelativeOrAbsolute)

           'Get the part using the uri we just set up
           Dim flowerPackagePart As PackagePart = _
               package.GetPart(flowerUri)

           'Create a relationship from the
           Dim relationships As PackageRelationshipCollection = _
              flowerPackagePart.GetRelationshipsByType("flower_to_text")

           'Get the first relationship (in real code, we would want some error checking here)
           Dim relationship As PackageRelationship = _
               relationships(0)

           'Get the part from the relationship (once again, this would need some
           ' error protection because in a real world app this part might not exist anymore).
           Dim textPart As PackagePart = package.GetPart(relationship.TargetUri)

           'Get the stream
           Using stream As Stream = textPart.GetStream()

               'Create a buffer
               Dim buffer(stream.Length) As Byte

               'Read the stream
               stream.Read(buffer, 0, stream.Length)

               'Read the text
               Dim myText As String = System.Text.ASCIIEncoding.ASCII.GetString(buffer)

               'Show the text (the crowd should go wild here)
               MessageBox.Show(myText)

           End Using

       End Using

   End Sub

WPF Designer causes Visual Studio to Close

2009-03-18T21:10:00.006-04:00

Okay, so we all know that the WPF designer in Visual Studio 2008 is suboptimal. And if you didn't, now you know. Besides not being particularly user friendly, it's buggy as hell.

Today, while trying to demonstrate the basics of XAML / WPF, I was trying to show the design view of a WPF Window. The problem was, every time I opened the designer, the IDE would just close. No error, no beep, just gone. That was awesome.

Here are the things that I did that didn't solve the problem:

Cursed.
Rebuilt all.
Cleaned solution, then rebuilt all.
Manually cleaned the solution by deleting the bin and object folders under each project in the solution.
Closed the solution and deleted the .suo file (Solution Options File).
Closed the solution and deleted the project user files.
Rebooted.
Cursed when it still didn't work.
Contemplated Harakiri.

Here's what did work:

Deleted all of the temp files in the temp directory.

WTF? So in XP, here is the temp directory that was causing the issue (it's a different path in Vista):

C:\Documents and Settings\\Local Settings\Temp

There were like almost 5,000 files in that directory. Apparently, the designer creates temp files. My best theory is that tt will keep bogging down trying to find unique temp file names until one day it runs out of combinations. Then there is no call for help, no suicide note, it just quietly and inexplicably goes away. It doesn't even hang itself (no process remains in Task Manager).

I had discovered this fix many moons ago, and had of course forgotten about it until months later when my temp directory filled up.

Nomadic Programming

2009-03-05T10:14:00.004-05:00

No, I don't mean driving all around town to program... Which isn't to say that wouldn't be fun. This refers to the tendency for a team to work on almost every module of a product at the same time.

So, how do you tell if this is happening? Draw a picture of your project. Break down your project into its major components. Pick a color scheme. This one is pretty straightforward:

Red - the module hasn't been touched
Yellow - the module is in progress
Green - the module is code complete.

And you'll end up with something like this:

Holy crap - there are very few modules that are complete, and very few that are untouched. That means that the team is wandering all over the featurescape almost randomly coding on different modules. This approach has all sorts of dangers:

This makes it very hard to ever get a project done because no individual item ever is completed.
This approach leads to the "throw it over the wall to testing at the end of a long development" method. Not a good thing. For example, a fundamental flaw in design / implementation could have happened months ago and propagated to the rest of the product. That could easily lead to orders of magnitude to fix all of those issues.

If all is going well, we would expect to see a very small part of the diagram showing up in yellow (in progress) with the rest of the modules being either red (untouched) or green (completed).

Special Characters in the Office 2007 Ribbon

2009-02-10T16:32:00.002-05:00

Have you ever run into a teeny little problem that was incredibly annoying and almost impossible to debug? Well, I did. All I wanted to do was create a Ribbon Tab at runtime from a database for a Word 2007 Add-In.

Creating the tab and adding the controls was easy. Very easy actually. However, using"special characters" such as "'/" and "(" or ")" in the labels caused the entire tab to not be displayed. No error message, no log, just poof - ribbon gone. Sweet. I tried escaping the characters xml style, but that caused even more problems. I created a ribbon using the Visual Studio 2008 Ribbon Designer. The code I had written looked almost exactly like the code there. Well crap. I Googled the living snot out of the problem and couldn't find a damn thing. I asked team members. I stared at the ceiling. I mediated about it. I even programmed myself to dream about it. Actually, I gave up at the ceiling staring stage, but you get the idea.

Well, today I was looking through the designer code for the ribbon, and it had calls to ribbon.SuspendLayout(), ribbon.ResumeLayout(False) around the calls to add the ribbon controls. I didn't think this would do anything, but hey - why not give it go? Sure enough, that fixed my problems.

So, in summary, do this:

ribbon.SuspendLayout()

... 'Add a bunch of tabs, groups, controls, etc

ribbon.ResumeLayout(False)

and everything will be fine.

XML Literals with namespaces

2009-01-06T09:30:00.006-05:00

I love Xml literals in VB. They're pretty slick. However, I ran into a little gotcha today... All I wanted to do was query some data from an xml that happened to be part of a Word 2007 template (a .dotm file). It looked like I had the right query syntax, but I wasn't getting any result.

Most of the examples I found on the web were searching through xml like this:

Dim document = <customers>
            <customer firstname="John"></customer>
            <customer firstname="Juliet"></customer>
         </customers>

Dim firstNames = From customer In document.<customers>.<customer> _
Select customer.@firstName

This works like a champ. firstNames contains what you would expect:

{Length=2}
(0): "John"
(1): "Juliet"

But let's say our xml is part of a namespace (much more realistic)


Dim document = <customers xmlns="http://fowlcoder.blogspot.com/xmlLiteralExample">
            <customer firstname="John"></customer>
            <customer firstname="Juliet"></customer>
         </customers>

If we use the same query code as above, we don't get any results. We actually have to add some code to make the query aware of the namespace. It's pretty straightforward.

First, add an Imports statement at the beginning of the file:

Imports <xmlns:fc="http://fowlcoder.blogspot.com/xmlLiteralExample">

Now, you have to alter the query a little bit:


Dim firstNames = From customer In document.<fc:customers>.<fc:customer> _
                   Select customer.@firstName

Voila! You get the results that you would expect (John and Juliet).

How to destroy your business 101 - network security

2008-12-23T16:00:00.001-05:00

Throughout the course of my career, I've had opportunities to work with a range of companies both large and small. Along the way, I've seen some amazingly bad practices. The root cause of each of these scenarios is usually a mixture of inexperience and/or laziness. I'm not a network expert, but I know a bad idea when I see one. Here are some example of grievous holes in security that I've run into first hand.

Shared Accounts
Don't do it. I've seen this manifest itself in few different ways. At one shop, every member of the IT staff knew the password to the domain admin account. This is bad. The IT manager didn't realize that you could add accounts to the Domain Administrators Group. *sigh* The thing is, if a bunch of people have access to the same account, it's almost impossible to tell who screwed something up. Also, if it's hard to tell who dunnit, it's more likely that somebody is going to do it. In other words, if you have a disgruntled employee in house that has domain admin access and you have no way to audit access, he or she probably knows it and is free to wreak whatever havoc he or she wants to without much fear of getting caught.

More recently, I saw the same problem from a different angle. Instead of a bunch of people having the password to the domain admin account, everybody had the username / password to a test account that is part of the domain admin group. Oh snap. With these credentials, it would be possible to wreak devastation on the network with no trail. This isn't a good. The first thing I did was report this huge hole in security, so I'm hoping that somebody does something. It's not my responsiblity, but I'd rather not have to twiddle my thumbs as the IT team rebuilds the servers.

Easy passwords for sensitive accounts
This was a legendary scenario. Most companies use VPN to provide remote access to the corporate network. The passwords for these accounts are usually required to have strong passwords at the the very least. The robust solution should require certificates, SecureID fobs, etc. I stumbled onto this one night when I was bored at home and was curious if I could guess the password to one of the salepersons accounts. I fell out of my chair when I got it on my second guess. Oh yeah, it was "password".

Note that this was a large company, with over 300 employees that did many millions of dollars worth of business. Oh, and it was a medical supply company. Holy crap. That was a huge violation of HIPAA rules. I called the IT manager to fix the problem immediately. He was worried that he would get support calls from the sales staff in the middle of the night so he didn't want to deal with it until the morning. I knew that I would be the one fixing the problem if the network got comprimised, so I broke protocol and disabled the VPN server for the entire company. I don't like sidestepping procedure but in this case I felt I had no choice. The first thing in the morning I let the executive meeting what was happening. Fortunately, the exec team understood the gravity of the matter and we resolved the issue pretty quickly.

Wireless Access Points
In another case, I was walking around the building I worked in. While walking by the office of the IT manager, I noticed that there was a wireless router plugged into the network. Snap. I asked him what it was for and he stated that we was playing with it, but it was no big deal because it didn't have a big range.

This was at the same company (and yes, the same IT manager). Did I mention the gobs of patient data that we were responsible for? I advised him that he probably should not be plugging that into the network. He eventually saw my point, but I was amazed at the complete lack of forethought.

There are ways to safely incorporate wireless networking into an enterprise architecture, but the right solution usually involves several layers of security including encryption, access control and firewalls. Just plugging a cheap consumer wireless router into your office wall with default settings (wide open access) is a recipe for disaster.

Mystery Machines
At one post, I noticed there were several servers that were hanging out in the corner of the server room. They weren't labeled and nobody had any idea what they did. Better yet, nobody had the root password to the machines. Holy crap!

Basically, an intern had set up some servers for the company a while back, but never shared the passwords. Out of fear, the IT manager refused to turn off the machine. Later, when I became responsible for the network, the first thing I did was unplug those machines. It turned out they were service some utility, but weren't critical. I instructed the IT staff to recycle the machines with a fresh OS install so that we knew exactly what was installed.

Finally
There are many subtle ways in which network security can be comprimsed. These were some gaping holes that were just asking for trouble. Take an inventory, if you're doing any of the above - stop!

Automation

2008-12-19T17:00:00.001-05:00

I get bored easily. I wouldn't make a good factory line worker because I'm horrible at repetition. Once I've figured something out or gotten proficient at something, I lose interest for the most part (this excludes multiplayer first person shooter games - I can play those forever). If I had to choose between working on an assembly line or wrestling rabid alligators, I would probably say something like "How big are the gators?"

This isn't necessarily a bad thing (or at least that's what I tell myself). When it comes to building software, I like to design and code, improve process - that sort of thing. Doing repetitive things like running database scripts or running reports on project status are Kryptonite to me. I would rather spend a few days building a tool to do the work for me than do it by hand every day / week, etc.

What are good candidates for automation? Pretty much anything that is repetitive.

Daily, Weekly, Monthly, Reports.
Do whatever it takes to make these pushbutton. This doesn't apply to one off reports. However, if you're spending a bunch of time copying and pasting between Excel spreadsheets, you're doing something wrong. If you automate the reporting process, any time spent daily is tweaking. Tweaking is important for reporting. If you're expending all of your energy just perfoming the mechanics of assembling the report, you're not as likley to make improvements to the report itself.

Builds.
Find a way to automate the build. This is a continuous integration sort of thing, but it's a productivity enhancer. Broken builds make broken teams. Can you live without it? Sure, on a small team it isn't too bad and I've worked that way plenty. However, on a larger team, I can't imagine living without it.

Installers
If you're using the Setup project type in Visual Studio, it's pretty easy, just build the setup project from the IDE. If you're using install shield, find a way to script it / run it with nmake, etc so that you don't need the "install guy" (who is probably a coder responsible for a bunch of other things) to take time to "turn the build" and make an installer.

I ran into an extreme version of this at one shop where the build took something like 14 man hours to turn. This one guy would go back to the build machine (it was the only environment where the build would work) in the closet and do his thing. He eventually figured out how to script the whole thing with make files, but the manual process was ridiculous.

Odd bit
There are plenty of opportunities. While working at one place, the shiny new web server got set up just before the IT guy left for vacation. Genius. Of course, the site developed all sorts of problems and was going down every few minutes.

We fixed the (numerous) issues and put it back into production. This one guy was sitting there hitting the web site every few seconds to make sure that it was staying up. I threw together a quick app that monitored the site and would make noise if the site went down. He appreciated the help but was like "You must have too much time on your hands." My response was "that's how I make time." I try to invest a little bit of time up front so I don't waste time later. It's a net gain.

Starting a new Dev project

2008-12-11T23:27:00.001-05:00

It's a glorious day. You have the green light to start a new development project. You can almost feel your hands on the keyboard typing out glorious code and coming up with fresh frameworks that are devoid of all that legacy that has been keeping you down. Not so fast! There are a lot of critical things that have to be in place for a project to be successful. Here are some lessons I've learned from participating in the development of a number of projects.

Process
Pick a process. It's 2008 for crying out loud. Developing software without a process is just plain silly. I've been a big fan of the iterative approach including Scrum. Can you succeed with waterfall? Sure. Even a blind squirrel finds a nut every now and then. There's a reason why most people cringe when they hear the word "waterfall." Even the creator of the process sites it as a generally bad idea.

There are some different approaches, including Spiral Development and Evolutionary Prototyping. You can also go crazy and implement CMMI. I haven't used that particular model, but from what I hear it's pretty involved. If you haven't developed using a software process before, I probably wouldn't start there.

Requirements
Yup, you need them. There's no free lunch here. What is there to justify? This lesson has been learned over and over and over again. Without a clear list of items to complete, nothing good will come. Go down to a pretty low level of detail. Items such as "Options Dialog" are very high level. You should go down to the level of "The user shall be able to select a default font for the document. " The more work and detail you do at this point in the game makes the rest of the project go much, much faster.

Prototypes
Prototypes are critical in proving technologies and approaches. Within the source of a project I end up creating a number of prototypes. Some of these are little one off sandboxes that I toss. However, with most of these prototypes, there is some value in saving these as examples for other developers on the project, or as an easy way to capture the knowledge gained while sandboxing for later. I usually create a folder in source control just for prototypes.

Of course, if you're using the Evolutionary Prototype process, prototypes are bakes in. If not, prototype each new piece of technology before adding it to the main source tree. It's worth the time and will make sure that what you add to the main source tree is of decent quality.

Also, if you're team is learning a new language for this new project, plan on throwing away the first attempt at building the product. The only way to learn how to code is by doing it, but assume that the first iteration of building whatever widget you're working on will be crap. You'll learn lots, but you'll need to rebuild it. The good news is that when you do rebuild it, it will take a fraction of the time and the quality will be several orders of magnitudes better.

Source Control
There are many options available for Source Control. Just don't use Source Safe. If you're thinking about using Source Safe, just shoot yourself in the foot. Literally. It will be as painful as trying to use Source Safe and will save time (including the hospital visit). It's slow, unreliable, and horrible. The lack of critical features such as atomic commits, not losing data, etc is unacceptable. I've only used Source Safe and Team Foundation Server (TFS), so I don't have any advice to share for specific systems outside of those. As far as TFS goes, there are pros and cons which I go into here.

Continuous Integration
Do this from the beginning. Make it easy for everyone to build the software. This is a great opportunity for automation. Different platforms have their own tools, but I'm a big fan of Team Build for TFS 2008. It's pretty easy to set up and does most of what I want (although gating isn't going to come until TFS 2010 - aka Rosario)

Installer
If you application requires an installer, build one from the beginning. As soon as you're past the prototype stage, build the installer and maintain it throughout the dev process. Doing months of work then throwing it over the fence to the installer guy is a recipe for disaster. The amazing thing is that I've seen this done more often than not.

If you build this upfront, you'll be able to get feedback from the stakeholder much sooner in the process. The shorter this feedback loop is, the less likely you'll be to stray too far away from what he / she / they expect.

Short Feedback Cycle
Well, we just covered this in the installer bit, but it's worth mentioning on its own. Schedule work in short enough increments (2 to 4/5 weeks seems to be the sweet spot range) that you can get feedback. That breaks your work down into manageable bits and provides specific opportunities for the stakeholders to view the product (whether it's internal or external).

Internationalization
Build it in from the ground up. Yes. Do it now. I go into it in more detail here.

Draw Pictures.
Draw lots and lots of pictures. Keep them around. Whiteboards are the best for brainstorming (although it doesn't work well remotely). Use Visio - it's great. I've used the flowchart diagramming to do all sorts of things from program flow to installation scenarios.

Have a big overview picture. It's good stuff. Hang it on the wall. Keep it up to date. It will help a lot of conversations to have the big picture to point at to talk about where problems are.

Testing
Do it. Do it from the beginning. Have a tester develop a test plan from the requirements. Testing in flight will save sooooo much time. Throwing a product over the wall to testing after months of coding is such a horrible idea it's staggering to know that there are still teams doing this. If you want to get your product to market as fast as possible, this facet of the development process has the greatest impact on delivery time (not to mention product quality which ultimately effects support costs).

Unit Tests
Yes do them. Write your unit tests before you implement your code. Having repeatable tests that you can run at the push of a button is magical. If you can hook up those unit tests to an automatic build process, that's even better.

Code Reviews
Code reviews are a stellar bang-for-the-buck proposition. It is by far the cheapest way to reduce errors and ensure that the teams coding standards are followed. This is also a good way to make sure that individual members of the team aren't reinventing the wheel. I don't know how many times I've looked at someone's code on the team and said something like "oh hey, we already have something that does that. Use it instead."

Code Reviews should start from the very beginning of the project. Most likely, the code reviews will be the longest in the beginning of the project while the team is deciding on best practices. As the project continues, the reviews should be done just as often, but they probably won't take nearly as long (if the project is going well) because the team should be in a groove and not drawing outside of the lines as much.

Conclusion
There are a bunch of other things that you can do, but this is a good punch list of things that should be set up from the beginning of the project.

Team Foundation Server - Pros and Cons

2008-12-03T14:47:00.006-05:00

So you're shopping for a Source Control server. There are a lot of options out there. I've only used two systems in earnest: Source Safe (SS) and Team Foundation Server (TFS). For the most part, I don't hate too many products / technologies. I'd like to think that I'm a pretty open minded guy. However, I truly hate Source Safe. I despise it. I wish that it would go away and never bother anybody ever again. It is a horribly outdated piece of crap technology that should never see the light of day. If you're thinking about adopting Source Safe for a new project, don't. Just stop. Shoot yourself in the foot. It will safe you time and will be less painful in the end. Alan De Smit does a good job detailing why Source Safe sucks in great detail here.

There are a number of other choices out there. I've been particularly interested in trying SourceGear Vault. I've only gotten as far as downloading the trial - I never got around to installing it. I've used their Source Off Site (SOS) product (it's a client / server piece which provides much faster WAN / VPN access to a Source Safe database - it was absolutely brilliant).

But, back to TFS. Here's some background information that should help you get a feel for what you're getting into...

Pros:

It's fast as hell, at least compared to Source Safe. It's designed to run over a WAN and it communicates with the server via web services. Getting latest is very efficient because TFS only gives you what you need and doesn't need to check every file in your solution.
Integrates ever so nicely with Visual Studio. It fits like a Glove into Visual Studio 2005 / 2008.
Atomic Commits. In other words, if one file doesn't make it into a checkin, none of them make it. That's the way it should be.
Comes with Team Build, which provides functionality that I hear is relatively similar to CruiseControl.net (or so I've heard).
The work item subsystem is pretty sweet. It has lots of features out of the box and is very extensible. This is where you can store bugs, work items, etc. It's not as full featured as Clearcase or one of those systems, but it's adequate for doing most items.
Pretty solid extensibility. You can add your own check in policies, access the work item / source control via API (either via the client API or through the service interface).

Cons

Costs an arm and a leg. You can get a 5 person workgroup edition (for free with your MSDN subscription), but you'll have to saw off your arm (and leg) to buy enough seats for 6 people.
Setup is a pain in the ass. There are a bazillion (well, not that many) prerequisites and it takes forever to get them all installed (SharePoint, this, that, etc). Setting up the data tier on another machine takes some work as well. It's definitely not a turnkey, just run Setup.exe and accept the defaults installation.
Because installation is such a pain, recovery is a pain unless you backup the TFS as an image. The good thing is that you only need two things in a worst case situation to restore a TFS server: The SQL Server database backup and the report private key. Well, you can probably live without the key, but the instructions say that you need it.
The work item system in its current implementation does not support hierarchical data. That (very important) feature is supposed to be supported in TFS 2010. IMHO, you need a hierarchy to do a proper breakdown of any non-trivial project. I actually moved all the breakdown information into MS Project (shudder) to get a better breakdown.
No keyword expansion. This ruffled more than a few feathers as evidenced here. I've never used the feature in Source Safe, but to those who have used it, it is a sorely missed feature.
No sharing of files. This one is a bit annoying. While I've only used sharing sparingly, it's a very handy feature when you need it.
No shadow folder support. Once again, I've never used this feature. However, if you've depended on it - you'll miss it.

There are some notable differences for people that are used to Source Safe, such as:

TFS keeps track of everything in a Workspace. You have to get all the files that you want to work on before you can do anything. Also, if you don't check out a file in TFS, but you just make it writable, it will likely get overwritten because TFS didn't know that you wanted to do that. This causes all sorts of consternation for long time users of Source Safe. Martin Woodward does a good job of explaining Workspaces here.
Compares work a bit differently. In Source Safe, if you do a compare of a directory, SS will literally compare every file byte for byte and report any differences (which could take an eternity). On the other hand, TFS assumes that if you haven't checked out a particular file, it isn't different. That's how TFS operates so quickly. Most of the time it works the way you want, but once again, it's different than how it worked in SS.

I'm sure that there are many more pros, cons and differences, but those are the big ones IMHO / experience. Whatever Source Control solution you end up picking, make sure that you trial it to make sure that you can live with it. Once you have a bunch of data in the source control database, it's usually non-trivial to move it to another server.

ProjectGuids in Project Reference

2008-12-03T10:20:00.007-05:00

Why is it that it's always the little details that take the most time in any project / implementation? In my recent efforts to get Team Build up and running, I ran into some of the oddest things. The one that had me pulling what's left of my hair out was a very small thing - the .

Normally, in the course of developing a .NET project, you can pretty much ignore the little details like what the projectGuid is for a given project. The problem that I ran into is that one of the project references had an oudated value.

This is the little beasty that was causing all of the issues (this is in the raw xml of the .vbproj file):

<projectReference include="..\MyClassLibrary.vbproj">&
<name>MyClassLibrary</name>
<project>{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}
<package>{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</package>
</projectReference>

It's rare that a projectGuid will ever change. In this case, we had to make the MyClassLibrary a VSTO plug in for word. I didn't do the conversion (and wouldn't have caught something like the projectGuid changing if I did), but for some bizarre reason we ended up with a new projectGuid for MyClassLibrary.

This is the little bugger that changed in the MyClassLibrary.vbproj file:

{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}

The fix was simple, all I had to do was copy the correct Guid to the tag of the other project and I was good to go. Finding that was absolutely horrible though.

Along the path, I found out that the solution would actually build after a complete rebuild. Apparently there is some voodoo happening with the ResolveAssemblyReference.cache files. I'm guessing that these "fix up" the references without changing anything in the original .vbproj files. We didn't notice it in our local build environment because these files were already generated with the correct overriding information. However, the build machine always grabs the source to a clean directory, so these files haven't been generated yet.

TFS Team Build

2008-12-02T13:58:00.005-05:00

It was the best of times, it was the worst of times. Team Build (as included in Team Foundation Server 2008) is a very powerful tool which can save all sorts of time by automatically building your code every time somebody checks something in. I've never used it, but TFS is supposed to do a lot of the things that Cruise Control.NET does out of the box. That said, it can be a pain tracking down all the resources you'll need to get your solution compiling like a champ. Here's what I did / used.

For the most part, getting started is pretty straightforward. However, there are a few gotchas. In general, you want a dedicated server to do the team builds. To get started with that, you need to install the build agent on that machine. The installation bits are on the Team Foundation Server install disc. The important part here is to set up the build service to run under an account that has access to TFS. If you screw this up the first time, just go into services and change the username / credentials for the "Visual Studio Team Foundation Build" (don't forget to restart the service).

After you've installed that, you need to set up your workspace. I followed Buck Hodge's advice on getting that going.

Now, some special cases. If you are signing any of your assemblies with a .pfx key, you'll want to import that onto the local machine. Here's some advice.

Another item to keep in mind is that the solution will be built with a slightly different folder structure. This can cause problems if you have a post build step that copies files (e.g. if you have some plug in type files that aren't directly referenced by the main application project but the app needs them to run).

This approach work fine on the local machine, but not on the build server. To make something like this:

copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"

work on the build machine, you can do something like this:

IF EXIST "$(SolutionDir)MyApp\bin\Debug" copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"

That should work in most cases (your mileage may vary).

I haven't tried setting up an unit tests to run automatically. If / when I'll do, I'll likely post about that too.

Internationalization

2008-12-01T12:53:00.000-05:00

How many times have you gone through this scenario? You start out a project, and you ask all the right questions including:

Will this application ever need to support multiple languages?

More often than not, this answer will be "No, that's crazy. Don't add support for that. It will take way too much time".

Now fast forward months / years into that project. How many times do you find out (usually in a conference call) that some huge customer in Elbonia that wants to buy a bazillion licenses of your software, but only if it's localized in Swahili.

This is the part of the story where the developers usually try to explain how difficult such an endeavor would be and that the next planned release will be postponed by orders of magnitude.

As in most cases, an ounce of prevention is worth more than a pound of cure. The only way to avoid this miserable situation is to build in internationalization support from the beginning. There are numerous objections to supporting this from the beginning:

It will take too much time to add support for multiple languages
It's too burdensome to add new strings
Working with the UI is too much of a pain

These concerns can't be dismissed. These are valid complaints / obstacles. However, it's worth pointing out that there are some benefits to going this route from the beginning, even if the PHB never makes the dreaded "We need to sell this thing in Russian" call:

All of the strings are in one place, so it's easy to maintain phrasing style for the whole project even with multiple developers.
Common strings can be reused (e.g. Cancel, OK, Username, etc). If a decision is made to change one of those, it gets changed everywhere.
Testers can usually make changes to spelling, phrasing, etc without bothering the developers. I've spent way too much time correcting spelling, phrasing errors when a tester could have just done it themselves if they had ready access to the strings.

Oh, and when you get the last minute call that you need to translate the product, it will be no big deal.

Damn, I'm not spamming!

2008-11-07T09:07:00.001-05:00

Wow, this blog is off to an amazing start... I haven't even had a chance to post anything, and google has marked this blog as a potential spam blog.

Here is the message I received:

Your blog at: http://fowlcoder.blogspot.com/ has been identified as a potential spam blog. To correct this, please request a review by filling out the form at [link removed].

Your blog will be deleted in 20 days if it isn't reviewed, and your readers will see a warning page during this time. After we receive your request, we'll review your blog and unlock it within two business days. Once we have reviewed and determined your blog is not spam, the blog will be unlocked and the message in your Blogger dashboard will no longer be displayed. If this blog doesn't belong to you, you don't have to do anything, and any other blogs you may have won't be affected.

We find spam by using an automated classifier. Automatic spam detection is inherently fuzzy, and occasionally a blog like yours is flagged incorrectly. We sincerely apologize for this error. By using this kind of system, however, we can dedicate more storage, bandwidth, and engineering resources to bloggers like you instead of to spammers. For more information, please see Blogger Help: http://help.blogger.com/bin/answer.py?answer=42577

So, hint to all new bloggers using blogger.com - fill out some profile information and post something, or you'll have to go through this process as well.