Code Samples

Although most of the examples used TeamCity, here are the code samples, available through GitHub.
https://github.com/ruthlesshelp/Presentations

Slides

Here are the slides, available through SlideShare.

You can be assured that I’ve been down this road. In fact, a few readers of my book, Pro .NET Best Practices, expressed some disappointment that the book is not a collection of specific .NET best practices. And this is exactly why I decided to address this subject in today’s post.

For those that want to dig right in, follow this link to part 1, MSDN: .NET Framework Best Practices.

If you want some background, let me start with the question: Who wants to follow best practices, anyway?

Adoption

The adoption of new and different practices is a central theme of Pro .NET Best Practices. I work with enough individuals, teams, and organizations to understand the issues involved with adopting best practices. Consider the four levels at which best practices are embraced:

• Individual: You or any individual adopts better practices to increase personal and professional productivity, quality, thoroughness, and overall effectiveness.
• Group: The team adopts better practices to be more industrious together, avoid problems, achieve desired results, improve interpersonal relationships, and work more effectively with other teams.
• Organization: Your company, agency, or firm adopts better practices to bring more positive outcomes to the organization, attract and retain employees, satisfy end-user expectations, and make stakeholders happy.
• Profession: Better practices are widely adopted and become generally-accepted standards, patterns, and principles that bring alignment to software development and benefit to all that follow them.

In an ideal world, best practices are quickly adopted at all four levels. However, in the real world, they can be slowly adopted by the group, resisted by the organization, embraced by one individual, not by another, or ignored altogether by everyone but you. It can be a mixed bag.

The Reader

There are two key readers of this blog post that I want to identify with and help:

1. Developers – As a developer, you have personal practices that make you an effective software developer. The compendium should list new and different practices that help make you a more effective developer.
2. Team Leaders – As a team leader, you see the team develop software through their current practices. The compendium should list practices that help the team perform better and achieve better outcomes.

These readers are adopting at either the individual or group level.

If you are a reader who wants to bring best practices to the organization or the software development profession then I assert that you are probably not interested in the content of this compendium. Yes, you might refer a developer or team leader to the compendium, but I doubt you will find it directly relevant.

So, given this introduction, let’s look at how a collection (I like the term compendium) of specific .NET best practices might be organized.

Tags for the Compendium

Since this is a blog, tags can help others find and navigate the content. Here is a quick list of tags that come to mind:

• Coding Best Practices. For example, C#, VB.NET, T-SQL
• Toolset Best Practices. For example, Visual Studio, ReSharper, Typemock
• Platform Best Practices. For example, ASP.NET, SQL Server, SharePoint
• Architecture Best Practices. For example, Client-Server , n-Tier, CQRS
• Windows 8 Best Practices
• Engineering Fundamentals Best Practices
• Cloud Best Practices
• Phone Best Practices
• ALM (Application Lifecycle Management) Best Practices

Clearly, there are a lot of ways to slice and dice the topic of best practices; however, I will try to bring things back to the topic of the Microsoft .NET Framework.

You can find the entire Best Practices category here: http://ruthlesslyhelpful.net/category/development/best-practices/

The Power of Free

I mostly wrote Pro .NET Best Practices based on my professional experience trying to get teams and organizations to adopt .NET Framework best practices. Over the years, I have read many books, I experimented, I tried and persevered with one approach, and I tried totally new approaches. Many times I learned from others. Many times I learned by my mistakes.

Over the years and as I researched my book, I found many free, on-line sources of .NET best practices. Many are professionally written and easy to follow. In my book I was reluctant to paraphrase or repeat material, but I should have done a better job of showing people how to access the material. (The one thing I really kick myself over is that I did not use Bitly.)

So, let me start the Compendium of .NET Best Practices with some great material already available on the Internet.

Part 1: MSDN: .NET Framework Best Practices

This is a great MSDN article to read and link to bookmark if you’re interested in.NET best practices.

Best Practices for Strings

Just take a look at all the information within the MSDN topic of Best Practices for Using Strings in the .NET Framework. I am not going to be able to duplicate all of that. If you are developing an application that has to deal with culture, globalization, and localization issues then you need to know much of this material.

Before I go any further, let me introduce you to Jon Skeet. He wrote an awesome book, C# In Depth. I think you might enjoy reading his online article on .NET Strings: http://csharpindepth.com/Articles/General/strings.aspx

Okay, let’s get back to the MSDN article. Below I have highlighted a few of the Strings best practices that I’d like to discuss.

1. Use the String.ToUpperInvariant method instead of the String.ToLowerInvariant method when you normalize strings for comparison.

In the .NET Framework, ToUpperInvariant is the standard way to normalize case. In fact, the Visual Studio Code Analysis has rule CA1308 in the Globalization category that can monitor this.

This is a really easy practice to follow once you know it.

Here is the key point I picked up from rule CA1308:

It is safe to suppress [this] warning message [CA1308] when you are not making security decision based on the result (for example, when you are displaying it in the UI).

