As developers we're constantly faced with the need to crank out good quality code.  This isn't often the easiest task, especially with the mounting need to stay at the forefront of technology.  Visual Studio, while a powerhouse development environment, can only offer so much.  Here is a great list of tools that should be a part of every developer's toolkit.  These tools will aid in the generation of good, quality code and keep the productivity high.  Additionally, Scott Hanselman has his Ultimate Developer and Power Users Tools List, a recommended set of tools that all developers must know how to use.

Of these tools, I have loads of firsthand experience with NDoc (love it!) and FxCop (currently version 1.3) and the Regulator.  I've played with several others.

Some other tools that I really find useful and enjoy are:

Aaron Skonnard's XML Tools

The VS.NET Command Prompt (invaluable - I moved this shortcut to my Start Menu for quick access)

ISO Recorder - invaluable tool for creating images of your CDs

Notepad 2 - A very capable replacement for the boring, ordinary Notepad...try it out! it's awesome!

UltraMagnifier - Excellent tool for giving presentations

What tools do you use?

Designing applications can be a daunting task.  Even the simplest of utilities can present obstacles and issues unforeseen.  Enterprise-level, distributed applications present problems on a greater scale: security (authentication and authorization), distributed transactional support, object pooling, JIT, just to name a few.  Trying to roll your own infrastructure to support these features reliably is extrememly difficult - go ahead and try.  I think every developer has tried to implement some of these features at least to some degree.  But trying to harness all of these capabilities, especially when they already exist, is asinine and a fool's quest.

Over the past several months, I have been asked repetitively by various individuals (both coworkers as well as friends and associates) whether COM+ is a thing of the past.  I've been told that Microsoft is no longer investing in COM+ services and that it's been deprecated; that Enterprise Services (aka COM+ in the .NET world) is just a COM-interop layer over the actual COM+ implementation provided by the OS.  These statements couldn't be further from the truth.  Enterprise Services is alive and kicking.

As Brian Noyes points out in his blog post, there are a lot of misconceptions about the positioning of Enterprise Services with respect to developing solutions with .NET.  It is frequently viewed as a thing of the past and therefore legacy software that doesn't really have a place in modern software development.  When Microsoft developed COM+ (which, in its inception was Microsoft Transation Server (MTS) and part of the Windows NT 4.0 Option Pack) they were very forward-looking and to their credit succeeded admirably.  If you take the time to read Microsoft's Prescriptive Architecture Guidance (PAG), you'll see that even today in the building of distributed, n-tier applications we are encouraged to use Enterprise Services.

One of the reasons I've heard that discourages its use is the whole COM-interop thing.  There are really two ways in which a COM+ application can run: as a Library application or a Server application.

When a component is a Library application, it runs in-process with the caller.  If you've developed your COM+ component in .NET there is no interop at all.  All calls to your COM+ component are direct, managed C++ calls to the subsystem - this will be very fast, just involving a context switch.

When a component is a Server application, then yes, COM-interop enters the picture.  A Runtime Callable Wrapper (RCW) is created.  It is through this proxy that calls to the object occur.  All in all, this overhead is minimal especially when compared to what the actual function will probably be doing.

With respect to the future, however, is COM+ going away?  Is Microsoft abandoning their flagship component server?  I think not.  When you look at what is up and coming such as Indigo it might appear that COM+ is going by the wayside, in preference to this newer technology.  In fact, COM+ is being enhanced to support calls to an from Indigo for a seamless interoperation in the Longhorn timeframe.

Basically, when it comes down to it, we are still being encouraged to use Enterprise Services in the back-end as the service provider for our applications, inside the service boundaries.  Usually, the recommendation is that the service boundary be actually implemented via another mechanism such as Web Services (eg: ASMX, WSE).

Enterprise Services offer many other benefits that I haven't mentioned here, but I believe that many developers are afraid to embrace the technology for fear of the complexity and breadth of its coverage.  Sure, COM+ can be a bit daunting.  It isn't simple, but as developers it is our responsibility to learn about the various technologies and apply them where they best fit.  I'm convinced that by using COM+ properly our applications will be better prepared for the today as well as for the future.

A few months ago I had the privilege of presenting a talk to our local .NET User Group regarding component development in COM+.  Check out the presentation.

