memory.Refresh()

When copying files in Windows, you are sometimes prompted about replacing an existing file.

The available options are Yes, Yes To All, No and Cancel. But what if you are copying a large number of files and want to choose the non-existent ‘No To All’ option? Well simply hold in the shift key while clicking the No option and it will apply that choice to all subsequent dialogs within the current operation.

Having worked on an application that required localising so that it can be translated into different languages, I know how hard it can be to test the different possibilities while still developing the code. This is especially so if the language is automatically detected from the current culture of the operating system.

Shawn Farkas came up with a simple solution for quickly testing code under different cultures that involves creating a bootstrap application to first set the required culture on the current thread and then launch the application to be tested.

One downside is that only the culture of the main thread is set, but for simple GUI testing this should be adequate in most cases.

Peter Laudati posted about migrating applications from .Net 1.1 to .Net 2.0. In doing so, he listed the different behaviours of .Net applications when running on computers with different versions of the .Net Framework installed:

A neat little project on CodePlex called Managed Stack Explorer enables you to monitor running .Net applications.

Using this tool, you can view all currently running managed applications, monitor all of their threads, and even collect stack traces at regular intervals. Very useful for getting information about applications whilst running outside of a debugger.

Using the latest version (1.35) of FxCop, it is possible to exclude generated warning messages in the source code instead of having to exclude them in the FxCop project file. This is accomplished using the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute class.

To exclude a message, simply mark up the method with the SuppressMessage attribute, declaring both the rule category and the specific rule to exclude:

[SuppressMessage("Microsoft.Design", "CA1062:ValidateArgumentsOfPublicMethods")]
public string ConvertToString(object obj)
{
    return obj.ToString();
}

The above example will exclude the “Validate Arguments Of Public Methods” rule from the Design category for the ConvertToString method (although in this contrived example it is probably a bad idea to do so as passing in a null will clearly cause problems).

One extra “tweak” that can be utilised in this scenario is the Justification property. Altering the above code to:

[SuppressMessage("Microsoft.Design", "CA1062:ValidateArgumentsOfPublicMethods", Justification="I do have a valid reason")]
public string ConvertToString(object obj)
{
    return obj.ToString();
}

will allow the person excluding a message to provide a reason for doing so in the code, alongside the exclusion. FxCop (v1.35) currently doesn’t display this in its output, but will do in the next release (source). It does however output the justification to a generated report if the options are set to output exclusions to the report.

Excluding FxCop messages in the source code has advantages over excluding them in the FxCop project as it demonstrates that the message has been specifically excluded for that particular case, but also will withstand class and namespace changes. It also makes switching from the standalone FxCop to Visual Studio’s code analysis an easier process.

In order to allow the SuppressMessage attribute to work, a CODE_ANALYSIS conditional compilation symbol must be defined for the project. Without this, FxCop will ignore the suppressed attribute and will still generate a warning.

More details can be found on the FxCop blog.