The goto statement revisited – level 200

I received quite a bit of comment on my previous post, so I did some more research on the matter.  My conclusion is that the usage of goto has no impact on the functionality of the program itself, but the usage of goto can open the doors of temptation to be a lazy coder and have a final product that may function perfectly well but is difficult to maintain.  I have decided to replace my usage of goto with a switch statement. 

I can also imagine that the more broader use of goto can make debugging confusing because of an unpredictable stack trace in thrown exceptions.

On another note, my friend, Noah Coad, will be starting work at Microsoft in about a week.  He’ll be working on the VS.NET team helping to shape the IDE of the future!  He’s a great WinForms programmer and a C# MVP.

Unit Testing support should be included in VS.NET Pro along with Team System – level 000

Peter Provost is starting a blog petition related to unit testing features in VS2005.  I don’t agree that Unit testing support should be in ALL versions of VS.NET, but I would like it to be in the Pro version and not just Team System.  I would, however, think it to be a good idea if MS offered a stripped-down version of VS.NET that cost in the $100s and not the $1000s so that more people can have access to the software.  Maybe a web IDE like Matrix with Intellisense added.  Something for small shops that don’t need 20+ people all working on the same project at once.

c# Naming Conventions recommendation – level 100

Recently my team began the process of revising out coding standards document.  We are revisiting this issue because the standards were developed when we used VB 6 and ASP 3.0.  I have offered my opinions to the team, and I’ll post them here.  Comments are welcome.  


To throw in my opinion, I would agree with the below proposed changes with the following exceptions:

All pulic, protected, or internal interfaces should use PascalCasing.

All private members should use camelCasing.

All private class members should be prefixed with “_”

“p_”, “m_”, “g_”, should not be used, and Hungarian notation should not be used.

For instance:

namespace GpdsIT.SomeRandomApp {
  public class IDBadge {
    private Guid _uniqueID;
    private string _badgeName = string.Empty;
    public Guid UniqueID {
      get { return _uniqueID; }
      set { _uniqueID = value; }
    public string Name {
      get { return _badgeName; }
      set { _badgeName = value; }
    public IDBadge(string badgeName) {
      _uniqueID = Guid.NewGuid();
      _badgeName = badgeName;

I’ll refer you to the MSDN Design Guidelines for Class Library Developers at

The Naming Guidelines link has naming convention recommendations that support the above rules, and the other links have very valuable information about .Net best practices.

Using Server 2003 on my development workstation – level 200

I’m currently finishing the installation of Windows Server 2003 on my development workstation.  I’ve heard and agree with the argument that you should develop with the OS on which your code will be running.  For me, it’s ASP.NET.  Especially with the bug in the XP large object heap, I’ve decided to make the switch.  We’ll see how it goes.  I like to profile my code, so I feel a little better doing performance testing on a server OS.  A limiting factor is that not all the software I use is supported on Server 2003, but so far all of it works.  For instance, MS Virtual PC 2004 isn’t supported, but it works fine.  I maintain in image of XP Pro that is the minimum requirements for user workstations, so I can test the UI with that.  All the code, however, will run on my server OS.  I’ve heard arguments for and against this approach, so we’ll see how it goes.  I can always fall back onto Windows XP if I have to.  If any readers have experience developing on a server OS (successes or failures), I’d like to read the comments.  I’ve heard several opinions, but none of the opinions against this method come from actually trying it.  Maybe in a few months I’ll post a follow-up article on how it is going.

EZWeb Beta Version 0.9 Released! – level 200

I’m am so excited.  I have released version 0.9 of my EZWeb framework on GotDotNet.  Major beta release.  I’ve made content editing part of page administration.  Fixed many bugs.  Created an extendable user framework.  Updgraded to FreeTextBox 2.0.6.  Added file and image upload feature.  Added SqlFactory class wrapper of the MS Data Access application block for data access in you application.  It’s almost worthy of being used as an application framework in a real project.  My next release will be version 1.0 stable release.  Please offer feedback.  I have not included more templates because everyone will want to make their own site look and feel anyway. 

EZWeb works out of the box.  Set up a virtual directory, give aspnet user write permission to it, and pull it up in the browser.  You can start creating your website right away.  Extend it with your own user by using ClientUserSample.cs as a guide and inheriting WebPrincipal.  Then change web.config to refer to your assembly for the user class.

This is an ASP.NET VS.NET 2003 project in C#. 

The next one-touch blog tool for .Text, NovaBlog – level 100

Noah Coad tell about his NovaBlog tool for one-touch blogging from the desktop.  A command-line tool for a true programmer.  After all,  are all programs written FOR programmers?  The command-line NovaBlog can be called from any text editor or integrated into any other program by calling it and passing the post information as arguments.  Whether or not the source code will be shared is still pending.  C’mon, Noah.  Do share!

How do I use a client’s type in my library assembly? – level 400

I have a library, and I use an Interface to define the required members of the clients “User” object in order for the client’s type to work with my library.  As long as they implement the members in my interface, everything is fine.  My Inferface implements IPrincipal, so it’s a standard .Net Framework user type.  It can be used in ASP.NET seamlessly.  When coding my library, I don’t know or have access to the client’s type that will implement my interface.  How, then, can I get it at runtime and code against it?  I have static and instance calls to methods in my interface.  The answer:  Reflection and runtime-loading of the client’s type.  Here’s some code I’m using to do it:

public static Type ClientType
Assembly ClientAssembly;
ClientAssembly = Assembly.Load(ConfigurationSettings.AppSettings[“UserAssemblyName”]);
Type clientType = ClientAssembly.GetType(ConfigurationSettings.AppSettings[“UserTypeName”], true, false);
return clientType;

This is a static property in my library to encapsulate the getting of the client’s type.  The client will have to define in the web.config file the assembly and namespace, and then we’re good.  Once I have the type, I can invoke the members using methods of the Type object.  I know the members I need to invoke because I’ve defined an interface, so the client’s object MUST have the members I need.  Now the client can have their own user object, and once they implement my interface, they are completely interoperable with my library which will make heavy use of their custom type.

The condemned “goto x;” jump statement – level 200

I’ve used all of the C# Jump statements.  You probably use break, continue, and return on a daily basis.  And in your switch statements, you probably use default.  But do you use the goto statement?  If you are like me, you’ve been conditioned since QBasic to avoid the infamous goto statement.  It creates spaghetti code, right?  Well, if you use it irresponsibly, it does, but what about nested if statements?  How do you jump out of 2 nested if statements?  break and continue don’t work.  My solution:  Use the goto statement.

if(condition 1)
if(condition 2)
goto endIf;
statement-that-should not happen if condition 2 is not met;
endIf:; //label to jump to and empty statement included.

You can probably think of several ways to refactor the above in order to avoid the goto statement, but in this case, the goto statement was the best decision, and this is a very valid use of the statement, and it does not create spaghetti code.

Re: Explanation of dynamic ASPX compilation and recompilation – level 300

To expand on my previous post, here is a reply I received from Dino Esposito about what goes on behind the scenes on a page request:

Hi Jeffrey

1) The runtime figures out the name of the class to serve that page request.  If the class can’t be found in any of the loaded assemblies, the source is compiled. If the class is found (means the page’s been compiled already), it checks the timestamp of the class against a value stored in an internal store. If they differ, it assumes the page has been compiled. This happens with ASPX files

2) If you change the CS/VB nothing happens and an explicit compile step is required

3) Changes in inline code trigger the recompile