Application Settings are the recommended way to save state between runs of your program. Long gone are the days of using the registry or INI files to save information. The only problem with Application Settings though is that they tend to disappear whenever you release a new version of your application. Fortunately, it is easy to fix this with some boiler plate code.

First, we need to make sure that our project has a settings file. It is usually under the Properties node of the project. If it is not, right click on the solution and Add | New Item… | Visual C# Items | General | Settings File and name it Settings.settings. Next, drag it and drop it in your project’s Properties folder.

Next, you need to add a bool User setting called UpgradeRequired and default it to true. Next, at the very beginning of your Main, you check if UpgradeRequired is true, and if it is, upgrade the settings, set UpgradeRequired to false and save out the settings. This will pull in the settings from previous versions of your application.

Your settings should look like this,

The code should look like this,

static void Main( string[] args )
{
   // Upgrade settings if required
   if ( Properties.Settings.Default.UpgradeRequired )
   {
      Properties.Settings.Default.Upgrade();
      Properties.Settings.Default.UpgradeRequired = false;
      Properties.Settings.Default.Save();
   }

   // Do work...

   // At the end of main, save out any changes to settings
   Properties.Settings.Default.Save();
}

Now you just need to create new settings and use them in your application. Any setting with Application scope will be set in your app.config and will be read-only. This is often used for connection strings and other information that is unlikely to change. User scoped settings also have their default values in app.config, but any changes are written out to an XML file in the user’s AppData folder.

Also, notice that code gets generated for any setting that you create and you access it through a property on Properties.Settings.Default. You can use any complex type for a setting, including classes in your application, as long as they are Serializable.

Most of the installation instructions for the ruby debugger that I found were out of date for Windows, so I thought it would be useful to document how I got it working.

1. First, you should start with Ruby installed from the RubyInstaller. If you have any problems with getting debugging working, I would suggest installing Ruby fresh from here and trying again.
2. Second, you need to install DevKit. Download DevKit from the RubyInstaller page, then follow the installation instructions on the Development Kit page. Their instructions are thorough, so I won’t reproduce them here. The DevKit install has changed recently and this was part of my problem getting the debugging gem installed.
3. Install the ruby-debug-ide19 gem with the following command line.

   gem install ruby-debug-ide19 –platform=ruby

4. You should now be able to debug in RubyMine. When I started debugging in RubyMine, it prompted to install additional debugging gems. I allowed it and they installed fine and debugging started.

1. Set a breakpoint by clicking in the gutter where you want the breakpoint

   

2. Select your run/debug configuration in the toolbar and click on the Debug button

   

3. Visit the page you want to debug in your browser. You should hit the breakpoint and see the callstack and the values of all the variables in scope.

   

4. You should now be able to step through the code. See the RubyMine debugging documentation for more help.

It seems that whenever I set up a new computer to debug PHP, I need to Google around to remind myself of the steps, so I thought I would document them here for reference. The following is for an XAMPP Apache/PHP install, but the basic steps are the same for any PHP install.

Install and Configure Xdebug for PHP

The first thing you need to do is get the Xdebug extension for PHP installed and configured. Luckily, XAMPP ships with Xdebug and has the configuration already in php.ini, so you just need to make some minor changes and restart Apache.

1. If you are also using XAMPP, skip this step. If you are using an install of PHP without the Xdebug extension, go to the Xdebug Find Binary page, paste in the output of phpinfo() or php –i and they will provide a link to the extension and custom installation instructions.
2. Open php.ini in your favourite editor. For XAMPP, it is likely in C:\xampp\php.
3. Find and uncomment the extension.

   zend_extension = "C:\xampp\php\ext\php_xdebug.dll"

4. Find the [XDebug] section and uncomment and/or edit the following values. Many of these are defaults, but I am listing them just in case you have different values.

   xdebug.profiler_enable = 1
   xdebug.profiler_enable_trigger = 1
   xdebug.remote_enable = 1
   xdebug.remote_host = "localhost"
   xdebug.remote_handler = "dbgp"
   xdebug.remote_mode = "req"
   xdebug.remote_port = 9000
   xdebug.trace_output_dir = "C:\xampp\tmp"

5. Restart Apache with the XAMPP control panel.
6. Bring up http://localhost/xampp/ and view phpinfo(). You should see Xdebug mentioned twice, once under the Zend engine and then as a PHP module.

   

   

7. You are done and ready to debug.

Debug with NetBeans

What is not to love about NetBeans? You can use it for Java, PHP, Ruby, Html and C/C++. It integrates well with many bug tracking and source control systems. It provides IntelliSense, database management, works great with Smarty templates and allows you to debug your code. If you haven’t tried NetBeans yet, I highly recommend it.