---
Update 06/17/2004:

Some helpful COM+/Enterprise Services links:

GotDotNet COM+ FAQ
DCOM deserves our respect
.NET Enterprise Services Performance
Enterprise Architecturing II

As a seasoned component developer I was a bit disappointed when I first made the move to .NET with respect to (really only) one thing:  the ability to scope the property getters and setters individually.  Back in the good ol' VB 6.0 and C++ days, it was common practice to create a property that was readonly externally and public internally to the application.  This simplified semantics and the programming model was simpler.  However, when I came into .NET I found abruptly that I would have to create a readonly property and then a separate accessor function to set the value of the property internally:

public int Age {
   get { return _age; }
}

internal void setAge(int value) {
   _age = value;
}

I am very excited to learn that in the Whidbey (Visual Studio 5.0) timeframe we'll get scoped property accessors.  Now the syntax would be like the following:

public int Age {
   get { return _age; }
   internal set { _age = value; }
}

As Eric Porter reminds us, this is not just a C# feature, but you'll be able to do the same thing in VB.NET:

Public Property Age() As Integer
   Get
      Return _age
   End Get
   Friend Set(ByVal Value As Integer)
      _age = Value
   End Set
End Property

I can't wait for this enhancement!

Yesterday I received my new laptop.  It's a new Dell Inspiron 8600.  I must say that so far I am impressed.  It's a blazing Pentium M 755 (2.0 Ghz) with 2GB of RAM.  With the WUXGA (1920x1200 res), 60 GB 7200 RPM hard drive, and the DVD+R/RW I am loving it!  I'm still in the process of setting it up, but I'm very excited.

As a matter of habit, the first thing I do when I get a new computer (PC or otherwise) is blow away the OS (archiving drivers of course) and install anew.  At first I wanted to use Windows Server 2003.  It installed flawlessly; that is, until I got to the video driver.  The video driver installed ok but upon reboot it incessantly blue screened.  It was frustrating to not find a Win2k3-compatible video driver on the Dell site.  I was forced to fall back to Windows XP, which I enjoy as well, but I would have preferred Win2k3...oh well...no worries.

Sorry for a non-technical post, but I just wanted to get this off my chest.

Being from Salt Lake City, Utah, this may sound like I'm turning on my own family, but believe me I'm not.  Pretty much all of the people I know didn't want the Los Angeles Lakers to win the NBA Championship.  It's not because we're anti-Lakers.  In fact, were it anything else, I wouldn't have minded at all if the Lakers had won - I've always been a fan.  Everyone is anti-Malone (Karl Malone).

Aside from being a constant whiner and complainer, Malone is a lousy human being.  I know - I've met him so my bias isn't all based on second-hand sources.  I think it's hilarious that he left the Utah Jazz for the Lakers (even accepting a cut in pay - amazing!) as a perceived guarantee to winning the championship.  That's pretty selfish if you ask me, especially for man who admittedly has no ego...at least I think that's what he said; it was hard to understand him due to his inability to speak intelligently.  Additionally, after being one of the key reasons that the Jazz didn't win the Championship when they had the chance, he was pretty much a non-factor to the Lakers and didn't help the team at all through the Championship series.

I am so glad he didn't get his championship.  Evil, I know.

Upon reading this post by Martin Spedding, I got to thinking about where Microsoft Visual Studio fits into the scheme of things.  Martin argues that Visual Studio leads developers down the seductive and misleading path of least resistance in application development.  For instance he mentions that Visual Studio will place the app's public void Main() within the WinForm application's Form1.  I agree that this is a particularly nasty practice and I agree with him that it is poor design, but that is in no way the fault of Visual Studio.

First and foremost, this practice begins to combine application startup code with the WinForm, which may (and arguably should be) completely independent of one another.  This mentality hearkens back to the Visual Basic days in which the app's startup object could be a form vs. a Main() procedure.  This can be pretty nasty because if you remove your form file to create a more appropriately named form (which I am very inclined to do), you lose your application's startup code.

