GACing Assemblies in Windows 7 / .NET 4.0 / Visual Studio 2010

Before an assembly can be GACed, you need a strong name key. Open up the Visual Studio Command Prompt (2010) in administrator mode and type in:

sn -k c:\temp\MyKey.snk

Run Visual Sutdio 2010 in administrator mode and view the project’s properties. Under the Signing tab, check the Sign the assembly checkbox and choose your newly created key. Under the Build Events tab, add this under Post-build event command line:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\gacutil.exe" /i
"$(TargetPath)"

Now when you build your project, the assembly will be automatically GACed. Note that you need to run Visual Studio in administrator mode so that the post-build command will run. You can view your GACed assemblies at C:\Windows\Microsoft.NET\assembly\GAC_MSIL.

Testing BizTalk Maps that use Flat File Schemas

I was testing a BizTalk map that used a flat file schema with a flat file instance input file and ran into this error:

Error 3 Output validation error: Data at the root level is invalid. Line 1, position 1.

Turns out that the map is treating the input file as an XML file. In the map’s property, ensure the TestMap Input is set to Native.

BizTalk Schema Build Error

I just ran into a rather strange problem when I tried to rebuild my BizTalk solution. A bunch of these errors popped up:

Error 3 Source file 'C:\Source\MyProject\InputFile_XML.xsd.cs' could not be opened ('Unspecified error ')

Turns out the rebuild wipes out *.xsd.cs files. These files are generated by Visual Studio at build time for each schema file but when they are removed, subsequent rebuilds will fail to regenerate these .xsd.cs files and the compilation fails. This seems to be related to TFS because the solution is to check out all the schema files in the project and build again. The .xsd.cs files will be generated again.

Event Logging

Here's a quick method to log exceptions to the event log:

private void LogException(Exception exception){
    EventLogPermission permissions = new EventLogPermission(EventLogPermissionAccess.Administer, ".");

    using (EventLog log = new EventLog("Application")){
        permissions.PermitOnly();

        if (!EventLog.SourceExists("MySourceName")){
            EventLog.CreateEventSource("MySourceName", "Application");
        }

        log.Source = "MySourceName";
        log.WriteEntry(exception.ToString(), EventLogEntryType.Error);
    }
}

A couple of things to note:

• The using statement makes sure the EventLog object is disposed without fail
• The EventLogPermission permits this callee to create an event source if required and to write to the event log

Using Static Alias

C# developers will be familiar with this syntax:

this.DoSomething();

whereby DoSomething() is some other method and qualifying it with the this keyword is good practice. But how about static methods? You'll have to qualify it with the class name:

MyClass.DoSomeStaticThing();

I've never felt right qualifying static methods and properties within the class itself (it is of course required when calling from outside the class) and it gets a bit silly for really long class names, eg:

ServiceModelConfigurationSectionGroupCollection.DoSomeStaticThing();

That might be the worst case scenario class name, but when it is used more than once, the code starts looking littered:

MyVeryLongClassName.TryEnterReadLock(MyVeryLongClassName.Timeout, MyVeryLongClassName.IsReadOperation);

One option is to not qualify at all:

DoSomeStaticThing();

but this just doesn't promote good code clarity, especially when there are numerous static methods and/or properties that seem to float around with no qualifiers at all.

What I've started doing is using an alias called "This" which is just a shortcut to my class:

namespace MyNamespace{
using This = MyNamespace.MyVeryLongClassName;
public class MyVeryLongClassName{ ...

Now I can succinctly qualify static methods and properties:

This.DoSomeStaticThing();

There is an analogous distinction (albeit subtle) between this (instance) and This (static) which is consistent with .NET naming conventions between class types (Pascal case) and instances (Camel case).

Using ReaderWriterLockSlim

I was revisiting some code I needed to rewrite and realised I really needed to implement a locking mechanism. I remembered that of all the techniques available in the .NET framework, the System.Threading.ReaderWriterLock was going to suit the most because I needed to allow multiple concurrent reads but only one write at any time. When browsing through the class reference, I noticed a new class called ReaderWriterLockSlim and decided to have a read about it.
According to MSDN, the ReaderWriterLockSlim is a much more performant version of ReaderWriterLock and recommends developers to ditch the older class in favour of the newer one.
One tip I have is to use the TryEnterReadLock/TryEnterWriteLock methods instead of the EnterReadLock/EnterWriteLock methods. The reason is that the latter methods may end up blocking indefinitely while the former methods give you a timeout value:

lock = new ReaderWriterLockSlim();
...
if (lock.TryEnterWriteLock(1000)){
    try{
        //do some write operation that requires locking
    }
    catch(Exception e){
        //handle the exception
    }
    finally{
        lock.ExitWriteLock();
    }
}
else{
    //optionally throw a System.TimeoutException          
}

You need to be diligent in ensuring all write operations that require locking are actually enclosed by write locks or you defeat the purpose of having a locking mechanism. The lock variable will also need to be a singleton so that locks are honoured across all threads.

Guidance Explorer

I stumbled upon a very useful tool - Guidance Explorer . If you're into design patterns and best practices, take a look at this (free) tool, its well worth it.