Strong name assembly and unit test project (InternalsVisibleTo attribute)

I tried to create a test project for a strong name assembly and I've encountered following error

Friend assembly reference 'TestProject1' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.

In order to fix it, the test project assembly has to be strong signed as well. The thing is that the test assembly needs to get access to the private members in the tested assembly, so it has to be decorated with the InternalsVisibleTo
attribute and should look like this:

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("TestProject1, PublicKey=PUBLIC_KEY")]

Where TestProject1 is the name of the test assembly which need access to private members, and PUBLIC_KEY is,as the name suggests, the public key value of tested assembly. But how to get the PUBLIC_KEY value?

> sn –Tp AssemblyFileName

And this information is displayed; we need the public key

Public key is

0024000004800000940000000602000000240000525341310004000001000100537d27966b492e
6e4402d93b86848897b04781de2bf54fbef46671e3163d817d43bed3a786eeaa0e5beda76cda89
ec6845deef5d2852165bac0a4df08a22bb8fccec93c4c24ed7803886178b6d4279488b7800eac0
bbfa6357e3c52d6bb19bb278056955fba5f4c85fa18164088ca18377f15d74d9b75e0fd58cd053
97cdc7de

Public key token is fd41b11fd220edb5

So the attribute at the end has this form:

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("TestProject1, PublicKey="+
"0024000004800000940000000602000000240000525341310004000001000100537d27966b492e"+
"6e4402d93b86848897b04781de2bf54fbef46671e3163d817d43bed3a786eeaa0e5beda76cda89"+
"ec6845deef5d2852165bac0a4df08a22bb8fccec93c4c24ed7803886178b6d4279488b7800eac0"+
"bbfa6357e3c52d6bb19bb278056955fba5f4c85fa18164088ca18377f15d74d9b75e0fd58cd053"+
"97cdc7de")]

After adding above attribute I could build without the unit test project any issues. Problem solved.

FxCop

FxCop is a great free tool for static code analysis, which checks managed code assemblies for compliance with .NET Framework Design Guidelines. FxCop is available both as GUI and a command line tool, so it can be easily used in build process. Certain messages can be excluded from future reports if you can intentionally avoid rules. New custom rules can be created using FxCop SDK.

If you recently updated Windows SDK to version 7, the FxCop installation file can be found in the Windows SDK v7.0/Tools/ directory.

To use GUI version of FxCop just start the application, add targets i.e. assembly or assemblies which you want to check and click Analyze button. After a while, depending on the assembly size, you will get the report.

Every message should be reviewed and one of the following actions should be taken

• If there is a code defect - fix the code
  
• If rule broken intentionally – exclude message
  
• If message generated is false– exclude message
  

After you fix the code for all other messages rebuild the assembly and analyze the code again.

FxCop is great tool for all .NET developers, especially for these who are not familiar with .NET Framework Design Guidelines. FxCop can help you write robust and easily maintainable .NET Framework code.

Extension methods – great new feature of C# 3.0

C# 3.0 has a new great feature which is extension methods. It basically allows you adding methods to already existing types without recompiling, creating derived types, and yes it can be used with sealed types!

Let's take a look how to create an extended method for string type which checks if string is empty or null.

Ok we have a method defined, let's see how to use it – it couldn't be simpler, just type method name after string object. As you can see Visual Studio IntelliSense shows it as an extension with arrow shape icon.

I think extension methods are great feature making developer life easier and what's important code just looks cleaner and simpler, doesn't it?

Single instance application for each user

Sometimes there is a need of creating a single instance application. It can be achieved in several ways and below you can find how it may be done using named Mutex. Named mutexes are visible throughout the operating system and can be used for synchronization purposes. Additional requirement is that there has to be single instance application for each user. To achieve this we are going to create a unique mutex name for every user. Please notice that if you use the same name for every user there it will be possible to run only one instance for the whole system. If another instance of the application is running, the main window will be displayed with SetForegroundWindow
method from user32.dll library.

Because an external library will be used add namespace declaration

using System.Runtime.InteropServices

Now the SetForegroundWindow metod declaration

[DllImport("user32.dll")]

static extern bool SetForegroundWindow(IntPtr hWindow);

And here is the code that does the job