In other words, take care to uppercase strings when the code is making a security decision based on normalized string comparison.

2. Use an overload of the String.Equals method to test whether two strings are equal.

Some of these overloads require a parameter that specifies the culture, case, and sort rules that are to be used in the comparison method. This just makes the string comparison you are using explicit.

3. Do not use an overload of the String.Compare or CompareTo method and test for a return value of zero to determine whether two strings are equal.

In the MSDN documentation for comparing Strings the guidance is quite clear:

The Compare method is primarily intended for use when ordering or sorting strings.

All-In-One Code Framework

If you have not had a chance to take a look at the All-In-One Code Framework then please take a few minutes to look it over.

The Microsoft All-In-One Code Framework is a free, centralized code sample library driven by developers’ needs.

It is Microsoft Public License (Ms-PL), which is the least restrictive of the Microsoft open source licenses.

What’s relevant to this article is the All-In-One Code Framework Coding Standards document. You can find the download link at the top of this page: http://1code.codeplex.com/documentation

In that document, they list a very relevant and useful list of String best practices.

• Do not use the ‘+’ operator (or ‘&’ in VB.NET) to concatenate many strings. Instead, you should use StringBuilder for concatenation. However, do use the ‘+’ operator (or ‘&’ in VB.NET) to concatenate small numbers of strings.
• Do use overloads that explicitly specify the string comparison rules for string operations. Typically, this involves calling a method overload that has a parameter of type StringComparison.
• Do use StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase for comparisons as your safe default for culture-agnostic string matching, and for better performance.
• Do use string operations that are based on StringComparison.CurrentCulture when you display output to the user.
• Do use the non-linguistic StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase values instead of string operations based on CultureInfo.InvariantCulture when the comparison is linguistically irrelevant (symbolic, for example). Do not use string operations based on StringComparison.InvariantCulture in most cases. One of the few exceptions is when you are persisting linguistically meaningful but culturally agnostic data.
• Do use an overload of the String.Equals method to test whether two strings are equal.
• Do not use an overload of the String.Compare or CompareTo method and test for a return value of zero to determine whether two strings are equal. They are used to sort strings, not to check for equality.
• Do use the String.ToUpperInvariant method instead of the String.ToLowerInvariant method when you normalize strings for comparison.

This post is part of my Compendium .NET Best-Practices series.

1. The first stop was in Albany on Monday, Nov. 12th to present at the Tech Valley Users Group (TVUG) meeting.
2. On Tuesday night I was in Syracuse presenting at the Central New York .NET Developer Group meeting.
3. On Wednesday night I was in Rochester presenting at the Visual Developers of Upstate New York meeting.
4. Finally, on Thursday night I was in Buffalo presenting at the Microsoft Developers in Western New York meeting.

Many Belated Thank Yous

I realize it is belated, but I’d like to extend a very big and heartfelt thank you to the organizers of these users groups for putting together a great series of meetings.

Thank you to Stephanie Carino from Apress for connecting me with the organizers. I really appreciate all the help with all the public relations, the swag, the promotion codes, the raffle copies of my book, and for the tweets and re-tweets.

Slides and Code Samples

My presentations are available on SlideShare under my RuthlessHelp account, but if you are looking for something specific then here are the four presentations:

1. An Overview of .NET Best Practices
2. Overcoming the Obstacles, Pitfalls, and Dangers of Unit Testing
3. Advanced Code Analysis with .NET
4. An Overview of .NET Best Practices

All the code samples can be found on GitHub under my RuthlessHelp account: https://github.com/ruthlesshelp/Presentations

Please Rate Me

If you attended one of these presentations, please rate me at SpeakerRate:

1. Rate: An Overview of .NET Best Practices (Albany, 12-Nov)
2. Rate: Overcoming the Obstacles, Pitfalls, and Dangers of Unit Testing
3. Rate: Advanced Code Analysis with .NET
4. Rate: An Overview of .NET Best Practices (Buffalo, 15-Nov)

You can also rate me at INETA: http://ineta.org/Speakers/SearchCommunitySpeakers.aspx?SpeakerId=b7b92f6b-ac28-413f-9baf-9764ff95be79

Yesterday I traveled up to Long Island, New York to present at the LI .NET Users Group. A very big thank you to the LI.NET organizers for putting together a great September meeting. I especially enjoyed the New York pizza. The group last night was great. Very good turnout. The audience had many good questions and comments. Also, there were a lot of follow up discussions after the meeting.

Thank you to Stephanie Carino from Apress for connecting me with the organizers of LI.NET. I really appreciate all the help with all the public relations, the swag, the promotion codes, the raffle copies of my book, and for the live tweets and pictures.

I especially want to thank Mike Shaw for coordinating with me and recording the presentation. He was very helpful and kept me informed every step of the way. I will link to the presentation once it is posted.

Code Samples

Here are the code samples, available through GitHub.
https://github.com/ruthlesshelp/Presentations

Slides

Here are the slides, available through SlideShare.

Code Samples

Here are the code samples, available through GitHub.
https://github.com/ruthlesshelp/Presentations

