SSMS 2008 add-ins: one problem solved

If you Google SQL Server Management Studio Add-Ins, you'll find quite a few articles on writing them for SSMS 2005.  You'll also find people complaining that they can't get them to work in 2008.

I can't add any useful comment on the changes made in assemblies between versions, because I didn't attempt writing an SSMS add-in until I'd already upgraded to 2008.  However, I did encounter one problem right away when I attempted to write an SSMS version of a VS 2010 add-in, as have others.  The boilerplate code in the OnConnect method, which was generated by VS, would fail on this line:

     public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)

     {

           _applicationObject = (DTE2)application;                      

           _addInInstance = (AddIn)addInInst;

The error message was “No such interface supported”.

A little poking about, and it became clear that this is because, well, the host application isn't a DTE2 anymore.  It's a SSMS object with a very long name and no obvious connection to the DTE2.  Which is a problem if you need any of the DTE2's properties, as you probably do.  

But the fix is easy.  The addInInst object has a DTE property that is, in fact, of type DTE2!  So all you have to do to get over this speed bump is to change those two assignment statements:

    _addInInstance = (AddIn) addInInst;                                    

    _applicationObject = (DTE2) _addInInstance.DTE;

And carry on from there.

Things I'd Like To See, #765

I'd like to be able to put attributes (à la .Net) on Sql Server columns.  I'd like to be able to flag certain columns so as to indicate that these columns with the name UserId that relate to the master User table are for change tracking, as opposed to other columns called UserId that relate to the User table but might be part of security or personnel records.

Why do I want this?  So that I can run queries to ensure that standard columns all have standard definitions.  Standards are only standards if they're enforced, after all.

This came up because I stumbled upon a standard column with some non-standard characteristics today, and had to write a change script.  If we had an equivalent to FxCop that we could apply to table definitions and stored procedures, we could keep an eye on these things and catch them before they got to production.  Being able to run a metadata query to ensure that all columns with the attribute "TrackingUserId" had a certain definition would be a good start.

(Before you suggest it, let me say that I know we could probably simulate this with extended properties.  If I were staying longer on this project, I might try to implement that.)

Useful Things to Know, #425

You can call an extension method on a null class instance.

For example, if you have an extension method IsEmptyOrWhitespace on the class System.String, the following code will work:

string s = null;
Debug.Writeline(s.IsEmptyOrWhitespace());

It makes sense because the string s is actually passed as a parameter to the method IsEmptyOrWhitespace.  Therefore, if you code the method correctly, it'll accommodate a null value and respond in whatever way makes sense.

It's interesting because it's a place where the facade of the extension method actually being an instance method of the class breaks down.  (But I wouldn't code on the assumption that this will always be true!)

Why does this fail?

This code throws an InvalidCastException, on the grounds that you can't convert a DateTime to anything else but a string.  But I didn't think I was converting a DateTime:  I thought I was converting a nullable DateTime.

DateTime? nDate = new DateTime? (DateTime.Today);

Convert.ChangeType(nDate, typeof(DateTime?));

Tomorrow I will research this.

ETA:  The answer.

Advice to New Programmers, Part I

I was talking to someone who was a professor of Management Information Systems at a local university not too long ago.  We were talking about his students and how they would do at their first jobs.

Now, I have quite a bit I can say on the subject of new programmers and mistakes they tend to make, most of which I know from having made them myself and taken the consequences.  But I'll spare you that (for now) and just list some books that young programmers ought to read:

The Programmer's Survival Guide, by Janet Ruhl.  This is over 20 years old, and much of what it says about the IT environment is extremely dated.  Network management and web page design had barely been conceived when this was written.  Nonetheless, the advice on legacy code, legacy people, getting along with your peers, and relating to management is still quite sound.   Ms. Ruhl has since written The Computer Job Survival Guide, which I have not read, but which supposedly has updated advice.

Games Mother Never Taught You, by Betty Lehan Harragan.  This was written, I was surprised to discover, back in 1977.  The world has changed (in spots) since then.  If you find the idea of office politics uncomfortable, this book can scare you to death: its tone is harsh, and the picture it paints an intimidating one.  But you still ought to read it.  Not all organizations work like the ones described in this book, and not all those that do are like that on the lower levels, where the programmers are.  But I've seen things in my career that only made sense in light of what this book teaches. 

Keep the Joint Running, a regular column by Bob Lewis of IT Catalysts.  Possibly the most sensible man currently writing about information systems (as opposed to pure programming), Lewis consistently gives good advice to both IT workers and business managers. He's entertaining as well as insightful, and leaves you with the sense that you've both gained something useful and learned to see a little more clearly.