Developing For .NET

The software I’ve been developing needs to be accessible from the command line, and in those cases it needs to be able to receive parameters in order to properly initialize the application instance.  I’d done this plenty of times in Windows Forms, but when I started looking for the public static void main entry method, I couldn’t find it.  It didn’t take long to find the answer, but I thought it was worth sharing.

Windows Forms

In Windows Forms, the way I’ve always done this is to add a string[] args parameter to Main(), which is found in “Program.cs”.  Then I override the Form constructor and pass the array to the Form.  You can also use Envorinment.GetCommandLineArgs().  That post had a couple of comments where the users seemed concerned because the first element of the array contains the full path to the executable.  If you choose this method, simply ignore index 0 and you can access the parms in exactly the same way.

WPF

The method in WPF is the same basic concept, but it occurs in a slightly different way.  Right off the bat, you’ll notice there is no “Program.cs” and no Main() method to process.  Instead, the entry for the application is found in “App.xaml.cs”.  There is no entry method here like Main: in order to process the incoming paramters, we need to add a listener to the App_Startup event.  This event will fire prior to the Window class being executed. In order to hook the event up to the application, edit “App.xaml” and add Startup=”App_Startup” to the Application declaration.

The event includes a StartupEventArgs object, which contains a reference to the Args array, so you would simply parse it as desired just like in the Windows Forms Main() method. The difference with WPF is that we do not have a call to the Window class exposed like we do in Windows Forms.  What we do have, in the Window class, is access to the Application object itself.  Microsoft’s sample, downloadable from MSDN, creates a static variable in the App class and populates it in the App_Startup event.  The Window class then accesses the static App variable for its access to the command line arguments.

The sample above parses the values and stores them in a Hashtable (yuck!), so obviously we have some better options, like a generic Dictionary.  Or even better, how about a custom class that holds the values you want?  This would be especially good if some of the values are not strings, or to enforce business rules on the incoming parameters.  I like this approach because it allows all the parsing work to be done outside the Window, leaving the Window to only determine how to use the results.  It just feels better to me since one of our primary goals with WPF is separating layers of responsibility.

If you don’t like the process above, or you really want to handle the parsing inside the Window class, you still have access to Environment.GetCommandLineArgs(), and it works exactly like it does in Windows.Forms.  Again, you can just ignore the 0 index and process the arguments directly.  Oh, and if you are a real glutton for punishment, both methods include the Environment.CommandLine property, a string that represents the complete command line entry.

Debugging Command Line Parameters

I hate trying to navigate through the DOS shell (excuse me: Command Prompt) to find the exe file of my project in order to test command line argurments.  Fortunately, we don’t have to!  If you go to the main menu and follow Projects -> “xxxApplication Properties”, and then click on the Debug tab, you’ll find a box where you can enter the Command Line Arguments you want to test.  As expected, they will be included when the application begins and you can debug their values.