Ok, that aside, I don't believe that it is the role of Visual Studio to enforce a layering separation in our code.  Visual Studio is an editor.  It's an IDE.  It offers functionality as defined and prescribed in the language engines (such as syntax coloring, intellisense, and much more).  It's an immersive experience to work in Visual Studio because it brings so much together, but it shouldn't be telling me how to write my code.  When it comes down to it, the problem with the aforementioned non-separation of code isn't the fault of Visual Studio at all...it's all in the template files that it uses to create a new project.  If anything those should be fixed.

I firmly believe that the layering approach to application development is the right way to design and develop applications for a lot of reasons.  Developers should be taught and nurtured with best practices, but that's not the responsibility of the IDE...fix the templates.

If anyone is interested, I've updated all of the scripts, html files, and template .cs files that VS uses that helps promote best practices and eliminates unnecessary dependencies (such as System.Data and System.Xml which I don't use unless I need to).  Saves a few clicks whenever I start a new project.  Just let me know!

Well, I know this might be difficult for some people to hear.  In fact, some might find it appalling.  I like Visual Sourcesafe.  Yes, I have had my issues with it in the past and there are some, ok, many things that beg to be improved, but for the most part it has served me well and has done a fairly good job of maintaining my source code.

Tonight, however, I ran into an issue that was driving me nuts.  I was attempting to add a user to my SS server and it would repeatedly fail with an 'Invalid DOS path: C:\...\users' error.  In fact, it would go so far as to create the user's directory, but that was it.  It was supposed to also create a ss.ini file within the folder.  At first I thought it was a permissions error (but that didn't make sense because it was creating the directory in the first place AND I was logged in as an Administrator on the box).

After a bit of searching online, I found a link to http://support.microsoft.com/?id=149378 wherein I discovered that I was missing a file named 'Template.ini'.  Upon creating this file, everything worked peachy.  The question I have now is this: How did I come to be missing this file when I've created users in the past?

I wish SourceSafe had some built-in mechanisms for recovery and error handling that actually explained the error, it would save us lots of time on the diagnosing the problem.

Last night's .NET User Group meeting was pretty awesome.  A great friend of mine from Microsoft, Matt Smith, gave us a presentation on the new and upcoming version of Visual Studio called Visual Studio Team System (VSTS); it is code-named “Burton“.  This product was officially unveiled at TechEd so this was a great presentation for those of us that didn't get a chance to attend TechEd.

VSTS rocks!  What I really liked about VSTS is what it's name implies: Team.  It is very heartening to see that MS is making great strides and in-roads into placing the software development process into its flagship development environment.  VSTS encompasses the entire gamut of application development - from the initial concept and envisioning stages all the way through design, development, and testing, to deployment and maintenance.  One very cool aspect is that you can define an application development methodology (such as MSF) and incorporate that directly into how you interact with Visual Studio.  The methodologies are extensible as well so you can even create your own, in-house methodologies.

VSTS seems to really drive home the concept that the team is an integrated, cohesive unit.  I absolutely loved the integration with SharePoint and I feel this will even further enhance the sharing of information across the team.

The things built into VSTS are not all revolutionary - some have existed in other forms and in other tools, but it does offer them in a completely integrated, end-to-end offering which is very exciting.

These are a few of my favorite capabilities built-in (in no particular order):

• Integrated Source Control - the new source code control system (written from the ground up) leverages SQL Server as its back-end data store.  This eases backups as well as makes the data universally more accessible.  Plus when creating a new project in VSTS you start out integrated with the source control system with a new branch.
• SharePoint - when creating a new project you can immediately create a SharePoint team site.  This is fantastic because all team members can automatically see schedules, tasks, and deliverables and share information and documents with each other.  If you haven't had a chance to work with SPS, do!
• Tasks - members of the team can associate tasks (or be assiged tasks) that must be completed.  This goes further than simple 'fix this bug' tasks.  Policies can enforce rules associated with the tasks so that code must be tested and verified before it gets checked into source control.  Awesome.
• WhiteHorse - this is fantastic.  This modeling tool enforces that the model is the code is the model.  You have to see it to believe it.
• FxCop - I am very excited to see FxCop built into VSTS.  Rather than being a separate step in the application development process, you get the warnings to frequent gotchas right in the dev environment.

The list goes on and is not limited to the above, but includes also the built-in performance analysis, stress tests, daily builds, etc.

