In these last couple of days I’ve been busy trying to refactor some apps which are starting to show their age. It hasn’t been fun because unfortunately I didn’t have a high enough code coverage to perform the refactoring safely (oh well, life sucks sometime!). Even though it’s not the most pleasant thing to do in the world (hell, I can remember quite a lot of way more interesting things to do ), doing this kind of work has been…how shall I put it…interesting.

Today I got stuck for at least an hour trying to understand why a RhinoMock stub wasn’t being called as it should. In order to illustrate the problem, let me present you with the code being tested (this is only for illustration purposes):

public class StudentService {
    private readonly ISession _session;
    public StudentService(ISession session) {
        _session = session;
    }
    public Student GetStudent(Int64 studentId) {
        using(var tran = _session.BeginTransaction()) {
                return _session.Get<Student>(studentId);
        }
    }
}

In the real world, this service would implement an existing IStudentService contract and I’d be using code contracts to ensure that _session would always be a valid reference. In my real world example, I had lots of other things going on too, but the previous snippet is more than enough for me to make my point. Now, being a conscious developer, I knew I had to update the existing tests. I was already using RhinoMocks, so I’ve added structuremap’s RhinoAutoMocker to simplify the testing code.

After refactoring the code, I’ve ended up with something that resembled the following snippet:

[TestFixture]
public class StudentServiceReturnsExistingStudent {
    private readonly RhinoAutoMocker<StudentService> _autoMocker;
    private readonly  ISession _session;
    private readonly ITransaction _tran;
    private readonly Student _std;
    private const Int32 _id = 1;
    public StudentServiceReturnsExistingStudent() {
        _autoMocker = new RhinoAutoMocker<StudentService>();
        _session = _autoMocker.Get<ISession>();
        _tran = _autoMocker.Get<ITransaction>();
        _std = new Student {Id = 1};
    }

    [Test]
    public void Test() {
        Arrange();
        var std = _autoMocker.ClassUnderTest.GetStudent(_id);
        Assert.AreEqual(_std, std);
        _session.VerifyAllExpectations();
    }

    private void Arrange() {
        _session.Expect(s => s.BeginTransaction())
            .Return(_tran);
        _session.Expect(s => s.Get<Student>(_id))
            .Return(_std);
    }
}

Ah, now let’s run the test. What? not working?

Not possible…what the hell is going on here? After looking several times and checking the types were correct (in my case, I had Dto.Student and Student, so I double checked if the types being expected were of the correct type), I’ve decided to ignore the arguments being passed into Get:

_session.Expect(s => s.Get<Student>(_id))
            .IgnoreArguments()
            .Return(_std);

This small change was enough for making the test pass. In practice, this meant that there was something wrong with the setup of arguments in the Expect call. And sure, that was the problem! If you look carefully at GetStudent, you’ll notice that it expects an Int64. However, my test code was configured so that Get would receive an integer (Int32). Interestingly, calling GetStudent with an integer works without a problem (since going from int to long is considered to be a safe conversion). However, that does not happen when you’re building “RhinoMock expectations”. Moral of the story: if you think you’ve set up the expectations correctly and your test is not producing the expected results, double check the types of the arguments you’re setting up in the expectations.

And that’s it for now. Stay tuned for more.

If you’re a long time user of ASP.NET, you’re probably aware that the out of the box providers have some limitations. For instance, you couldn’t really use them with an SQL Compact database because they depended on stored procedure support for performing their actions. Besides that, clean up and maintenance in general depended on agents which run scheduled clean up tasks.

When Microsoft started working with Web Pages and the WebMatrix, they decided to have another go at this problem. Their first solution was known as universal providers and it solved the problem I’ve mentioned in the previous paragraph (ie, with the universal providers, you can  store your data in a SQL Compact or SQL Azure db) . The easiest way to add the universal providers to your project is to run the following instruction from the Nuget console:

Install-package Microsoft.AspNet.Proviers

Notice that I’ve used plural (provider*s*) because the package ends up installing session, membership, roles and profiles providers. You should also keep in mind that the previous instruction will also update the web.config file so that the app uses all these new providers ( if you’re just interested in one or two, don’t forget to clean up your web.config file).

But the team wasn’t finished yet. They’ve decided to introduce another provider, known as the SimpleMembership, which is way more flexible in its requisites regarding data storage (even though it’s called SimpleMembership provider, the truth is that the package introduces two providers: one for roles and another for membership – this is the most important one). Instead of forcing the use of a specific database table, this provider requires only that you specify the name of the table which is holding your users accounts and the names of the ID and username fields used in that table.

Now, there’s already some resources out there which show you how to get started with this provider (for instance, this one does a good job of explaining what you can expect from it) and that’s why I won’t be wasting your time explaining how it works.

If you’re using Web Pages, you’ll end up getting this provider for free. However, if you’re using Web Forms and you like what you see in that post, then you’re probably wondering about what’s needed to add it to your app. Once again, Nuget is your friend here  

All you need to do to use this provider from your app is to run the following Nuget instruction:

install-package Microsoft.AspNet.WebPages.WebData

Now that you’ve added the required assemblies, I’ll leave it to you to explore the new features introduced by this new provider.

And that’s it for now. Stay tuned for more.

One of the things that I needed to do in the past was to write a cross-platform project which had to be consumed from Silverlight and an ASP.NET MVC project. At the time, I was kind of lucky because you could reuse a Silverlight assembly in a .NET project provided that you only used some types (Christian Nagel has a nice post about this feature here).

This feature was nice, but it wasn’t perfect. VS 2012 improves it by introducing the new Portable Class Library project. This new project lets you write and build portable assemblies for Windows 7, Windows 8, Silverlight, Windows Phone and the XBox. Sure, there are still several limitations, but now you can reuse your assembly across a wider range of other projects types. Notice, though, that the assemblies produced by this project type can only target .NET 4 or .NET 4.5. If you’re interesting in getting more info about this new project type, then this will help you understand its restrictions.

And that’s it for now. Stay tuned for more.

Before going on, I need to confess one thing: I’m really frustrated! Why? simple: I was watching the damn build keynote and it stopped…right in the middle of the whole JS app for Windows 8…oh well, it’s probably a sign that it’s time to go back to my blog…

As you probably recall, in the previous post I’ve started presenting some guidelines for working with exceptions in C#. Today, I’ll keep doing that and I’ll introduce another guideline: it’s ok to catch an exception and re-throw it as “something” else if:

• you handle only the exceptions you know how to
• don’t forget to pass the old exception as the inner one in the new one.

Since we’re opening a database connection, we know we might end up with an SqlException whenever we open that database connection. Getting the information from a database is really an implementation detail and that’s probably someone who is consuming your code doesn’t need to know about.

Another interesting to notice is that I’ve passed the caught exception to the InexistingPersonException constructor. By doing this, I guarantee that the original exception isn’t lost and that may help me find the problem when someone calls back and complains about that exception.

Oh look, it’s saying that the day 1 keynote video will be available shortly! It’s probably best to wrap this post up right now

And that’s it for now. Stay tuned for more.

As promised, today I’ll start presenting some interesting guidelines you should follow when working with exceptions. If there’s one guideline you should *always* follow, this is it: don’t catch every exception there is…especially if you’re developing libraries which will be used by other developers.

It’s important to realize that whenever you catch an exception, you’re saying that you’re expecting it and you know how to deal with it. In my experience, it’s far too common to see code like this (btw, I’ve used it before in previous posts, which was probably a bad idea…anyways, don’t do it):