Slides

Here are the slides, available through SlideShare.

Microsoft explains their vision of the Security Development Lifecycle and provides SDL Practice #10: Perform Static Analysis. On that page, under the heading of Tools specific to this practice, CAT.NET is recommended and download links are provided. However, the links are to CAT.NET version 1.0. What happened to CAT.NET 2.0?

On the MSDN blog a post from the SDL folks implies that security-oriented code analysis is going to be part of Visual Studio 11. I believe there is a lot of value in having a separate tool, like FxCop, to perform static code analysis across VS projects and solutions and on 3rd-party assemblies.

I would love to hear more about the tools specific to SDL Practice #10: Perform Static Analysis, and I am hopeful that this will be described in detail in one or more sessions at some future SDC.

I was amazed. Philly.NET Code Camp is like a mini TechEd. I am impressed at how professionally everything was done. Registration, content, food, facilities, etc. This group knows how to put on a code camp. It is a testament to the capability and dedication of Philly.NET; it’s leadership and members. Keep up the good work. Thank you for an awesome day. I cannot wait for the next one.

Slides

Here are the slides, available through SlideShare.

Sample Code

The sample code from my session (Tools track, 1:40 PM) is available here:

• GitHub: https://github.com/ruthlesshelp/Presentations
• Zipped up in one download file: Philly.NET Code Camp 2012.1 slides and code

Also, please review the requirements for using the code samples in the section below the slides.

Requirements For The Code Samples

To use the sample code, you need to create the Lender.Slos database. The following are the expectations and requirements needed to create the database.

The sample code assumes you have Microsoft SQL Server Express 2008 R2 installed on your development machine. The server name used throughout is (local)\SQLExpress. Although the sample code will probably work on other/earlier versions of SQL Server, that has not been verified. Also, if you use another server instance then you will need to change the server name in all the connection strings.

Under the 0_Database folder there are database scripts, which are used to create the database schema. For the sake of simplicity there are a few command files that use MSBuild to run the database scripts, automate the build, and automate running the tests. These batch files assume you defined the following environment variables:

• MSBuildRoot is the path to MSBuild.exe — For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319
• SqlToolsRoot is the path to sqlcmd.exe — For example, C:\Program Files\Microsoft SQL Server\100\Tools\Binn

The DbCreate.SqlExpress.Lender.Slos.bat command file creates the database on the (local)\SQLExpress server.

With the database created and the environment variables set, run the Lender.Slos.CreateScripts.bat command file to execute all the SQL create scripts in the correct order. If you prefer to run the scripts manually then you will find them in the $_Database\Scripts\Create folder. The script_run_order.txt file lists the proper order to run the scripts. If all the scripts run properly there will be three tables (Individual, Student and Application) and twelve stored procedures (a set of four CRUD stored procedures for each of the tables) in the database.

The slides are available on SlideShare.

Requirements For The Code Samples

To use the sample code, you need to create the Lender.Slos database. The following are the expectations and requirements needed to create the database.

The sample code assumes you have Microsoft SQL Server Express 2008 R2 installed on your development machine. The server name used throughout is (local)\SQLExpress. Although the sample code will probably work on other/earlier versions of SQL Server, that has not been verified. Also, if you use another server instance then you will need to change the server name in all the connection strings.

The sample code for this presentation is within the NDbUnit folder.

Under the 0_Database folder there are database scripts, which are used to create the database schema. For the sake of simplicity there are a few command files that use MSBuild to run the database scripts, automate the build, and automate running the tests. These batch files assume you defined the following environment variables:

• MSBuildRoot is the path to MSBuild.exe — For example, C:\Windows\Microsoft.NET\Framework64\v4.0.30319
• SqlToolsRoot is the path to sqlcmd.exe — For example, C:\Program Files\Microsoft SQL Server\100\Tools\Binn

The DbCreate.SqlExpress.Lender.Slos.bat command file creates the database on the (local)\SQLExpress server.

With the database created and the environment variables set, run the Lender.Slos.CreateScripts.bat command file to execute all the SQL create scripts in the correct order. If you prefer to run the scripts manually then you will find them in the $_Database\Scripts\Create folder. The script_run_order.txt file lists the proper order to run the scripts. If all the scripts run properly there will be three tables (Individual, Student and Application) and twelve stored procedures (a set of four CRUD stored procedures for each of the tables) in the database.

Apress is currently running a promotion for Pro .NET Best Practices. This is for a limited time.

Until May 31, 2012, you can get 40% off the Pro .NET Best Practices eBook from the Apress website when you apply the promo code CMAP12.

Follow these steps

1. Go to the Pro .NET Best Practices page at apress.com: http://www.apress.com/9781430240235
2. Select the “Buy eBook” button
3. Enter the promo code: CMAP12
4. Press the “Apply Discount” button
5. Proceed to checkout

Available eBook formats: EPUB, MOBI, PDF

This discount is only available through apress.com, when you purchase the eBook and apply the promo code CMAP12.

For more information, please visit apress.com