This is really gonna be a great tool set.  I have a feeling that this package is going to feed coal to the Whidbey freight train.  What is that? Do I see a coffee cup on the train track?

While flying back from Santa Barbara I had a few minutes to sit back, relax, and work on my PC version of The Settlers of Catan.  The coach steward noticed it and was amazed by it.  We spent several minutes talking about it and how it's just a fun game.  This was quite reassuring.  I guess this game's popularity is just booming, especially here in Utah as I now see it almost everywhere.  I'm now even more envigorated and want to see it through to completion.

Today (rather, tonight) I focused on aspects of the player's turn and UI state.  Also, I began work on a different type of hexagon hit test.  You may have read what I posted previously on hexagon hit testing.  This is kind of test, rather that checking for a hit test on the hexagon itself, focuses on hit tests against the corners and the edges (with a certain allowance on either side to make the selection easier).  I'll post my code when I have it working...should be soon!  Also, I extended the hex hit test further to allow (or deny) certain type of hexes to be selected.  This is important for game play because there are times where only water hexes or only resource hexes can be selected.

Just wanted to jot down some thoughts and observations before I retire for the evening.  I had the opportunity to spend this last weekend in California working with a good friend of mine on some software.  It was a gruelling set of days, but such is the way and life of a devout coder (or so I hear - maybe I'm just denying myself the good things in life).

The application that we are writing targets the ASP.NET platform.  One of my tasks this last weekend was to take what we had started recently and migrate it to be more of a component rather than written directly into the website.  This was our intention all along but time restraints caused us to reevaluate our immediate priorities and coaxed us down a different path.  Fortunately, we designed it in such a way that facilitated a reengineering.

The goals in 'componentizing' this application were the following:

• Remove it from the existing sample website (test harness) - DONE
• Write it in such a way to support templated layout - IN PROGRESS BUT DEFINITELY SUPPORTED
• Be able to 'plop' it down in an existing website and with very few changes (no recompilation) have the whole product just work - DONE

In (re)writing this, I also had a personal goal of having the component be deployed once to the web server instead of within each virtual directory.  I'd like to support both installing the app once on the web server for all sites/virtual directories to use it (though this implies some common security across the sites - maybe not such a good idea) as well as installing it individually in the site/virtdir that uses it.  Such functionality hearkens back to the good ol' days of the System Registry.  Well, this is best accomplished in .NET with the Global Assembly Cache (GAC).

So here's what I did:

The natural choice in designing the component was to write a Web Server Control that, when compiled, yields a .dll.  Web server controls can be easily integrated within other websites and also offer several advantages over their .ascx (HTML Server Control) counterparts such as client browser detection, a nice clean object model, templated child controls, and much more.  This was exactly the functionality I needed.

A while back I had written a batch file that I use during the project's Post-Build Event.  This batch file copies the newly compiled assembly to a version-specific folder, unregisters it from the GAC if the same version was already registered, and registers it anew.  If you want a copy, just let me know and I'd be happy to send it to you.  It wasn't until I employed this batch file that I realized that it wasn't really well suited for Web Server Controls due to a peculiarity with the ASP.NET worker process.

As it turns out, if your website utilizes a GAC-registered Web Server Control, the worker process (aspnet_wp or w3wp) copies your control dll into a subfolder within WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files at runtime and holds onto it for dear life.  This was manifested by the fact that changes made to the server control were never reflected within the browser.  This basically means that if you want to use a GAC-registered component that is in development, you'll have to kill the ASP.NET worker process after each compilation.  This was incredibly frustrating.  Now if there is an alternative to this, I don't know what it is, but by the same token I haven't looked into it hardly at all.

Needless to say, I reneged on my desires to have it GAC-registered and settled for having it copied into each virtual directory.  This resulted in a much easier and productive development experience.  Who knows, maybe I try to do things the hard way too often.

I just had an interesting discussion with a coworker of mine and wanted to write down my thoughts on the matter.  The question revolved around whether it was preferred to call Close() or Dispose() on a SqlConnection.  This discussion obviously extends to pretty much any IDisposable/Closeable class but for clarity I'll focus on the SqlConnection object.  His question was spurred on by a snippet from the MSDN documentation that states that the Close() method 'is the preferred method of closing any open connection.'  His question goes a bit deeper than this seemingly inocuous question.  The SqlConnection seems to go counter to some other MSDN documentation that indicates that Close() should call Dispose() where Close() is a more natural means of shutting down an object.

To begin, let's take a peek at what our good friend IL DASM has to say on the matter.  Opening up the IL for the SqlConnection.Dispose() we see the following:

...
IL_000a:  ldloc.0
IL_000b:  switch     ( 
                      IL_0020,
                      IL_001a)
IL_0018:  br.s       IL_0020
IL_001a:  ldarg.0
IL_001b:  call       instance void System.Data.SqlClient.SqlConnection::Close()
IL_0020:  ldarg.0
IL_0021:  ldnull
IL_0022:  stfld      class System.Data.SqlClient.SqlConnectionString System.Data.SqlClient.SqlConnection::_constr
...

As we can see, when Dispose() is called, it first does a check to see if the connection to the database is open (an extraneous check in my book, but oh well) and then it calls Close() if the connection were open in the first place.  Afterwards, it nulls out the connection string.  Now we all know that once an object is disposed it should no longer be used.  An advantage to calling Close() is that you can in effect reopen the connection on the same SqlConnection instance.  When Close() is called (or Dispose() by virtue of what it does) the connection is not actually closed but is returned to the database connection pool - remember that the connection pool is a collection of SQL Connections, not SqlConnection objects.

When deciding on whether you should call Close() or Dispose() you may be persuaded by language constructs to elect one over the other in certain circumstances.  For instance, as a devoted C# developer I find the using() {...} pattern very persuasive.  The advantage of this is you can in essence avoid having to call Dispose() as it will automatically be cleaned up for you:

string getUserName(string id) {
   using ( SqlConnection cn = new SqlConnection(“...“) ) {
      // open the connection
      // execute scalar to retrieve the name
      // return the name
   }
}

Okay, that may be a bit simplistic but it gets the idea across.  If you're using a different language, say, Visual Basic you'll have to jump through other hoops:

Function getUserName(ByVal id As String)
   Dim cn As SqlConnection
   Try
      cn = New SqlConnection(“...“)
      ' open the connection
      ' execute scalar to retrieve the name
      ' return the name
   Finally
      cn.Dispose()
   End Try  
End Function

Obviously I have neither of these snippets of code have been tested - I typed them in here and not within the IDE.

As for a recommendation, it's hard to say.  I definitely have a preference, however: use Dispose(), especially for one-off, autonomous database operations.  Ok, I guess the recommendation would be to call at least one of the functions - don't not call one.  If you have to choose one over the other, call Dispose().  At the end of the day, however, this probably won't be the straw that broke the camel's back...code it how you see fit for your circumstances and how you like. 

I owe lunch to a great friend of mine for helping my solve this.  Jason Walker (a fellow member of our .NET User Group leadership) was kind enough to research an issue I was having.

The team up at Redmond was kind enough to include a method called EnableVisualStyles() in .NET Framework v1.1.  This method alleviates the need to include .manifest files for each .exe for which you want the sleek, cool Windows XP look and feel.  This method should be called prior to any UI or control being presented so it is routinely the first line of code in your app's entry point.  I suppose (for I haven't looked deeply into it yet) that calling this method internally performs a PostMessage() operation which is an asynchronous, fire and forget method (vs SendMessage() which is synchronous).

Through heartache and pain I have found that if your application displays a modal dialog window an exception will be thrown when the dialog closes down.  Well, I was programming along and all of the sudden I was greeted by a very noxious-looking and uninformative System.Runtime.InteropServices.SEHException when a wizard that I had written (which is displayed as a modal dialog) shut down.  It didn't occur to me that my call to EnableVisualStyles() was the offender of this obscure error.  I was trying to figure out whether it was something to do with some custom non-UI to UI thread marshalling or something of the like.  The stack trace revealed the following:

SEHException at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at
System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(...)
...

I should have read the stack trace more closely before applying my own rationale to solving the problem.

The solution is to call Application.DoEvents() just following the call to Application.EnableVisualStyles() so that the message posted has a chance to complete before proceeding.