Whenever you write code like this, you’re saying that you know how to handle all the exceptions that might be thrown. Really? Are you sure about that? What do you expect to do whenever you get an OutOfMemoryException? Do you really know to handle it? And what about all the other exceptions which might be thrown? Things are even worse if you do something like this in a library which is going to be used by other developers. For starters, it’s difficult to know how the application which is consuming your library will respond to exceptions. Probably it can do more than you…probably, not…And that’s why it’s vital to let those exceptions your type can’t handle flow through the call stack. The worse thing that will happen is getting an unhandled exception which ends up killing the process. And this is not such a bad thing because 1.) most unhandled exceptions will probably be caught during development and 2.) sometimes ending the process is the best way to ensure that no data is corrupted.

Notice that the problem isn’t really catching any exception. It’s swallowing it! So, if you need to log all exceptions and you’re writing library code, then this is the correct way to do it:

And now you’ll get your logging and you’re letting the exception flow through the call stack without changing its origin. And everybody is happy and you can go home an enjoy dinner in family…

And that’s it for now. Stay tuned for more.

When someone with lots of experience in Win32 programming starts using .NET, they tend to be shocked with the regular use of exceptions. In fact, they tend to ask why do we define APIs which don’t return error codes and rely heavily on exceptions. Well, it’s a matter of “culture”. Notice that .NET and OO allows a developer to be very productive. For instance, just look at all those fluent APIs we have. For instance, here’s a snippet from Fluent NH:

When I write code like this, I’m assuming that all of those methods calls will be executed without errors. Code would need to be much more tedious if we had to check for errors in all those calls. I mean, we have lots of things going on here and we didn’t even went into the IL… It’s really hard to write defensive code for all of this and, in this case, I’m ok with getting an exception in the mappings that ends up terminating my app. Even though this might be a chock for people coming from Win32, the truth is that the productivity gains from doing this kind of things makes it “all right” to rely heavily in exceptions when you’re writing ,NET code.

So, we simply rely in catching known exceptions and understanding that things will go well most of the times. Notice, however, that we do get several interesting assurances from the CLR to mitigate state corruption:

• a thread can’t be aborted when executing code is inside a catch or finally block;
• we can rely on CERs (constrained execution regions) to reduce potential exceptions (more about this in a future post);

Even though these assurances do help, there will be times when you end up with corrupted data. In these cases, you probably should terminate your app’s process immediately. I’d say that the bottom line is that managed code has a different philosophy  and it probably is a good option if you’re writing  applications which can be terminated when data corruption occurs.

And that’s it for now. On the next post I’ll present some of the guidelines I try to follow when working with exceptions. Stay tuned for more.

In one of the previous posts, I’ve mentioned that the CLR allows an instance of any type to be thrown for an exception (notice that this isn’t allowed by the CLS). In practice, this means that you should be able to throw ints or strings from CLR languages which allow you to write non-CLS compliant code. Since most people will use C# or VB.NET, they think that they’re only allowed to handle Exception derived exceptions and so they think that using the Exception type in a catch block is enough for getting all the exceptions. In other words, people think they would catch all the exceptions by writing this code:

And life was good until you needed to, say, consume some managed C++ code (which, for instance, interacted with some legacy code) that would end up throwing an exception which wasn’t derived from the base Exception type. There was a solution for this problem:

By using the catch all block, you are, in fact, catching all exceptions. In other words, the first catch block catches all the CLS compatible exceptions (ie, all Exception derived exceptions) and the second ends up catching all non-CLS compatible exceptions.

