memory.Refresh()

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.

Nikhil Kothari has made a nice little Web Development Helper for ASP.Net. It works as a plugin for Internet Explorer and is similar to the Internet Explorer Development Toolbar, but with more of an ASP.Net twist.

Some of its most useful features are:

-Rich error information for script errors, including call stack, script url and line number.

• a DOM inspector with filtering to enable easy viewing of particular items.
• a view state browser.
• trace information can be shown in a separate dialog instead of in the page itself.
• a full HTTP/HTTPS logger showing all traffic between the browser and the server.

The Web Development Helper requires .Net 2.0 to run and can only work on the same machine as the server, but this should not be a problem during development.

After installation, I had the same problem that lots of other people seem to have in that clicking the newly installed toolbar button did nothing. The suggested fix of installing the Internet Explorer Development Toolbar solved the problem though. Nikhil also suggested that a reboot (or killing explorer.exe) may also work because information about plugins is cached on startup.

Microsoft recently released Guidance Explorer, a tool that contains a browsable collection of best-practice patterns for developing .Net and ASP.Net applications.

Both the tool and its guidance library have regular updates, containing best-practices for performance and security related issues.

The tool also has the ability to add custom sets of guidance to allow corporate/team standards to be included.

Aaron Stebner posted a recent article about the available installation modes for the .Net Framework 2.0.

There are three supported modes:

Standard Mode

All UI screens are displayed, including warnings about missing prerequisites, existing beta versions, errors and reboots.

The setup includes a multi-lingual UI that chooses the correct language from the user’s operating system UI language settings, so a user should always see the install in their preferred language.

Unattended Mode

All UI screens are suppressed, except for a progress dialog during installation.

To install in unattended mode, use the following command line:

dotnetfx.exe /q:a /c:"install.exe /qb"

Changing /qb to /qb! will hide the cancel button on the progress dialog, stopping the user from aborting the install.

Silent Mode

All UI screens are suppressed. This is useful for a custom installer to install the .Net Framework.

To install in silent mode, use the following command line:

dotnetfx.exe /q:a /c:"install.exe /q"

If using silent mode, any errors, previous beta versions or reboots must be handled by the hosting installer since the .Net Framework installer cannot display any dialogs to prompt the user. Aaron also provides details of possible return codes from the installer, how to detect previous beta versions of the framework and how to manage reboots.