1. Start the IDE and load your PHP project. In the Project window, right click on your project and select Properties. Go to the Run Configuration node. You should be running as a Local Web Site. The Project URL should point to the root of your project directory and the Index File should be the file you want to launch into.
2. Right click again on your project. You can select Debug from here and get going right away, but if you first select Set as Main Project, you can just launch into the debugger with the Debug Main Project button on the toolbar or Ctrl+F5. (If Debug is not enabled, you probably need to enable the PHP plugin in NetBeans. Go to Tools | Plugins, click the Installed tab and make sure PHP is enabled.

   

3. When you start debugging, NetBeans will launch the browser to your start page. Notice how it appended the variable XDEBUG_SESSION_START=netbeans-xdebug to the end of the URL to start Apache debugging. If you see any Windows Firewall prompts at this point, accept them.
4. As the page loads, NetBeans will break on the first line of PHP code. The line will be highlighted and there will be a little green arrow in the margin to indicate the current line of execution.
   
   
5. Congratulations, you are debugging. From here, you can set breakpoints by right clicking on the margin of your code and selecting Breakpoint | Toggle Line Breakpoint. You can step through code (F8) using the debug toolbar (if you don’t see it, right click on the toolbars and enable it.) You can inspect or even change variables and view the call stack.

   

6. If you are new to debugging code, read more about what you can do in the article on the NetBeans site,

   Debugging PHP Source Code in the NetBeans IDE.

If I missed anything or you have any other suggestions, I would love to hear about it in the comments.

As the people who know me know, I have been a big proponent of log4net over the years. I tried very hard to stick with log4net despite years of inactivity of the project. Over the years, I found, reported and fixed issues, but the patches have never been applied. I have reached out to the remaining members of the team to get involved and help revive the project, but received few responses. I even applied patches and released an updated version myself.

As I started to use that updated version, I soon discovered that the current source has many bugs and actually fails many of its own test suites. I tried to get the test suites running and submitted more patches for those, but still the project remains dormant. Without the support of at least one member of the team, it is difficult to revive a project without forking it, which I don’t want to do.

I ended up talking with a member of the NHibernate team, I learned that they were also moving away from log4net and were looking at NLog, the new player in .NET logging. I read through the website, followed the forums and liked what I saw, so I decided to move over to NLog.

Switching over actually turned out to be fairly straight-forward once I managed a few regular expressions for search and replace. Roughly, I performed the following steps,

1. I did a search and replace using Notepad++ in all of my project files to switch the references over.
2. I then replaced all of my using statements.
3. Next came the log instantiation. log4net uses ILog where NLog uses Logger. In log4net you also tend to use GetLogger( typeof( MyClass ) ) where in NLog you just use GetCurrentClassLogger(). This required a bit of RegEx magic.
4. The hardest step was finding every instance of log.Warn( msg, exception) and converting them to log.WarnException( msg, Exception ). I did this nearly manually for each of the log levels, inspecting to see where I was passing in exceptions.
5. Then for each of the log levels, I converted instances of log.WarnFormat( "Substitute this {0}", val ) to log.Warn( "Substitute this {0}", val ). This was another easy file replacement.
6. Lastly, I removed my XmlConfigurator attributes and changed my log configurations. A quick recompile, a few minor fixes and I was up and running. Painless!

So far, I don’t regret my choice at all. I find the configuration of NLog to be much more intuitive and the Intellisense for the config file in Visual Studio sure helps. The documentation is still a bit sparse in places, but it is getting better. I do worry because it is currently a one man show, but it Jaroslaw Kowalski does seem fairly active and committed. Time will tell…

Real developers live on the command line. Way back in 1996, Microsoft released the Command Prompt Here Power Toy to ease their pain. Industrious developers who preferred the Visual Studio command prompt took it and adopted it to run a Visual Studio command prompt with all of the paths to Visual Studio and .NET tools in the path.

In the fine, time honored tradition, I have continued to update with each new Visual Studio release and have finally done so for Visual Studio 2010.

To install, download, unzip and right click and install the INF file, it will add a “VS 2010 Cmd Prompt Here” menu item when you right click on a folder in Explorer. Clicking on the menu item will launch a DOS prompt in that directory with all of the Visual Studio and .NET paths set correctly.

• Visual Studio 2010 Command Prompt Here (x86)
• Visual Studio 2010 Command Prompt Here (x64)

This assumes that you have installed Visual Studio to the default directory on the C drive. If that is not the case, edit the INF file and change line 38 to the correct path for your installation.