Now, the *GOOD NEWS*: you only need to worry about this if you’re running .NET 1.1. And that’s because MS recognized that it needed to “solve” this problem and introduced the RuntimeWrappedException class. Whenever you add the RuntimeCompatibilityAttribute to an assembly (which is done automatically by the C# compiler), all non-CLS compliant exceptions are wrapped by a RuntimeWrappedException object. This means that from 2.0 onwards, you can really catch all exceptions by using the 1st code snippet I’ve shown. Btw, if you want you can get the real thrown exception by accessing the WrappedException property (notice that it references an Object and not an exception).

And that’s it for now. Stay tuned for more.

As I’ve said before, you’re supposed to throw an exception when a method cannot complete its task in the way it’s supposed to do it. Before throwing an exception, you should consider two things:

• which type of exception should you throw?
• What’s the message that  you’re going to pass into the Exception constructor?

The first step is really important: you should choose an exception type which is meaningful. This is an important decision because you need to consider what will happen when you throw that exception. You should start by looking at the predefined exceptions introduced by .NET. If none of those brings the semantics you’re looking for, then you should probably create a new one. In this case, I’d say that you’re better off by reusing Exception as the base type of the new exception (in fact, if you need to create several exceptions for a specific application, then it’s best to make the hierarchy shallow and wide, ie, with as few base classes as possible).

After choosing the exception type, you should also give some thought about the message you’re passing in when you instantiate that exception. As I’ve said before, this should be a technical message, so don’t be afraid to get into details. Whenever an exception isn’t caught, it will end up as an unhandled exception. In practice, this means that it will probably end up in the event log and, when that happens, this message should be a good starting point for us to know how to handle the current problem. Since this message shouldn’t really be shown to the user, then you probably don’t need to worry about localizing it.

Having said this, I must confess that there is a place where I don’t follow these guidelines: whenever I need to develop WCF services, I tend to catch eventual expected exceptions and transform them into new exceptions, with user friendly messages tackled into its, which are propagated into the client (WPF or Silverlight).

If you decide to create a new Exception derived class, then you can expect to have some tedious work ahead of you. For instance, suppose you’ve got a method which changes the value of a property. Furthermore, suppose you want to improve the semantics of your code by generating an IncorrectNameException whenever the string that is passed in is not limited to 30 characters…In that case, the first thing we need to do is build a new Exception derived class:

The first interesting point is that we should always make the new exception serializable. Besides applying the Serializable attribute, I’ve also implemented the interface and overrode the GetObjectData inherited from the base Exception class (the serialization part is simple and it will only save/restore the value of the _incorrectName field). In order to personalize the message, I’ve also opted for overriding the Message property so that it appends the name of the field to the message that is passed in the constructor. Btw, and since I’ve mentioned the constructor, notice how I’m taking advantage of optional parameters (instead of writing three constructors, I’m writing just one! – the second one is only there for deserialization purposes). I’ve also overridden the Equals method (and the GetHashCode) to ensure that the comparison between two instances of this type is perfomed correctly.

The code isn’t really complicated, but, as I’ve said before, is rather tedious. If you want, you can also use generics to create a new generic type which you can reuse for all your exceptions types (in this case, it’s clearly a good idea to transform the String parameter into a generic type parameter!).

After defining the class, we’re ready to throw our custom exceptions:

I couldn’t end this post without mentioning that I’d wouldn’t really create this new exception type in a “real world” application (at least, not in my domain code). The reason is simple: .NET already offers an ArgumentException class which is more than adequate for this kind of error. In fact, I would leave these verifications for the code contract framework, which does a very good job in verifying pre and post conditions and invariants!

And that’s it for now. Stay tuned for more.

In the previous post, we’ve started looking at how to use exception in .NET. Even though the CLR allows an instance of any type to be thrown for an exception (more about this in a future post), the truth is that all CLS compliant languages can only catch and throw Exception derived exceptions. That’s why in C# you can only throw and catch exceptions whose type is derived from Exception. The class exposes several interesting properties which you can use to get more information about an exception. The StackTrace property is (probably) one of the more important ones and you can use it from within a catch block to get a string which indicate the methods that were called that led up to the current exception. The following snippet tries to illustrate the use of this property:

And the next image shows the result at runtime:

As you can see, we end up getting the names of all the methods until the one where the exception was thrown. Typically, you won’t be using this info at runtime (ie, don’t show it to the final user!), but you should probably log it so that you can get more info about the exception when the phone starts ringing and someone starts complaining about a crash

If you’ve checked the docs for the Exception class, you’ve probably noticed the Message property. This property (which, btw, is read-only) contains info about the error and it should also explain how to fix the problem. Notice that this isn’t an error friendly message; in fact, it’s a technical message and this means that it shouldn’t be shown to the final user. There’s also a Data dictionary, where you can find a collection of key-value pairs with extra info about the exception (if you’re the middle-man, you can add-more information to this entry and re-throw it). The TargetSite and Source properties reference, respectively,  the method that threw the exception (MethodBase instance) and the name of the assembly that generated the exception. Finally, there’s also an InnerException property which references the previous exception when the current one was raised when handling the first one (we’ll return to this topic in future posts).

If you look at the MSDN docs on exceptions, you’ll notice that there’s a long long hierarchy. Many of the predefined exceptions inherit from ApplicationException or SystemException. Originally, MS recommended that all new exceptions should expand one of these types. The idea was not bad since new applications exceptions should inherit from ApplicationException and system exceptions should expand the SystemException class. If that guideline had been followed, then it would be possible to have catch blocks which would handle all system exceptions or all applications exceptions. Unfortunately, not even MS followed its own guideline! This means that there are system/CLR exceptions which inherit directly from Exception and others which inherit (wtf?) from ApplicationException… Bottom line: these two classes are useless in the real world!

And that’s it for now. In the next post, I’ll present some considerations you should keep in mind when throwing an exception. Stay tuned for more.

After a great month of vacations, it’s time to go back to work.

And this time, I’ll write a couple of posts about exceptions and exception handing in .NET. In .NET, we should generate an exception when a member (method or property) fails to complete its task correctly. Did you noticed the “fails to complete its task correctly” part? It might be a little bit cryptic, so let’s expand it a little more. Say you’ve got a method which needs to change the value of an integer field as a result of some operation performed over another object it receives as a parameter. There might be some assumptions here…for instance, suppose that that method needs the passed in object to be in a specific state…if that doesn’t happen, then you probably should signal that by generating (ie, throwing) an exception. If you’re consuming that method, then you need to know how to handle an exception. And that is what I’ll discuss in this post.

Let’s take a look at an example…the following snippet illustrates how we can handle exceptions in our code:

Whenever you write code that might throw an exception, it’s a good idea to wrap it up with a try block and specify the exceptions you’re prepared to handle . As you can see, the DoSomething method can recover from the specifics InvalidCastException and AmbiguousMatchException exceptions (notice the use if the catch keyword). Within a catch block, you’ll probably find some logging code which gets and logs information about the current exception. If you’re not able to recover from the exception, then your best option is simply to rethrow the current exception (as it’s shown in the catch all exception block – the third catch instruction). Don’t be tempted to rethrow the exception by writing throw ex;. If you do that, you’ll end up with a new exception stack and the original error stack is lost!

Having said this, there are several choices you can make at the end of the catch block. You can:

1. rethrow the exception (as shown in the global catch block in the previous snippet);
2. create a new (richer) exception and throw it (notice that this is not the same as throw ex; I’ve mentioned before);
3. simply let the thread “leave” the current catch block.

(We’ll return to this in a future post.)

As you probably know, the catch block code will only be executed when the code in the try block generates an exception. When you have several catch blocks (as in the previous example), the CLR will evaluate them from top to botton in the order they were declared until it finds one whose parenthetical expression’s (ie, the expression which appears after the catch keyword) catch type is compatible with the current exception’s type. That’s why you should always put the more specific exceptions at the top.

If the CLR doesn’t find any matching catch code block associated with the try block where the exception was thrown (this doesn’t happen in the previous example because there’s a catch all code block), then it will keep looking in the current call stack until it finds a matching catch block or until it reaches the top of the call stack. In this last case, you’ll end up with an unhandled exception (more about this in future posts). On the other hand, when the CLR finds a matching catch block, then it will go “back” and execute all the “inner” finally code blocks, starting from within the one associated with the try block that threw the exception and stopping in the catch block that is responsible for handling the current exception. At this point, the CLR executes the code of that catch code block and, only then, will it execute the associated finally block code (provided that you don’t rethrow the current exception or throw a new exception from within the last catch code block!).

Notice that the CLR guarantees that the code in the finally block is always executed (even when there’s no exception), making it the appropriate spot for putting your clean up code. I’d say that the typical example of this is opening a file stream and ensuring it gets closed:

The finally block is optional and it must always be defined after all catch blocks (if there are any). After finishing executing the instructions defined in a finally block, the thread will simply jump into the next instruction.

Before ending this post, there’s still time to mention that it’s possible that some code defined within catch or finally blocks might end up throwing an exception. This is definitely *not* a good thing, but it’s also not the end of the world. When this happens, the CLR’s exception handling mechanism I’ve explained in the previous paragraphs will kick in and execute again as if the exception was thrown after the finally block. Notice, however, that all the information about the original exception is completely lost (it’s as if it didn’t happen).

And I guess this is it for now. Stay tuned for more on exceptions.

As I write this, I’m getting ready for enjoying month away from my daily job. I hope it’s enough for resting, but what I’d really love is to hear from you, my faithful reader .  I know I haven’t really posted much in these last couple of weeks, but I’ve been really busy updating my HTML5 book (it will more examples which try to illustrate how you can combine several new features introduced by HTML5).

Anyways, I believe it’s time to check if any of the content I’m producing has helped you in any way. When I’ve started blogging, I was working mainly in web projects. That is no longer the case today, though I’m still quite interested in that area. If you’ve been following along, you probably recall that I’ve written about several features/areas (which have ranged from web  to some posts about multithreading in windows). So, would you be interested in keep reading more about .NET basic features? Would you prefer more web? Probably, more posts about JavaScript features? What about multithreading? Some Silverlight love maybe? Or would it be great if I kept writing about several areas?

I’m not really a guru in any of these areas but, as I said, I’ve been working in all of them for quite some time now and probably I can still write one or two interesting entries about them. Thanks for your feedback!

Ah, the joy! Almost in vacations, but still one day to go!

We’ve already covered a lot of ground in this delegate series. As we’ve seen, creating a delegate is rather easy: we just need to provide a compatible method and pass it to the delegate constructor which is being initialized. However, there might be times where you don’t have all the required information for creating a new delegate at compile time. Fortunately, our job is not that complicated in these (rare!) cases because the Delegate type introduces several overloads of the CreateDelegate method which helps us in creating new delegate instances at runtime. To illustrate this strategy, we’ll reuse our old Logger delegate definition:

And now, we’re ready to create dynamic delegates…Let’s start with creating a new delegate for the following static method:

And now, here’s how we resort to CreateDelegate to create a new delegate which “wraps” the DoIt static method:

After running the previous code, aux references a Delegate instance. At this point, we have two options: we can cast aux to the correct type (not something you’d be able to do when you’re creating delegates like this) or we can rely on Delegate’s DynamicInvoke method:

DynamicInvoke ends up calling the delegate’s callback method while sending it the arguments it received. Notice that DynamicInvoce will always ensure that the passed in arguments are compatible with the ones expected by the callback method (if they aren’t, you’ll end up with an exception). As you’re probably expecting, there are also other overloads which you can use for creating delegates that wrap instance methods. Suppose we modify our Holder class so that it looks like this:

And here’s how you can create a new delegate dynamically:

And now you can invoke the delegate by executing the DynamicInvoke method like we did before.

Before ending, there’s still time to say that you shouldn’t really use the CreateDelegate overloads which use strings (instead of MethodInfo instances) because there’s a chance of getting an ambiguous binding (and that might lead to unpredicted results).

And that’s it for now. Stay tuned for more.

I’ve ended the previous post by saying what we can chain several method calls and that is what we’ll see in this post. With chaining, we can combine several delegates so that calling one of them ends up invoking all of them. A quick example is the best way to see this feature in action (I’m reusing the Logger delegate introduced in the previous posts):

I’ve started by declaring three Logger variables which are initialized with three different lambda expressions. After that, I rely on the static Combine method for creating new delegates which “combine” our delegates variables. As you can see, I start by combining del1 with null. When this happens, chain an del1 end up referencing the same memory address. The second Combine call produces more interesting results. Since chain already references a delegate, then this Combine call ends up creating a new delegate whose internal delegate list is initialized with an array that holds the two elements passed to the Combine method.

As you’re probably expecting, the last Combine call will also return a new Delegate but notice that its internal invocation list will have three (not two!) delegate references. You might expect it to have two since our chain variable holds a delegate returned from the second Combine call and you might think that the third call would combine that delegate with del3. However, that doesn’t happen and the last delegate’s internal delegate list will reference our 3 delXXX delegates.  One interesting result of this behavior is that the delegate returned by the second Combine call can be garbage collected since there isn’t any variable referencing it. Btw, you can access this internal delegate list through the GetInvocationList method.

Now, if we invoke chain, all delegates’ methods end up being called. As we’ve seen, calling a delegate through the method syntax is the same as executing the Invoke method. Internally, this method will check the delegate list. When that list is not empty, it will call all delegates present on that list (when the list is empty, it will use the target and method fields for invoking the correct method). You’re probably wondering what happens when our delegate matches a method that returns a value (different from void). Well, in that case, the returned result is the one that is returned by the last delegate that gets executed.

By now, you’re probably thinking that if we can add delegates to the internal list, then we can probably remove them from that list. And that’s true: we can remove a delegate from the list by using the static Remove method. This method expects two parameters: the first references the delegate whose internal list will be searched for; the second identifies the delegate that should be removed from the list ( match is found when a delegate’s target and method fields reference the same objects as the delegate that is passed through the second parameter).

When there are several delegates in the array, the method  will return a new delegate whose internal delegate list has all the remaining delegates. When there’s only one delegate and that delegate is being removed, the method will return a reference to that delegate. It’s also important to understand that Remove will only remove one delegate from the list (even if there are several delegates that match the delegate passed to Remove through the second list). Now that we understand the theory, here’s some code that illustrates the use of the Remove method:

And that’s it for now. Stay tuned for more!

As we’ve seen in the previous post, delegates are really easy to use: you create a new delegate definition and then instantiate it through the new operator, passing it a compatible method reference. However, there’s a lot more going on behind the scenes and that’s what we’ll start seeing in this post. The first thing we need to understand is what happens when the compiler sees a delegate definition like the one show in the next snippet:

In these cases, the compiler will automatically transform the previous delegate expression into a new class which inherits from MulticastDelegate and looks like this:

Notice that you can’t really reuse the MulticastDelegate type in C# because the compiler won’t allow you to use those classes directly from your C# code.

As you can see, a delegate definition expression ends up generating a new class with a new constructor and three methods: Invoke, BeginInvoke and EndInvoke. Lets start with the constructor. The two parameters it receives are used for initializing, respectively, the MulticastDelegate’s target and method private fields. When we use a delegate to call a static method, the target field is initialized to null. On the other hand, when we use it to call an instance method, the target field is initialized with a reference to the object whose instance member is being invoked. In both cases, the private method field references the method that should be called. Btw, you can access these values through the inherited Target and Method properties:

If you take a look at the MulticastDelegate’s code, you’ll quickly notice that it doesn’t define these properties. In fact, these properties are exposed by the Delegate type, which is used as base by the MulticastDelegate type. To be honest, I really don’t have any good explanation for having two delegate classes since our delegates definitions end up always creating new classes which expand the MulticastDelegate type (and no, you can’t either create a new type which uses Delegate as a base type in C#)…Going back to the snippet, I believe I should mention  that the Method property returns a reference to a MethodInfo instance (this type provides us access to a method metadata – this means you also use it, for instance, to get the name of the method that is being invoked).

Now that we understand what happens when we instantiate a new delegate, it’s type to see how invocation works. So, what happens when the compiler finds something like this:

If we take a peek at the generated IL, we’ll find the following code:

As you can see, our aux method called is translated into an instance Invoke method call. Btw, nothing prevents us from doing that call from our C# text:

And yes, it does compile without any errors (thank you for asking!). Internally, Invoke will use the information returned by the Target and Method properties to invoke the method. As you’ve probably inferred, BeginInvoke and EndInvoke can be used to invoke the methods asynchronously (and have been used for several years as a way to run code in parallel). We’ll probably return to the async methods in a future post…

But there’s more…the astute reader has probably noticed the “Multicast” string in the MulticastDelegate name’s type. It’s obvious that using indirection to invoke a method is really powerful, but what about using a delegate to chain the execution of several methods? We’ll see how we can do this in the next post. Stay tuned for more.

If you’re an experienced Windows developer, then you know that Windows has always relied on callback methods/functions for doing several things (ex.: window procedures). In unmanaged code, this was typically achieved through the use of callback functions which, in practice, referenced only a memory address that “had” some code which should be executed when something special happens.

As you probably know, .NET also supports this concept but, unlike unmanaged code, it does it in a type-safe way. As I said, in unmanaged code callbacks reference only a memory position and there’s no extra information about the callback method (for instance, there’s no info about eventual parameters that should be exposed by an eventual callback method). Since .NET tries to enforce type safety, the callback idea couldn’t just be directly ported from unmanaged code: it needed to be improved so that type safety is correctly enforced. And that’s how we got delegates. In .NET, delegates are always created through the use of the delegate keyword. Let’s take a quick look at a simple example:

In the previous snippet, I’ve started by introducing a new delegate (named Logger). As you can see, it’s compatible with methods that return void and expect a String. Then I’ve added a new class which uses the delegate so that it doesn’t rely in a specific class for outputting information about a number (yes, we could also have used interfaces, but lets use delegates this time). By using the delegate, we can now output information to different places by just using a different delegate instance (for example, we can use one for outputting to the console, other for outputting to a file, etc.). Another thing you’ve probably noticed is that delegates are used as methods, ie, we’re using the Logger delegate as if it’s a method from within our class. The next snippet shows how to instantiate a new delegate which outputs info to the Console: 

As you can see, we start by adding a new method which is compatible with the delegate’s signature (notice that ConsoleLogger returns void and expects a string). As we’ll see in the future, we can use static or instance methods (in this case, I’ve opted for a simple static method). You’ve probably noticed that the delegate is being instantiated in a similar fashion to a class. And that’s because it is (but we’ll leave this for a future post). Even though the previous snippet didn’t illustrate it, the truth is that the C# allows for covariance and contra-variance of reference types when binding a method to a delegate. Notice that *reference type* is important here…

Btw, it’s really simple to use delegates to call instance methods, as you can see from the next snippet:

As you can see, the code is really similar to the one we presented earlier. Even though there are several interesting differences in the way both calls are handled internally, there aren’t any from the perspective of the programmer that is using a delegate to call instance or static methods.

Oh, yes, you’ve probably noticed one important difference (when compared with the static method call): I’ve simplified the syntax used for creating the delegate instance. As you can see, I’ve removed the redundant constructor call since the compiler is smart enough for doing that work for me. Btw, and since we’re talking about code simplification, you should also keep in mind that we don’t really need to use named methods and can rely on anonymous methods:

In the previous snippet, we’ve resorted to a lambda expression for creating a method that will be called by the delegate. When the compiler finds this lambda expression, it will automatically translate it into a private static member of that class (notice that the lambda expression doesn’t access any class member!) and replace the previous snippet with a delegate instantiation expression. If our lambda expression referenced any class instance member, then we’d end up with an instance private method.

And I’d say that’s all for now. In the next post, we’ll keep looking at delegates and we’ll see what happens when we instantiate

After all, I’ve decided to write another post about custom attributes. In the last post, I’ve mentioned the use of the CustomAttributeData type. Since I’ve received a couple of questions about its use, I thought it would be a good idea to show an example of how one can use this class to check for specific values. So, I’ll just start by introducing the custom attribute and some code that applies it to a property:

In the previous post, we’ve already saw how to check if an attribute is applied to a specific target. So, we won’t be performing that check again and I’ll just show you how to recover the values applied to the properties of the attribute:

I believe the code is rather simple: positional parameters are represented by CustomAttributeTypedArgument instances, which allow us to recover its value and type. On the other hand, named parameters are represented by CustomAttributeNamedArgument instances, where each item exposes a Name (that identifies the custom attribute’s property that is being initialized) and a CustomAttributeTypedArgument property (TypedValue) which allows us to recover its value and type.

And I guess this wraps it up for now! Stay tuned for more.

Now that we already know how to create new custom attributes and how to restrict its use, it’s time to wrap up this series with a final post that shows how to rely on custom attributes to change the behavior of your code at runtime. One of the first things you’ll need to do (if not the first!) is check for the existence of an attribute. If you have a reference to a type (or can get a reference to a type), then you can perform this check by using the IsDefined method. Suppose we’ve got the following code:

And now, suppose we need to see if the MyAttribute is applied to the Student type. Performing that check is not hard, as you can see from the following snippet:

Both options return the same result (false in both cases). Btw, the second parameter passed to IsDefined is a Boolean which specifies if the attribute should be searched in the inheritance chain. Lets suppose you want to check the if the attribute is applied to a property of the Student class…once again, you can rely on the IsDefined method, but this time, you’ll have to go through each property’s type:

As you can see, the previous code is really similar to the one we had before: the difference is that in this case we’re resorting to LINQ expression to filter the properties to which the attribute has been applied.

There are, however, other interesting options for checking for custom attributes. For instance, the Attribute class introduces several overloads of the following methods (btw, there are several derived Type classes which also expose similar members – we’ve already met the one defined by the PropertyInfo type in the previous snippet):

• IsDefined: returns true when an instance of the specified custom attribute is associated with the target;
• GetCustomAttributes: returns an array where each element is an instance of the specified custom attribute that was applied to the target;
• GetCustomAttribute: returns an instance of the specified attribute if it was applied to the target.

If you’re looking for performance and you’re only interested in checking if a custom attribute was applied to a specific target, then you should use the IsDefined method. This is the most efficient method of the previous list because it doesn’t construct any instance of the custom attribute class. Unfortunately, there are times where you do need to get info about the values of the properties of an attribute class and, in these cases, there’s really no option: you do need to use one of the other methods presented in the previous list. Btw, in these scenarios it’s also a good idea to perform some sort of caching because checking for a specific custom attribute and deserializing it from the metadata tables is not an operation you’d want to perform often.

Before moving on, there’s an interesting gotcha associated with the use of the methods shown in the previous list. The next snippet illustrates this behavior:

And now, what happens if we run the previous property check (which looks for the custom attribute MyAttribute)? It will still return the Name property bacause it is annotated with the MyDerivedAttribute attribute. This might not be problematic, but it’s certainly not what you want if, for some reason, you need to ensure that the type matches only MyAttribute instances (and not its derived types). To get this behavior, you can use something like this:

Until now, I’ve only written code which tests for the existence of a specific custom attribute. Sometimes, you need to check if a specific custom attribute has its properties initialized to some values. There are several options here:

• you can get an instance of the custom attribute and then check for its properties values;
• you create a new instance of the attribute class with the “correct” values and rely on the Equals method which the base Attribute class overrides. Internally, the method will check the type of the attributes and its fields (when both attributes have the same type). Since this comparison relies in reflection, you can improve the performance of the code by overriding this method in your custom attributes so that it doesn’t rely on reflection;
• Besides Equals, there’s also a Match method which you can override for performing more “intelligent” comparisons.

But there’s still more…if you look at the MSDN docs, you’ll find an interestingly named class: CustomAttributeData. If you take a peek at the docs, you’ll notice that it introduces several overloads of the GetCustomAttributes method. In practice, you’ll use this class (and one of its GetCustomAttributes’ overload method) when you need to check for attributes for a type whose assembly was loaded through the Assembly’s ReflectionOnlyLoad method (when you load an assembly through this method, the CLR won’t execute any code in it). In these cases, you do need to rely on this helper class for getting info about its metadata since there’s no way for the code in that assembly to get executed. As you might expect, there are some differences associated with the use of this class…

For starters, the method returns a list of instance of the CustomAttributeData type (one per attribute applied to the “current” target). After getting this list, we can query each instance to determine how the object would be instantiated (ie, check which constructor would be called through the Constructor property) and see which arguments would be initialized (through the property ConstructorArguments). As you’d expect, the approach is slightly different from the one used before. To show a possible  use of this class, lets change the previous code for getting the properties of a type which have been annotated with the MyAttribute attribute:

As you can see, p doesn’t reference an attribute instance but a CustomAttributeData instance. As we’ve said, this means that we need to go through the Constructor.DeclaringType property to get the type of the attribute (which was the only thing we need to do in this scenario).

And I’d say that’s it for now. Stay tuned for more.

After another long blogging pause (for a good cause, I must say!), it’s time to go back to our .NET attribute series. In the previous post, we’ve starting looking at how we can build new custom attributes. We’ve already met several restrictions (ex.: inherit from the Attribute base class, limitations applied to the types used as fields, etc), but there’s still one important thing to talk about: how to restrict the members to which an attribute is applied.

By default, you can apply attributes to any member type. This behavior can be controlled through the usage of the AttributeUsageAttribute class. This class introduces several properties which are used by the compiler to check for the proper usage of a custom attribute. The next snippet illustrates its use:

From now on, we can only apply the DumbAttribute to methods and classes. It’s no longer possible to annotate an interface with this attribute. As you can see, the AttributeTargets enum is a flags enum (notice the combination of values) which introduces several constants that identify the application elements to which the custom attribute can be applied to. Currently, this is the only positional parameter that is expected by the AttributeUsageAttribute class. There are, however, several named parameters which are important:

• AllowMultiple: expects a Boolean which indicates that the custom attribute may be applied more than once to an element;
• Inherited: passing true means that the custom attribute will he inherited by derived classes or overriding members.

So, if you need to ensure that a custom attribute is applied only once to a member, you can something like this:

And that’s it. From its use, it’s safe to assume that you’ve probably noticed that AttributeUsageAttribute extends the Attribute class. What you’re probably wondering is what happens when you don’t annotate a custom attribute with an AttributeUsageAttribute instance…well, in this case, you’ll end up with a custom attribute which can be applied once to any type of element and it will also be automatically inherited (and yes, that means that you didn’t really need to explicitly set AllowMultiple to false in the previous snippet).

And I guess it’s all for now. We’ve already covered all the basics associated with custom attribute definition and usage. In the next posts, we’ll see how we can detect their use. Stay tuned for more.

We’ve already covered a lot of ground on the basics series…but guess what? There’s still a lot more to cover Today, we’ll start looking at how we can improve our .NET code with attributes. With attributes, we can add custom metadata to our types (and/or a type’s members). After adding extra information to a type (or to a type’s member), you can then query it at runtime through reflection so that you can influence the way some piece of code is executed. Make no mistake about it: we’re talking about some very interesting stuff here! If you don’t believe me, then take a quick look around and you’ll notice  that several .NET technologies rely heavily on it (for instance, it’s used in Windows Forms, WCF, WPF, Siverlight, serialization – oh damn, serialization is also an interesting topic for future posts, don’t you think? – you name it!).

In .NET, anyone can reuse one of the predefined attributes or   just create new one for a specific scenario. Since attributes are targeted at the CLR, then all compatible compilers must understand them, interpret them and add the required entries to a type’s metadata. Before going on, it’s important to understand that most attributes have only one purpose: defining the metadata that will be associated with a type or member. And that’s it. To drive this point home, let’s take a look at the following code:

The first thing you should notice in the previous snippet is that we apply an attribute to a type (or member) through the use of square brackets. In the previous snippet, we’re using the SerializableAttribute to say that Student type instances can be serialized. In C#, you can apply attributes to the assembly, module, types, fields, methods, method return values, properties, events and generic type parameters. Once again, from the previous example, it’s easy to understand that, by default, an attribute is applied to the associated type or member. There are, however, scenarios where you need to use a prefix to make it clear to what you’re applying an attribute to. The next snippet shows how to apply an attribute to an assembly:

Besides assembly, you can also use the module prefix if you intend to annotate the module with a specific attribute and the return prefix if you want to make sure that an attribute is applied to the return value of a method. If you’re targeting the compiler generated field or methods of an event declaration, then you need to use the field and method prefixes:

MyDummy is a custom attribute (we’ll return to this topic in the future). Interestingly, these last two prefixes are optional when you’re targeting a method or a field:

Finally, there  are also the property and param prefixes which can be used to indicate that an attribute is being used to annotate a property or a parameter:

If you’re just starting, then you’ve probably noticed that the compiler allows us to cut the Attribute suffix from the attribute name. This is only possible because the C# compiler team thought that it would be a good idea to reduce the amount of typing and to improve the readability.

And that’s it for now. In the next post we’ll keep looking at attributes. Stay tuned for more.

As we’ve seen, we’re limited quite limited when you need to define a new enumerated type: we can only specify the enum base type, the symbolic names and its associated values. That means that you can’t add new instance methods to an enum (which doesn’t really make sense because, as we’ve seen, enums are mapped into structs by the compiler). Fortunately, from C# 4.0 onwards there’s a workaround: we can rely on extension methods for adding methods that are supposed to be used as instance methods.

To  show you how we can improve  our code with utility extension methods, we’ll start by creating a new flags enums (in fact, we’ll simple reuse the Permissions flag enums we’ve introduced in a previous post):

In these cases, it would be really helpful to have a method for checking if a specific bit is on or off. Here’s how we might check that:

And now, we can perform our test as if we’ve added IsBitOn directly to the Enum declaration:

Simple and it works! And now, I’ll leave it to you to think of some cool work which can be done with extension methods Stay tuned for more!

In the last post, we’ve started looking at the static methods introduced by the Enum type. In this post, we’ll take a quick look at the instance methods provided by that type. Before going into the methods (well, to be precise, I should say method:)), I’d like to make a small detour. I’m not sure that you’ve noticed, but the compiler treats enum as primitive types . In practice, this means that we can use several operators for comparing and manipulating enum instances (I’m reusing the Sizes enum introduced in the previous post):

If you’ve been following along, then you’ve also probably noticed that we can explicitly cast an enumerated type value into a numeric type. Here’s some code that shows this:

And yes, you can also go the other way around:

But there’s more: you can also rely on a cast to convert between different enums types:

And now, back to business…

If you take a peek at the Enum API, you’ll notice that if offers several overloads of the ToString method (we’ll only talk about 2 because the other ones are considered deprecated). As we’ve seen, you can rely on this method to get an enum’s string equivalent representation. The overload that expects a string let’s you pass a value which identifies the format that should be used. Here’s some code that shows how to use this method:

Even though it’s not recommended (or even a good practice!), you can have several symbolic names refer to the same value. In this case, you don’t have any control over which name will be returned when you call the ToString method for formatting the value in the general format.

On the other hand, if there’s no symbolic name for the current value, then the returned string will contain that value:

The behavior of these ToString methods changes slightly when it notices that the current instance is a flags enum. Here’s an example (I’m reusing the Permissions enum from this post):

When the ToString detects the FlagsAttribute applied to the current enum, it treats the current numeric value as a set of bits. In practice, this means that the current numeric value is ANDed with all the enum’s values. For each AND operation that returns true, that value’s associated symbolic name is added to a string and that bit is turned off. If after the end of this algorithm, the final value obtained from the ANDing operation isn’t zero, (recall that each “successful” AND turns off the “associated bits”) then the method knows that there aren’t symbolic names for all the turned on bits of the current numeric value and it will simply return a string with that numeric value.

Btw, if the flag enums has an all “All“ value which matches all the enum’s values and the current value matches that “All” value, then the ToString will return the “All”’s symbolic name. Here’s an example that shows this behavior:

And that’s  for now. Stay tuned for more.

Since a C# enum declaration is always “transformed” into a struct which inherits from the Enum type by the compiler, then we can reuse those instance methods inherited from Enum and the static ones which expect Enum parameters. In this post, we’ll be looking at the static methods defined by Enum. Lets start by introducing a simple enum which we’ll reuse through the rest of this post:

One of the things you might need is get an enum’s underlying type, which can be done through the static GetUnderlyingType method:

It’s also possible to enumerate the names and values of an enumerated type by using the GetValues and GetNames methods:

You’ve probably noticed the Int64 cast…if you don’t do that, you’ll end up with a string with symbolic name instead. This happens because the GetValues method returns an array which contains one element for each symbolic name of the enum, where each element is an object with the corresponding boxed enum symbolic name’s value.

The Enum class will also let you get the symbolic name of a value by using the static GetName method:

If you’ve got a string, you can try to map it into an enum’s symbolic name through the static Parse method:

In the previous snippet, I’ve used the overload which accepts a Boolean that specifies if the matching should be done in a case insensitive manner (true in the previous example). If Parse can’t match the string to a symbolic name, then it will simply generate an exception. If this behavior is not acceptable, then you should rely on the TryParse method instead.

You can also use the IsDefined method if you want to check if an enum supports a specific value or symbolic name:

As you can see, we can pass a value or a string that identifies a symbolic name. When we pass a value, we must ensure that it has the same type as the one used as the enum’s underlying type. If you don’t do that, then you’ll end up with an exception. Notice also that, unlike Parse, there’s no overload for specifying that the symbolic name matching should be done in a case insensitive manner. Too bad, but that’s life…There’s also a small penalty associated with the internal use of reflection…Finally, it’s important to notice that the method might not work as expected when you pass it a value from a flags enum (where you’ve combined two values). Bottom line: it’s probably a good idea to stay away of this method…

Finally, there’s one more static method: ToObject. There are several overloads of this method (that differ in the expected parameter type) which allow you to convert a value into an enumerated value:

The most interesting thing about this method is that it allows us to pass values of a different type used for the enum’s underlying type. Do notice that there’s also a nasty problem which might get you off guard:

Wow! wtf? Yes, it works. you end up getting a Sizes enum whose value doesn’t have an associated symbolic name. I believe that there are some reasons for allowing this. First, I’m not sure if checking the value would be a reasonable thing to do from a performance point of view. Second, what would be the correct behavior for flag enums? Btw, there’s a similar problem when you initialize a Size enum variable with its default value:

Yes, Default(Sizes) produces a Sizes enum value set to 0. So, if you’re really interested in ensuring that you’ve got a “valid” enum value, don’t forget to check it before converting it into an enum (you can use the IsDefined method or create your own custom routine for doing that check). And I guess this is all for now. In the next post, we’ll take a quick dive into the instance methods inherited from Enum. Stay tuned for more!

In the previous post I’ve introduced the concept of enumerated type. As I’ve said, we can resort to an enumerated type to introduce several symbolic names/values pairs. As we’ve seen, enum are transformed into structs which extend the Enum type. During this transformation, the compiler ends up adding constants fields to the struct. By default, ints (System.Int32) are used as the default type for each of these constants. You can change this type by changing the enum’s underlying type:

When the compiler finds the previous enum, it will transform each of the symbolic values into Int64 constants. Besides long, you can also use one of the following primitive types as an enum underlying type: byte, sbyte, short, ushort, int, uint, long, ulong. Notice that (unfortunately!) the compiler forces you to use the C# primitive type name (alias). If you try to use the FCL name, then you’ll end up with a compiler error:

Besides setting the underlying type, you can also be explicit about the values associated with each symbolic name:

As you can see, if you can resort to an attribution if you want to be explicit about the value of symbolic name. If you don’t set a symbolic name’s value explicitly, then it will add one to the previous value (that’s why Sizes.Small has value 11).

Enums can also be used as flags (aka bit flags).  Here’s an example:

In the previous example, we’re using an enum to express a set of bits which can be combined (unlike “normal” enumerated types’ values). Notice also how each symbolic name’s value is defined so that it will only “turn on” a single bit (the comments show the integer represented in binary). In practice, the previous enum allow us to write code like this:

After grabing an enum value, you can check if a specific bit is “on” with code like this:

Even though the previous Permissions enum definition is enough to explain the usage and purpose of flag enums, it wouldn’t be complete without presenting a couple of recommendations associated with its use. So, besides ensuring that each symbolic name’s value will have a single bit turned on, it’s also common to introduce a value called None and the combinations of the most used values. Let’s update our Permissions enum to reflect these recommendations:

And I guess that’s it for now. Stay tuned for more.

I guess all .NET developers have already used enums (aka enumerated types) in applications, right? if this is true, then you probably know everything there is to know about enums, right? If that is the case, then I’d say you’re can probably miss this and the next couple of posts. On the other hand, if you didn’t have the time to dig into things or if you’re unsure about one or two things, then this series will probably be worth a couple of minutes of your time 🙂

Lets start from the beginning, ok? What’s an enum? An enum is a type which defines several symbolic names/value pairs. Here’s a quick example good enough for getting started:

By default, all enum types use ints to store the values associated with symbolic names (this can be changed, as we’ll see in the next post). When you don’t initialize a symbolic name with a name explicitly, then the first name (XSmall) is associated with value 0, the second with the previous value + 1 (in this case, Small is associated with the value 1), and so on. After introducing an enum type, we can simply refer to its symbolic names. Here’s an example of this:

Many see enums as allowing us to mention a value by name (for instance, in the previous snippet, we could see Small as a “synonym” for 1). If that is the case, then are there any advantages in using enum types? The answer is yes, there are several:

• they tend to improve the readability of your code (I believe that Sizes.Small confers meaning which 1 – its associated value – can’t);
• they contribute to easing the maintenance of your code (if you’re using ints, what happens when you need to update 0 to 1?)
• enums are *strongly* typed.

All of the previous reasons are important, but I believe the last one is *probably* the one that makes using enum a *must*. Being strongly typed means that the following code won’t compile:

Enum’s first class treatment gives us a lot of power. But there’s more. All enum types inherit from System.Enum (which inherits from System.ValueType). In pratice, this means that enum types are  value types. However, unlike other value types, you can’t add new methods to an enum directly (like you do when you create new struct). There’s a workaround for this, but the most common case is using inherited methods from the Enum base class (this class introduces several interesting methods which allow us to perform several utility operations over enum values – more about this in future posts).

Even though enum’s usage in C# is rather limited (you can define their symbolic names, values, “base types” and that’s it), it’s probably interesting to end this post by trying to understand how the C# compiler transforms that code into IL. Let’s give it a try, shall we? Let’s take a look at the IL generated for the Colors enum:

As you probably can deduce, each symbolic name is transformed into a const field. In other words, it’s as if you’d written the following C# (btw, don’t try it! You’ll get a compile time error since the C# compiler won’t allow the direct use of the Enum type as a base type):

As I’ve said, you can’t write this last snippet in C#. However, I believe that thinking about this implicit mapping between enum and this pseudocode makes it easy to understand why we can use the instance and static methods introduced by the System.Enum type, right? And I guess this is becoming a rather long post, so that’s all for now. Stay tuned for more on enums!

Even though I’ve thought that the previous posts were enough for presenting the Nullable<T> type, the truth is that I’ve received a question about them from a friend of mine. Here’s what he was asking:

If GetType returns T’s type, then how do you know you’re working with a nullable value type?

Nice question…glad you’ve asked about it, though I was saving that part for a future post about reflection. Anyway, the question was asked and I thought I’d give a quick answer here. As we’ve seen in previous posts, Nullable<T> instances have special support and that means that getting the “real” underlying type isn’t really that easy. In practice, we want to ensure this behavior:

Our IsNullable helper method can only return true when it receives a Nullable<T> instance. If, like me, some of your day time is used reading the framework’s code in Reflector, then you’ll probably noticed that there’s a Nullable helper class which exposes several utility methods. One of them is of special interest to us. I’m talking about the GetUnderlyingType method, whose implementation looks like this:

As you can see, the method will return null when it doesn’t receive a Nullable<T> type. It’s also obvious that the method relies heavily in the Type class, which  offers several interesting members that allows us to see if we’re working with a Nullable<T> instance. With this information, it’s time to try to build the first  version of our IsNullable helper method:

hum…you know what? This won’t really work…why? it’s simple: if we write IsNullable(aux.GetType()), we’ll end up with something like IsNullable(typeof(Int32)) and that will always return false. What about changing the declaration of IsNullable so that value is an object reference?

Nop, that won’t work either because the Nullablet<T> GetType “special” method will still produce the wrong results. Going back to the first version of IsNullable, you can see that if we call it like this:

It produces the expected result. So, what we need is a way to infer the type of a variable without specifying explicitly through the GetType call. Is there a way to solve this problem? Yes, there is: enter generic type inference! Here’s our final version of the IsNullable method:

And now, we can call the method by passing it a value:

As you can see, IsNullable relies on the typeof operator for producing the correct result. Another interesting thing is that the IsNullable method doesn’t really use the value var for anything: it’s only there so that the compiler can infer its type. And there you go: a nice trick for checking if a variable is a nullable value type. Before ending, it’s important to give credit to the guy that presented this strategy. I’m talking about Jon Skeet, who presented this code while answering a similar question on the stackoverflow site. And that’s it for now. Stay tuned for more.

In the previous post, I’ve introduced the concept of nullable value types. As I’ve said back then, C# allows us to use a simplified syntax for working with nullable value types:

This code is equivalent to the one presented in the previous post. Whenever the compiler finds the XXX? type declaration, it will always convert it into a Nullable<XXX> declaration. But there’s more. I’m not sure if you’ve noticed it, but I’ve initialized the aux2 variable with null. But how can this be if Nullable<T> is a struct? This is only possible because there’s special support for the Nullable<T> type.

Since Nullable<T> instances should behave like Ts, then it’s also possible to apply other “known” operators to these instances:

Isn’t this fantastic? You can also use binary operators with Nullable<T> instances:

When using binary operators, the final result will always be null if one of the instances hasn’t got a “valid value” (ie, if the HasValue property returns false). Finally, you can also check for equality (== and !=) and compare instances (<, >, <=, >=). There is, however, a catch: the code generated for performing these operations is longer than the one you get when you use Ts directly. One final note regarding operators: since T (from Nullable) can be replaced by any struct, then you can create a custom struct and make it “nullable”. Notice that if your custom struct introduces custom operators, then they will be called when you’re manipulating nullable instances of those types! This is simply great!

Finally, and since I’m presenting some C# specific simplifications, I couldn’t end this post without mentioning the null coalescing operator (??). This operator takes two operands. If the one on the left isn’t null, that operand’s value is return. If it is, then the value of right operand is returned. This operator can simplify the code needed for initializing variables:

Before going on, it’s important to understand that the null coalescing operator can also be applied to  reference types. Some say that this operator wasn’t really needed because you could always use the ? : operator. Well, that’s probably true, but there’s one scenario where the null coalescing operator introduces a clear advantage: readability in composition scenarios. Here’s an example:

I’d say that reading this line is easy and simple…And I guess that’s it for now. Stay tuned for more!

To wrap up this series on .NET arrays, I’ll show you how to create a fixed size buffer (aka internal arrays). A fixed size buffer is useful technique for improving the performance of your app when you need to interop with unmanaged code. To understand the gains from this approach, we’ll start with a simple example:

As you probably know, struct is a value type and that means that it will be allocated in the stack (this is an implementation detail which is important when you’re after performance improvements). Now, what you probably forget is that the Int32 array won’t be stored directly in the stack. Since arrays are reference types, the array field defined in the struct will only hold a reference to the array. The array object will always be stored in the heap memory.

In these cases, sometimes it might be useful to be able to put the entire array in the stack.  We’ve already seen an option for doing this in the previous post. Fixed size buffers allow us to do that too. Here’s some code that shows how to change the previous code so that the array is completely embedded in the struct:

The first thing to notice is that we can only embed an array in an unsafe struct (which, when you think about it, makes sense). If you want, you can apply the unsafe keyword to field (instead of applying it to the struct). Notice also that the array can only be a single dimension zero-based array of one of the basic type (ex.: Int32, Single, etc). Going through all the items of the array can be done in several ways. You can use a pointer or you can simply use the array-like syntax:

As you can see, instantiating a Wrapper will automatically instantiate an array of integers in the stack. As you’re probably expecting by now, you can only instantiate Wrapper from an unsafe context. And that’s it for now. There’s still more to say about .NET basics. Stay tuned for more.

I’ve ended the previous post saying that there was still one extra mile we could take to improve the performance associated with arrays in .NET. This extra mile has a name: stackalloc. The stackalloc keyword can only be used in unsafe code and it’s responsible for allocating a block of memory on the stack. In practice, stackalloc creates a single-dimension zero-based array of of value type elements (whose fields’ types are not allowed to be reference types).

There are a couple of things you should keep in mind if you decide to use this option:

• since the memory block is allocated in the stack, then that memory will automatically be reclaimed at the end of the method where it was allocated.
• you won’t be able to pass this memory block to most of the  methods exposed by the types introduced by the framework.

Having said this, it’s time to show a quick sample:

As you can see, it’s not that complicated. The stackalloc keyword is used in place of the new keyword and we end up with a memory block in the stack which is big enough for storing 10 integers.

In the real world, you’ll (probably) use the stackalloc keyword for those scenarios where performance is a must or when you need to use interop to communicate with unmanaged code. In fact, I think that interop is one of those scenarios where stackalloc is a good option.  By using it, you don’t have to allocate an array in the heap (leading to less GC pressure), you don’t have to pin memory (don’t forget that this is a must for passing a reference from a managed object to unmanaged code) and you get automatic clean up on the method’s exit.

Since we’re talking about arrays allocated in the stack, there’s still one more option: fixed size buffers. We’ll take a look at them in the next post! And that’s it for now. Stay tuned for more.

In the previous post, we’ve looked an non-zero based arrays and I’ve ended the post by talking a little bit about performance. As I’ve said, non-zero based arrays are not really something you want to use regularly. Besides that, we’ve also seen that regular arrays aren’t as performant as jagged arrays because the compiler won’t, for instance,  hoist the index checking outside an eventual loop. Since this index hoisting *does* make a difference, then how can we improve the performance of our code? Well, there is a way for improving the performance, at the coast of safety: I’m talking about using unsafe code for enumerating the items of an array!

When you use this strategy, you’re performing a direct memory access. Notice also that these accesses won’t throw exceptions when you access an “invalid position” (like it happens when you use the “traditional approach”). Instead, you might end with a memory corruption…

In practice, using unsafe code means that the assembly that contains this code must be granted full trust or have the security permission’s skip verification option turned on.  After this basic intro, it’s time to see some code. The next snippet introduces two methods which go through all the items of a rectangular array by using a safe and an unsafe approach:

There’s not much to say about the SafeAccess method. There are, however several interesting observations about the UnsafeAccess method:

• the method is marked with the unsafe keyword because it uses pointers to access the items on the array (don’t forget that you need to compile this code with the /unsafe option).
• ptr is a pointer which points to the memory address of the first item of the array.
• We’re fixing (or pinning) the pointer (by using the fixed statement) to prevent the GC from reallocating a movable variable (since the ints references a managed array, it could get moved during a GC compaction operation).
• We need to perform the calculations required to access the items of the array. Even though we’ve got a rectangular array, the truth is that it is allocated as single block of items, where one line is appended to the end of the previous one.
• Finally, notice that we get the value of each value by using an “array index syntax” (similar to the one used in traditional C# code and to the one you can use with unmanaged C or C++)

In my machine, running the previous code resulted in the following output:

As you can see, there’s a small difference which can make all the difference in the world for those apps  where you do need that extra performance ounce…Before ending, a couple of observations:

• as I said, this code needs full trust and there might be some places where your code won’t have it.
• This strategy can only be used for arrays which hold primitive types, enums or structs whose fields’ type is one of the previously mentioned types.

If you want, there’s still an extra step for improving the performance of code that interacts with arrays, but that will be the topic of the next post. Stay tuned for more.