Adventures in .NET

Compiling Desktop Apps for Windows RT… Maybe

2012-09-13T15:05:00.001-04:00

As you may know, Windows RT when it launches in 6 weeks will only support limited applications in desktop mode, like Notepad, Paint, Explorer, and Office Home & Student 2013 RT. However, Visual Studio 2012 ships with a fully-functional ARM cross-compiler for C++ code! Fully-functional means just that – it can compile any assembly for the ARM platform.

The compiler is located in C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm. If you want to use the ARM compiler tools, like cl, you must first register the environment variables by executing vcvarsx86_arm.bat in that folder.

However, if you try to use cl to compile a simple console application, like a Hello World example, it will give you this nasty (and expected) error:

fatal error C1189: #error : Compiling Desktop applications for the ARM platform is not supported.

I was curious about whether or not it was possible to get around this. Then I found this StackOverflow question that gave me a clue. There is a part of the file "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\crtdefs.h" that contains a reference to an ARM SDK definition:

#if defined(_M_ARM)
#if _CRT_BUILD_DESKTOP_APP && !_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE
#error Compiling Desktop applications for the ARM platform is not supported.
#endif
#endif

So all you have to do is define that _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE with the /D argument and you can compile for ARM:

Obviously you can’t run ARM apps on an x86/x64 machine, but this shows that it did successfully compile a PE executable for the Windows on ARM platform. Now, since there aren’t any Windows RT devices out yet to test this on, I can’t even begin to say whether or not this will work. Most likely I’m assuming that Windows RT has some sort of either whitelisting or digital signature verification for desktop apps that are allowed to run, which would be beyond my ability to work around.

But, this brings up the point that obviously developers at Microsoft have been using an ARM compiler to compile apps for Windows RT, and it seems like they are most likely using these same tools. I’m assuming they define that _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE definition when they compile, too. And perhaps there’s a more elaborate SDK available, since that definition mentions “DESKTOP_SDK”, if it is true that there are digital signatures involved.

So it could be (and is most likely the case) that this was a complete waste of 10 minutes if it won’t run on Windows RT without some hackery, and I won’t know that until 6 weeks or so when I hope to have my hands on a Microsoft Surface – but it was a fun exercise nonetheless.

Extending Blaze with NuGet Support

2012-08-27T14:10:00.001-04:00

TL;DR Version

I recently extended the open-source Blaze C# Script IDE with NuGet support. You can get the latest version at the Blaze project site, or check out the source code changes at Bitbucket.

Continuing on…

I am a big fan of REPL loops. Even if you’re not familiar with the term, you’ve probably used one as a software developer. Standing for “Read-Evaluate-Print Loop”, it’s a console-like entry where you can type code and immediately execute it and see the result. For an example, hit F12 on any page in Google Chrome and go over to the Console tab. You can start typing JavaScript and hit enter and it will immediately run.

As a C# developer, occasionally I find myself needing to use a REPL to validate logic. Of course, I could open up a new Visual Studio console application project and do it that way, but that takes a while to get set up and then you have to write a bunch of nasty other code to handle the console, and then you have all these files on your hard drive that you probably won’t use again. A REPL makes that situation so much easier, as you can just fire it up, type in your code, run it, and see the result without creating a single file on your hard disk (temporary files aside, of course).

Thanks to the Roslyn project, there will be a Microsoft-supported C# REPL sometime in the future. Until then, though, I’ve previously been using the good-but-not-great gsharp utility that’s included as part of the Mono project install. That is, until I heard about Blaze.

Blaze is a C# script IDE that is the next best thing to a C# REPL. In many ways, it’s better than a REPL, as it is document based, so you can save and load scripts to/from your hard drive, and you can run just a portion of the script by selecting the text to run and hitting F5. It’s developed by my colleague, fellow feature[23] lead software engineer Zachary Gramana.

Since I heard about Blaze shortly after starting with feature[23], I’ve been using it often for testing code and validating logic. It’s exactly what I need as a C# developer, and it’s now an essential part of my toolkit. You can download the app from the Codeplex project site by hitting the big Download button on the right side. It’s a ClickOnce application, so any time it gets updated you’ll get the latest version on launch.

One handy feature of Blaze is that you can add references to DLLs, via the “Reference Assemblies…” menu option under “Runtime Settings”. This allows you to add in, say, a reference to Json.NET (also known as Newtonsoft.Json) and test out JSON serialization using a third-party utility before adding it to your app.

That’s exactly what I was trying to do last week when I realized “hey wait a second, I usually add Json.NET to my project via NuGet, so now I have to hunt around for the DLLs!” After a bit of thinking and discussion, I realized that I could probably add NuGet support to Blaze! And so I did.

From the Add References screen, click Add a NuGet Package and you’ll get this dialog above. It’s designed like the Package Manager console, so you can type in the name just like you might see on the NuGet Gallery package page, like this one for Json.NET. (Specific versions with the --version argument are not yet supported.)

After typing in the term, hit enter, and it’ll search NuGet for the package. If it’s found, you’ll see any dependencies the package has, as well as it’s DLLs.

Selecting a DLL then clicking Add Selected References adds the reference to the parent dialog. If there are any dependencies, double-clicking on the dependency will jump to that NuGet package.

After adding the references, you can then use the DLLs as you normally would.

Using the NuGet API

The NuGet API is very clean and easy to use, but there aren’t many good tutorials out there for using it. Here’s a simple example tutorial, hopefully from here you can explore the rest of the API and make more advanced use of it. First, add a reference to NuGet.Core using NuGet (how meta is that?!). Next, create a new PackageRepository using the PackageRepositoryFactory:

var repo = PackageRepositoryFactory.Default.CreateRepository("https://nuget.org/api/v2/");

Of course, you eventually will want to not hard-code that link (although it’s currently hard-coded in Blaze). Next, if you’re looking for a package by its identifier (like we are in Blaze), you’ll call FindPackage on that repository, passing in the identifier as the sole parameter. (If you’d rather search, you can call repo.Search and handle the results differently.)

var result = repo.FindPackage("Newtonsoft.Json") as DataServicePackage;

This method can throw exceptions, like if there’s a 500 server error, so make sure this is wrapped in a try/catch. If it is successful, result will be a DataServicePackage instance. You’ll want to cast it as DataServicePackage so you have access to the package DownloadUrl property. To download the package, first new up a PackageDownloader.

var downloader = new PackageDownloader();

Now you can call DownloadPackage to do an HTTP request to download the package, which is basically a ZIP package.

var downloaded = downloader.DownloadPackage(new HttpClient(result.DownloadUrl), result) as NuGet.ZipPackage;

The DownloadPackage method is a blocking call that can also throw exceptions. Now that you have the ZipPackage, you’ll want to open it to extract the files. In our case, we’re looking for an exact file name to extract. In order to extract files, you must use the System.IO.Packaging namespace that’s in WindowsBase.dll, part of the .NET Framework 4.0. You’ll usually need to add a reference to this DLL, unless you’re writing a WPF app.

Finally, you’ll need to open the package stream, open the stream of the file within the package you want to extract, then copy the stream.

using (var stream = downloaded.GetStream())
{
    var zip = Package.Open(stream);

    var part = zip.GetPart(new Uri("/lib/net40/Newtonsoft.Json.dll", UriKind.Relative));

    string filePath = "C:\\Users\\Paul Irwin\\Desktop\\Newtonsoft.Json.dll";

    using (var zipFileStream = part.GetStream())
    using (var fileStream = new FileStream(filePath, FileMode.CreateNew))
    {
        zipFileStream.CopyTo(fileStream);
    }
}

The namespaces you’ll want to include are NuGet, System.IO, and System.IO.Packaging. And, of course, I hard coded a number of strings in that example, but you should be able to take this from here and modify it as you please.

All in all I’ve enjoyed playing around with the NuGet API, and it was a fun project to work on!

Translating Objective-C to C# – Part 2 of n

2012-05-29T14:27:00.001-04:00

I hope by now you’ve already read Part 1, and if not, go do so now! As I left off last time I mentioned that I’d cover interfaces vs. implementations, type checking, inheritance, alloc-init, polymorphism, self/this and super/base keywords, properties, and initializers from Chapters 4-5 of the excellent book Programming iOS 5, Second Edition.

These 2 chapters get a little more in-depth into understanding Objective-C enough that you can then go and understand the basic Cocoa usage examples. This might be the last post purely about the Objective-C and C# languages, but I hope to get into more of a framework discussion of translating Cocoa to XAML for Windows Phone or Windows 8 Metro app development.

Again, I’ll be using a subset of the examples from the book as the source, but to fully understand the context, I recommend picking up a physical or eBook copy as it really is an excellent book!

Interface vs Implementation

At first, I assumed that Objective-C interfaces were much like C# interfaces in that they define the methods that a concrete type implements (and Objective-C actually uses the @implementation keyword for the concrete type), but after getting to the Cocoa examples, I realized this is not the case.

An Objective-C interface is pretty much an equivalent of a C++ header file (and, in fact, if you have the interface in a separate file, it uses a .h file extension, just like a C++ header file). It does not define an interface that other types can use as a contract – that’s what protocols are for, which I’ll cover later.

In Objective-C, you must have an @interface and an @implementation for classes you create. They can be in the same file or in separate files (the @interface in a .h file, and the @implementation in a .m file). In C#, you do not need a “header” for defining a class – this information is extracted as metadata at compile time.

Here’s the example of a trivial, single-file interface and implementation:

@interface MyClass : NSObject
- (NSString*) sayGoodnightGracie;
@end
@implementation MyClass
- (NSString*) sayGoodnightGracie {
return @"Good night, Gracie!";
}
@end

Notice that the @interface is where the inheritance is defined – MyClass here inherits from NSObject. There is a single instance (non-static) method called sayGoodnightGracie, and its signature is defined in the @interface and implemented in the @implementation. Notice that the interface and implementation share the same name – that should be your first clue that interfaces in Objective-C are not the same as interfaces in C#, as a class cannot share the same name (in the same namespace) as an interface it implements (or any other type, for that matter).

In C# meanwhile, the class is a bit simpler to define:

public class MyClass
{
    public string SayGoodnightGracie()
    {
        return "Good night, Gracie!";
    }
}

Now I’ll temporarily deviate from the book’s order to cover protocols, because they are what is equivalent to C#’s (or rather the CLI’s) interfaces. Like I mentioned, an Objective-C protocol is equivalent to a C# interface. Often you may read/hear Objective-C developers refer to protocols as delegates, as they are often used in a delegation pattern by Cocoa types, but a protocol itself does not innately imply delegation. If we wanted to create a protocol for the MyClass above, here’s what it might look like in Objective-C:

@protocol ISayGoodnightGracie <NSObject>
@required
- (NSString*) sayGoodnightGracie;
@end

Notice that the @required keyword means that any signatures following it must be implemented in the concrete types – there is no equivalent to this in C#. If a C# interface defines a signature, it must be implemented by the inheriting type.

Now, in order for MyClass to implement ISayGoodnightGracie, we use a special syntax using angle brackets. Also, we remove the signature from the @interface since it is now defined in the @protocol:

@interface MyClass : NSObject <ISayGoodnightGracie>
@end

@implementation MyClass
- (NSString*) sayGoodnightGracie {
return @"Good night, Gracie!";
}
@end

To translate this to C#, we define a new public interface called ISayGoodnightGracie, and make MyClass inherit from it using a colon delimiter:

public interface ISayGoodnightGracie
{
    string SayGoodnightGracie();
}

public class MyClass : ISayGoodnightGracie
{
    public string SayGoodnightGracie()
    {
        return "Good night, Gracie!";
    }
}

Type Checking

Now, back to where the book left off. Next up is type checking – or, checking whether an instance inherits from a given type in its inheritance heirarchy.

You might think this is similar to .NET’s Reflection, and it is, to a small extent. Each class in Objective-C has a corresponding Class instance, which is roughly equivalent to the System.Type type in .NET. You can get a class’ Class instance in Objective-C like this:

Class c = [MyClass class];

Which is mostly equivalent to the typeof operator in C#:

Type t = typeof(MyClass);

One major difference, however, is that you can send messages to static (class) methods to that “c” variable above – something you cannot do in C# to the “t” variable above.

You can also get the Class of a given object instance using the same “class” method:

MyClass* m = // something or other...
Class c = [m class];

And in C#, this is equivalent to the Object.GetType instance method:

MyClass m = new MyClass();
Type t = m.GetType();

Again, the same limitation of static method calls in C# applies.

Now that you can see how you can get type information, hopefully that will help in understanding determining inheritance. Objective-C has a way of checking to see if an object instance inherits from a type, using the isKindOfClass method, defined like this:

- (BOOL)isKindOfClass:(Class)aClass

In the book, it is used like this, in an if statement:

if ([someObject isKindOfClass: [MyClass class]]) // ...

C# has a few methods to determine inheritance. The most direct translation of the method above would be to use the “is” keyword:

if (someObject is MyClass) //...

This will work for exact matches as well as looking up the inheritance heirarchy, just like isKindOfClass does. You can use isMemberOfClass for exact matches in Objective-C, while you can use someObject.GetType() == typeof(MyClass) in C# to do an exact comparison.

[[MyClass alloc] init] and Initializers

Repeatedly in Objective-C you will see code equivalent to the following, known as the “alloc-init pattern”:

MyClass* m = [[MyClass alloc] init];

The inner message allocates space in memory to hold an instance of MyClass based on its known size, while the init message call performs any default initialization of instance variables or other initialization tasks. It then returns a pointer to the newly created object. According to the book, you will almost never want to separate these out into separate lines (i.e. storing just the result of alloc to a variable, then calling init), and as I’m just learning Objective-C, I can’t foresee a situation where you would need to. (I would appreciate if someone could outline for me an example where you might want to break with this pattern and do so – as well as what the dangers would be.)

In C#, the allocation of a new instance of a type is accomplished with the “new” keyword, and which constructor (equivalent to initializers in Objective-C) to call is determined by the parameters following the type name. The “init” message above is a default, parameterless initializer, which is much like a default, parameterless constructor in C#. Like I mentioned in the previous post, the pointers are implicitly managed for you, so you do not need the asterisk. The Objective-C example above would be equivalent to the following in C#:

MyClass m = new MyClass();

You will find that there are parameter-based initializers as well, such as NSArray’s initWithObjects initializer:

NSArray* pep = [[NSArray alloc] initWithObjects:@"Manny", @"Moe", @"Jack", nil];

This initializer would be equivalent to the following constructor, if you recreated the NSArray type in C# and didn’t reuse the BCL array type:

public NSArray(params object[] objects) { … }

Which would be called like this:

NSArray pep = new NSArray("Manny", "Moe", "Jack");

One major difference between Objective-C initializers and C# constructors is that C# (or rather .NET’s CLI) doesn’t use different identifiers for different constructors, they are merely method overloads if you have more than one – whereas the above Objective-C “initWithObjects” is clearly a different identifier than just “init”.

Also note in this example that variable-length arguments must end with nil as a terminator in Objective-C, but that is not required in C#.

There also is the concept of default initializers in Objective-C, where other initializers must ultimately call the default one – but there is no such requirement amongst instance constructor overloads in C#, although it is possible with constructor chaining:

public MyArray(params object[] objects) { /* ... */ }

public MyArray(List<object> objects) : this(objects.ToArray()) { }

In the above example, if you pass a List<object> into the MyArray constructor, it will pass the list as an array to the variable-length constructor overload.

Polymorphism

Polymorphism in Objective-C works very much like a C# developer would expect. You can implicitly cast an object to one of it’s inherited types upon assignment, like in this example from the book, where UIButton inherits from UIControl, which in turn inherits from UIView:

UIButton* b = [UIButton buttonWithType:UIButtonTypeRoundedRect];
UIView* v = b;

If these types existed in .NET, the previous code might look like this:

UIButton b = UIButton.ButtonWithType(UIButtonType.UIButtonTypeRoundedRect);
UIView v = b;

Both examples demonstrate the implicit conversion between a child class and a class higher up in its inheritance heirarchy. Much like C#, in Objective-C you can’t call a method on a variable of the higher class (UIView) that is defined in the lower class (UIButton) without an explicit cast (except without ARC enabled, in which case you’ll get a compiler warning). So the following would be illegal Objective-C with ARC enabled:

UIButton* b = [UIButton buttonWithType:UIButtonTypeRoundedRect];
UIView* v = b;
[v setTitle:@"Howdy!" forState:UIControlStateNormal];

But if you cast V to UIButton, it does work:

UIButton* b = [UIButton buttonWithType:UIButtonTypeRoundedRect];
UIView* v = b;
[(UIButton*)v setTitle:@"Howdy!" forState:UIControlStateNormal];

Likewise, here’s an illegal C# example of the above code:

UIButton b = UIButton.ButtonWithType(UIButtonType.UIButtonTypeRoundedRect);
UIView v = b;

v.SetTitle("Howdy!", UIControlState.UIControlStateNormal);

But the following is legal, since we’ve cast v to the type that defines SetTitle:

UIButton b = UIButton.ButtonWithType(UIButtonType.UIButtonTypeRoundedRect);
UIView v = b;

((UIButton)v).SetTitle("Howdy!", UIControlState.UIControlStateNormal);

Self vs This and Super vs Base

Objective-C’s “self” keyword behaves very similarly to C#’s “this” keyword. In a simple, single-level class, the self/this keywords refer to the current instance of the class that the method is being executed on. In a parent/child class example, if you refer to the self/this keyword in a parent-level method, it can refer to an instance of the child class. This applies to virtual method calls in C#, much as it does overridden methods in Objective-C.

In the book, he uses an example where a parent class Dog has a child class Basenji, where the parent class Dog’s “bark” method is overridden to return an empty string in the child Basenji class, because Basenji’s can’t bark. Yet, when the parent class’ “speak” method calls [self bark], the “self” is referring to the most inherited version of the method for the current instance, not the “bark” method on the parent class:

@implementation Dog
- (NSString*) bark {
return @"Woof!";
}
- (NSString*) speak {
return [self bark];
}
@end
@implementation Basenji : Dog
- (NSString*) bark {
return @""; // empty string, Basenjis can't bark
}
@end
// [so, in some other class...]
Basenji* b = [[Basenji alloc] init];
NSString* s = [b speak];

This behaves the same in C# with virtual method calls:

public class Dog
{
    public virtual string Bark()
    {
        return "Woof!";
    }

    public string Speak()
    {
        return this.Bark();
    }
}

public class Basenji : Dog
{
    public override string Bark()
    {
        return "";
    }
}

// somewhere later on...
Basenji b = new Basenji();
string s = b.Speak();

Just like in Objective-C, this C# code would store an empty string to the s variable, because calling “this.Bark()” will call Basenji’s overridden method.

Much like self/this, the Objective-C “super” keyword is analogous to C#’s “base” keyword, and calls to parent class methods (like virtual methods in C# calling the base version) using the super/base keyword work much the same way.

Properties

Objective-C and C# share a powerful feature that Java still lacks – properties. Properties allow you to encapsulate a field with getter and setter methods while still allowing it to feel like you’re working with a field rather than methods. To define a property in Objective-C, you use the @property keyword in your interface:

@property (nonatomic, retain) NSString* MyProperty;

If you want to define the getter and setter methods yourself, you can use the @dynamic keyword in your implementation. (I’m a little fuzzy on this, so please someone correct me if I’m on the wrong track.)

@implementation MyClass {
    @private NSString* _myProperty;
}

@dynamic MyProperty;

- (NSString*) MyProperty {
    return _myProperty;
}
- (void) setMyProperty:(NSString*)value {
    self->_myProperty = value;
}

@end

The @dynamic keyword tells the compiler that you will supply get and set methods for the property of MyProperty. The equivalent in C# (including the @property declaration) would be:

public class MyClass
{
    private string _myProperty;
    public string MyProperty
    {
        get { return _myProperty; }
        set { _myProperty = value; }
    }
}

As an alternative to the @dynamic keyword with properties, you can use the @synthesize keyword to tell the compiler to automatically create getter/setter methods for you, as well as a backing field.

@implementation MyClass
@synthesize MyProperty;
@end

In C#, there is the automatic property syntax to do the same thing:

public class MyClass
{
public string MyProperty { get; set; }
}

One feature that Objective-C has that C# lacks is the ability to automatically create get/set methods around a named private field that you have access to. C# will automatically create a backing field for each property, but it is given a special name by the compiler and you do not have access to it without some heavy (and largely unnecessary) reflection. To use this feature of Objective-C, add the private field name with an equals sign after the property name you’re synthesizing:

@synthesize MyProperty = _myProperty;

It would be great if C# would add equivalent functionality in the future, but that doesn’t appear to be on the roadmap.

Also of note is that C# lacks property attributes – in the interface example, the attributes are “nonatomic, retain”. These attributes signal to the compiler how to treat the accessor methods – nonatomic signals that the get/set methods should not be treated in a thread-safe manner and any thread safety should be left up to the implementation method if needed, and retain says that the passed-in variable should be retained before setting the instance variable. Since these (and other) property attributes have no C# equivalent, I’ll leave them for another day.

Summary

Hopefully this has shed some more light on how Objective-C and C# are really not all that different if you can apply a little bit of translation in your head while reading/writing code. If you live near Jacksonville, I hope you’ll come out to my presentation on iPhone Development with a Windows Azure-hosted API at JaxDUG on June 6th.

Please give me feedback on these posts in the comments. Thanks!

Translating Objective-C to C# – Part 1 of n

2012-05-22T17:33:00.001-04:00

As I mentioned in the previous post, I’m copresenting at JaxDUG in June on iPhone Development using a Windows Azure-hosted REST API. Before last week, I knew little about Objective-C or Cocoa. I still know very little – but I gained a wealth of knowledge by sitting down with my copresenter Mike Glass for about half an hour and he explained some of the concepts for me and it finally clicked. So I’ve spent the past 2 days reading through Programming iOS 5, Second Edition by Matt Neuberg to familiarize myself with the concepts.

While reading, I found that it was helpful to try and equate the concepts to C# equivalents. I figured that it might be helpful to others as well if I put these comparisons into blog form and shared them to the world. Hopefully this will encourage iOS and Mac developers to take a look at Windows Phone and Windows 8 development in C#. As I’m still learning, I’d appreciate any feedback you might have, and definitely let me know if I’ve said something wrong.

I’ll be using the examples in the eBook as the source, in the order they appear (but not using every example, of course).

Enums

In Chapter 1, he shows a common C enum type defined in Cocoa:

typedef enum {
UIStatusBarAnimationNone,
UIStatusBarAnimationFade,
UIStatusBarAnimationSlide,
} UIStatusBarAnimation;

This is easily convertible to a C# enum:

public enum UIStatusBarAnimation
{
    UIStatusBarAnimationNone,
    UIStatusBarAnimationFade,
    UIStatusBarAnimationSlide
}

Structs

Just like enums, the C-style structs are easy to convert to C# structs.

struct CGPoint {
CGFloat x;
CGFloat y;
};
typedef struct CGPoint CGPoint;

And in C#:

public struct CGPoint
{
public CGFloat x;
public CGFloat y;
}

Strings

Strings in Objective-C are treated very similarly to C#, in that the resulting type of a string literal is an actual reference-type class instance.

NSString* s = @"Hello, world!";

In C#, there is no @ delimiter for the start of the string, and the pointers are implicitly managed by the runtime, so there’s no need to be explicit with the * identifier. The NSString type is analogous to System.String.

string s = "Hello, world!";

For Each

Objective-C has an equivalent to C#’s foreach statement, using the more concise “for” and “in” keywords:

for (SomeType* oneItem in myCollection) {
// ... statements ....
}

Again, the pointers are implicitly managed, but this is easily done in C# using foreach:

foreach (SomeType oneItem in myCollection)
{
// ... statements ...
}

Instance vs Static Methods/Messages

In Objective-C, any time you see a statement in square brackets, that is called passing a message to an object, which is roughly equivalent to calling a method in C#. The first part inside the brackets is the object to pass the message to, followed by the “selector” (or method signature) and their parameters. Each parameter follows a colon, which makes the code more readable than C# in some cases.

In the interface definition for a type (more on that later), or in Apple’s documentation, you will see instance methods defined with a minus sign (“-“) and class (or “static” in C#) methods defined with a plus sign (“+”). So the following method is defined as an instance method:

- (NSString *)stringByAppendingString:(NSString *)aString

While this method is defined as a static method:

+ (id)stringWithContentsOfFile:(NSString *)path
encoding:(NSStringEncoding)enc
error:(NSError **)error

The C# equivalent signatures would be (replacing types with those found in the .NET BCL):

public string StringByAppendingString(string aString)
{
// ...
}

public static object StringWithContentsOfFile(string path, Encoding enc, ref Exception error)
{
// ...
}

More on id vs object later. Notice that a “pointer pointer” to a reference type is roughly equivalent to the “ref” keyword on a parameter. And clearly, there are static BCL equivalents of these methods in String.Concat(string, string) and File.ReadAllText(string, Encoding) wrapped in a try/catch block.

To call an instance method in Objective-C, you use an object instance as the first part inside the square brackets:

NSString* s1 = @"Hello, ";
NSString* s2 = @"World!"
NSString* s3 = [s1 stringByAppendingString: s2];

If the System.String type had a StringByAppendingString method like NSString (rather than the static String.Concat), the previous code would look like this in C#:

string s1 = "Hello, ";
string s2 = "World!";
string s3 = s1.StringByAppendingString(s2);

Just like the s1 instance was specified inside the square brackets to make it an instance method call, you can specify the type name instead to make it a static method call. This is almost exactly like C#, where you use the Type identifier before the dot instead of the instance. Here’s a static method call in Objective-C:

NSString* myPath = // something or other;
NSStringEncoding myEnc = // something or other;
NSError* myError = nil;
NSString* result = [NSString stringWithContentsOfFile: myPath
encoding: myEnc
error: &myError];

We can create our own .NET version of NSString’s stringWithContentsOfFile as follows:

public static class StringEx
{
    public static string StringWithContentsOfFile(string path, Encoding encoding, ref Exception error)
    {
        try
        {
            return System.IO.File.ReadAllText(path, encoding);
        }
        catch (Exception ex)
        {
            error = ex;
            return null;
        }
    }
}

And now that we have a Cocoa equivalent, we can call it like this:

string myPath = "something or other";
Encoding myEnc = Encoding.UTF8;
Exception myError = null;

string result = StringEx.StringWithContentsOfFile(myPath, encoding: myEnc, error: ref myError);

Also notice that nil in Objective-C is roughly equivalent to null in C#, and that in this example we are giving our code a very Objective-C feel by using named parameters with colons.

Nesting Method Calls

One thing that threw me off when I started looking at Objective-C is following the trail of nested method calls. Since the first part of a method call is what the message is being sent to, you can use the result of a message as the first part of another message call. In Chapter 3 he uses the following example:

NSArray* arr = [[MPMediaQuery albumsQuery] collections];

And he points out that this is equivalent to the following code:

MPMediaQuery* query = [MPMediaQuery albumsQuery];
NSArray* arr = [query collections];

A C# (or any C-style language) developer should be able to easily see that the first version is equivalent to this (although in reality, Array would be replaced with some generic collection):

Array arr = MPMediaQuery.albumsQuery().collections();

Also notice that this is a mix of a static/class and instance method call in both cases, but either example could be made from 2 nested instance method calls without a change in syntax (other than using the instance identifier rather than MPMediaQuery).

Parameter Lists

For methods with a variable number of parameters, Objective-C offers parameter lists, which is equivalent to C#’s params keyword. From the examples in the book, on the NSArray class there is a class (static) method with the following signature:

+ (id)arrayWithObjects:(id)firstObj, ... ;

The … is the syntax for denoting that the method can receive a variable number of arguments. He then uses this method like so:

NSArray* pep = [NSArray arrayWithObjects:@"Manny", @"Moe", @"Jack", nil];

He points out in the book that the nil terminator is required, and you will get a compiler warning if you forget it. In C#, the NSArray method is equivalent to the following method:

public static Array ArrayWithObjects(params object[] objects)
{
return objects;
}

Since the C# compiler automatically converts variable length arguments into an array instance, this method has a trivial implementation. It can then be called like so (from within the same type), and a nil terminator is not required:

Array pep = ArrayWithObjects("Manny", "Moe", "Jack");

ID vs Object

This one is a bit tricky. Objective-C has an id keyword which can be used instead of a type identifier to declare a variable or parameter as accepting a pointer to any type of object ever. In C#, you might think this would be equivalent to declaring a variable of the object type. However, my CoWork Jax coworker Mike Glass pointed out that Cocoa also has an equivalent of System.Object, which is NSObject – and all classes that inherit the default allocation and initialization behavior of objects should inherit from it. So if declaring a variable of type System.Object in C# is equivalent to declaring a variable of type NSObject in Objective-C, then what is the .NET equivalent of declaring a variable as id?

It seems to me like there is no direct equivalent. On one hand, id allows you to send messages to that instance that are checked at runtime rather than compile time. So the following code is not statically checked by the compiler, and may crash at runtime:

NSString* s = @"Hello, world!";
id unknown = s;
[unknown rockTheCasbah];

In that sense, you can see where id is not like System.Object, because trying to call rockTheCasbah on a System.Object variable would definitely throw a compiler error. So that makes id behave much like C# 4’s dynamic keyword – it can contain a reference to any object, and method calls at runtime are not statically checked by the compiler.

However, id in Objective-C also behaves much like the IntPtr type which in .NET refers to an unmanaged memory pointer. I would chalk this up to the difference between Objective-C being an unmanaged language and .NET being a managed language though, and leave the rest of this discussion for one to be had over beers. Bottom line – id seems to be most equivalent to C#’s dynamic keyword (but without the expensive DLR overhead), and NSObject is equivalent to System.Object; but in a true Objective-C to C# conversion you would probably use System.Object for id rather than dynamic.

Blocks

Blocks in Objective-C are very easily translatable to lambda expressions in C#. A Block, just like a lambda expression, is an anonymous method that has a special syntax, can be stored to a variable inside another method or passed as a parameter to another method, has a strongly typed parameter list, and has an implicitly typed return type. Blocks in Objective-C are declared by starting the block with the caret (^) symbol. In the example in the book, it is passed as a parameter to NSArray’s sortedArrayUsingComparator method (the block portion is in bold with a gray background):

NSArray* arr2 = [arr sortedArrayUsingComparator: ^(id obj1, id obj2) {
NSString* s1 = (NSString*) obj1;
NSString* s2 = (NSString*) obj2;
NSString* string1end = [s1 substringFromIndex:[s1 length] - 1];
NSString* string2end = [s2 substringFromIndex:[s2 length] - 1];
return [string1end compare:string2end];
}];

Compare that to the following lambda expression equivalent, assuming there was an instance or extension method on System.Array called SortedArrayUsingComparator (and the comparator parameter could be the delegate Comparison<object>, which takes 2 object types and returns an int):

Array arr2 = arr.SortedArrayUsingComparator((obj1, obj2) =>
{
    string s1 = (string)obj1;
    string s2 = (string)obj2;
    string string1end = s1.Substring(s1.Length - 1);
    string string2end = s2.Substring(s2.Length - 1);
    return string.Compare(string1end, string2end);
});

This example shows that Blocks and C# lambdas are extremely similar, and have very similar syntax and usage. Note that I’ve used the static string.Compare method rather than NSString’s instance compare method as in the original example. Also, the original example is implicitly returning NSComparisonResult rather than int, but with similar results.

Summary

I hope this shows how you can translate some Objective-C to and from C#. I’m still learning this myself, so please give me any feedback you can. Also, make sure you pick up a copy of Programming iOS 5 which these examples came from – it’s an excellent read!

Next time I hope to cover interfaces vs. implementations, type checking, inheritance, alloc-init, polymorphism, self/this and super/base keywords, properties, and initializers from Chapters 4-5.

I’m Speaking at JaxDUG! June 6th, 2012

2012-05-22T09:53:00.001-04:00

2012 is all about a reboot of my professional life. I’ve changed jobs, I’ve finally put up a new blog post, and now I’m finally speaking at a developer group again!

This time it’s at the monthly JaxDUG meeting, happening Wednesday, June 6th, 2012 from 6:00 pm to 8:00 pm at the LPS building auditorium, ground floor.

TL;DR Version: register for the JaxDUG meeting and I’ll see you there!

(By the way, if you haven’t checked out the new JaxDUG website, do so now! It looks great, and it’s developed by our community, so hopefully it will grow and thrive into an awesome resource. At the time of this writing, though, they still do not have the June meeting listed on the site.)

The most exciting thing about this meeting is that I’m not the only one speaking – I’ll be copresenting with Mike Glass, who works out of CoWork Jax downtown where I work a few days a week. Mike is a Mac and iOS developer who writes probably the cleanest and most readable Objective-C code I’ve ever seen. His company, Pocket Sevens, has produced some really awesome apps.

Our topic will be iPhone App Development using an Azure REST API. Mike will demonstrate how to use the new Storyboard feature in XCode/iOS 5 to easily create a 3-screen iPhone app that will load data from a REST API hosted in Windows Azure. Then, I’ll be demonstrating how to use ASP.NET MVC 4’s Web API feature to easily create a REST API that supports XML as well as JSON, and how to host that in Azure. I’ll then hand it back to Mike and he’ll tie everything together and deploy the app to the emulator. He’ll also explain some Objective-C concepts (that I had to have him explain to me!) like delegates (not the same as .NET delegates!), property synthesizing (roughly analogous to automatic properties in .NET), and how the controllers interact with the views when you use Storyboards. We also might have a few surprises in store!

The app that we’ll be creating will be a directory of Coworking locations, sorted based on proximity to your current position. It will take your current GPS position, send it to the REST API and get back a list of coworking spaces, and bind that list to a table view, and when a record in the table is selected, it will show a detail view with a map for that entry.

(If you’re not familiar with Coworking, it’s a new trend of common, shared office space where workers from many different businesses work out of the same space, collaborate, and network. I’ve been working out of CoWork Jax since mid-April, and I love it! It’s great to meet and talk with people that work for other companies, and you can help each other out with problems you might have.)

To register for the meeting, sign up for free at Eventbrite. There’s no need to print your ticket.

Hope to see you there!

Working with SalesForce.com – Observations and Frustrations

2012-05-11T15:09:00.001-04:00

As I mentioned in Yet Another Adventure, I started work at a new company in April – Potts Consulting Group. It’s been a wild ride leaving Fanatics and getting acquainted with consulting! I love every minute of it, and it was a great breath of fresh air changing jobs.

My first client job was a SalesForce.com integration. The client had domain-specific data that needed to be transformed into SalesForce.com (hereafter referred to in shorthand as SFDC) opportunities, accounts, and contacts. This integration is in its final phases now, and along the way I learned some very cool and very frustrating things about working with the SFDC APIs.

(Note: For the rest of this article, I will assume you have some familiarity with SFDC’s various APIs. You may have come across this post via searching for answers on a search engine, and if so, hopefully I can shed some light on the many “gotchas” you will encounter.)

SFDC has a few APIs to use for loading data, including the SOAP Web Services API, the Bulk API, and the Data Loader application, which uses either the SOAP or Bulk API through a command-line interface. The Data Loader also has a GUI, but that is not helpful for scheduled loading of data – but it turned out to be very valuable when debugging issues with the CLI version.

I initially looked at the SOAP API, thinking it would be the easiest to integrate with a .NET application. That turned out to be far from the truth – adding a service reference to their SOAP endpoint worked, but when the code was executed I could not get past XML deserialization errors. After a little bit of trial and error, I decided to pursue the Bulk API.

The bulk API was more what I was looking for, but required a good deal of manual work for mapping. Since the Data Loader can use the bulk API and handles the mapping for you, I eventually ended up on the decision to use the CLI version of the Data Loader.

I created a Windows Service application that, based on a schedule or manual invocation, will pass to the Data Loader the information needed to load the data into SFDC. This was invoked by using the System.Diagnostics.Process class.

The Data Loader is a Java application that can load data either from CSV files or from a database query. Since my source data was already in SQL Server 2008, I decided to use the database query approach rather than CSV. This brings us to the first frustration.

The SQL Server JDBC Driver

In order to have the database queries from the Data Loader access Microsoft SQL Server, you must use the SQL Server JDBC driver (and if you’re using SQL Server 2012, make sure you get the 4.0 version). However, this is not as easy as it appears – the driver is a .jar file that must be “included” when the Data Loader is run. To do so, you must manually modify the process.bat file in the Data Loader /bin/ folder to include the JDBC driver. I placed the SQL Server JDBC Driver .jar file in the /Java/lib/ folder so it was alongside the other .jar files.

I modified the process.bat line that executes Java to look like the following (I also put absolute file paths there that weren’t there before):

"C:\Program Files (x86)\salesforce.com\Data Loader\Java\bin\java.exe" -cp "C:\Program Files (x86)\salesforce.com\Data Loader\Java\lib\sqljdbc4.jar;C:\Program Files (x86)\salesforce.com\Data Loader\dataloader-24.0.0-jar-with-dependencies.jar" -Dsalesforce.config.dir=%1 com.salesforce.dataloader.process.ProcessRunner %PROCESS_OPTION%

Once the JDBC driver is included in the .bat file, you can modify your connection in the database-conf.xml file to look like the following:

<bean id="dbDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.microsoft.sqlserver.jdbc.SQLServerDriver"/>
<property name="url" value="jdbc:sqlserver://{server};database={database}"/>
<property name="username" value="{username}"/>
<property name="password" value="{password}"/>
</bean>

And replace {server}, {database}, {username}, and {password} with the values that are correct for your database server.

Passing Custom Parameters to SQL

One thing that isn’t well documented in the Data Loader documentation is that you can pass custom parameters to your SQL query through the command line. All you have to do is add on the variables after the %PROCESS_OPTION%. Say you had a variable called CustomerID and you wanted to pass the customer ID value in through the command line as the third argument (after process name). You could add the following to the .bat line above after %PROCESS_OPTION%:

CustomerID=%3

Then you can specify a parameter in your database-conf.xml file’s query, for example:

SELECT {fields here} FROM Customers WHERE CustomerID = @CustomerID@

Just make sure you add the CustomerID parameter in the sqlParams bean property:

<property name="sqlParams">
          <map>
            <entry key="CustomerID" value="java.lang.String"/>
          </map>
      </property>

Now you can execute your process.bat like this:

process.bat ../configs/myconfig myLoadOperation 123

And the value 123 will be inserted into your database query as the @CustomerID@ parameter.

Exponential Notation

If you are trying to load a number into a Number type field in SFDC, make sure the number will never exceed 10 million. After 10 million, the number values are sent in exponential notation and you will get an error. I was trying to load an integer identity column value into a Number type ExternalID field, and once the IDs reached 10 million I received errors. While not the most elegant solution, I had to get around this problem by making the ExternalID field a Text type instead and cast the int as a string in the database query.

No Default External ID field

As you may know, objects in SFDC have their own internal ID. In order to match a SFDC object to one in your database, you must store your ID in the SFDC object. Unfortunately there’s no default External ID field created for you, so you must create one for every object. Like in the past section, I recommend using the Text type as it will save you much frustration.

DatabaseWrite and Stored Procedures

One cool thing I discovered is that you can execute stored procedures for databaseWrite operations, which gives you greater flexibility by being able to have complex code inside a T-SQL stored procedure rather than your database-conf.xml file. This combined with the ability to pass in parameters from the command line makes for very powerful extractions of data from SFDC into your SQL database.

5MB Developer Account Restriction

An annoyance I discovered is that the free Developer account only allots you 5 MB of data usage. After loading a few thousand records I hit this limit very quickly, and once you hit it, you can not load any data before you delete something else to free up space. 5 MB is not nearly enough to exhaustively test an integration, so you can only really use your developer account for testing a small number of records to make sure the mapping is correct. I hope they increase this limit in the future.

Cannot Delete Opportunities In Bulk

Under the Setup section of the site, you can bulk delete accounts and contacts. However, for some reason, you can not bulk delete opportunities. When testing data loading, you need to repeatedly load bulk data then delete all that data so you can test again. But since there’s no easy way to delete opportunities in bulk on the site, you have to bulk delete them using the GUI version of Data Loader (or, I guess you really could use the CLI version, but that’d be painful) by extracting all the opportunities to CSV then performing a bulk delete with that extracted CSV so it knows which IDs to delete. Very frustrating for testing by trial and error (which, since SFDC mappings can be very flaky, is a common strategy)!

Null, Empty String, and Overwrites

If you pass NULL to a field mapping on an object that already has a value in that field, it will not overwrite the value. This is helpful if you want to run the integration multiple times with different columns each time. I was pleased that this was the case. However, I was surprised to also find that passing empty string (“”) to a Text field will not overwrite the value, either. So if a value is present at one point in time but you want to blank it out, you can not easily do that as far as I can tell using the Data Loader and the databaseRead operation. You could replace it with space (“ “), but that’s an inelegant solution. I would have preferred if NULL did not overwrite but empty string did overwrite the value.

Field Names in Mapping Files are Case Sensitive

When creating a .sdl mapping file, ensure that you log in to the Setup section of the site and view the API field names for the object you’re loading, and make sure the casing of the field name on the SFDC side is correct, as they are case sensitive. Despite them being case-sensitive on input, the Data Loader GUI application exports field names as all upper case. Go figure.

Well, that sums up my observations and frustrations with SalesForce.com. Hopefully my trials and aggravations have resulted in helpful information for someone else, as there is a lack of good information online about how to effectively use Data Loader for real world automation of SFDC imports.

Yet Another Adventure

2012-03-06T10:19:00.002-05:00

I am exceptionally embarrassed that I only made one (ONE!) post in all of 2011. I sincerely apologize for that. I am not going to make another empty promise that I'll post more, but perhaps I'll make a declaration of my intention to post more in 2012.

But I'm writing today to announce that I'm starting yet another adventure, not unlike my post from August 13, 2009 titled Jacksonville, Here I Come!. I have just accepted a new position at a small consulting company in St. Augustine, and I will be leaving my position at Fanatics on Friday, March 23, 2012. It's been a crazy two and a half years, which has given me experience with a highly scalable e-commerce application on two different platforms (one ASP.NET WebForms, the other ASP.NET MVC), as well as a wealth of additional experience in areas like web analytics, multivariant testing, performance testing, WCF and AppFabric, MSMQ, jQuery and AJAX, algorithms, metaprogramming, database tuning and advanced querying, and many, many more. I'm extremely grateful for the opportunity to make software solutions to keep up with the company's rapid growth and I will always look back on this position with good memories.

I'm excited about the new position, and looking forward to using this new experience (and gaining even more) working on a wide variety of projects. Catch you on the flip side!

Mocking Static Methods for Unit Testing

2011-03-15T19:13:00.001-04:00

As you probably know, unit tests are supposed to be fast, lightweight tests of your code logic. They are not supposed to do any disk I/O, network communication, or long-running CPU calculations. If you have cleanly decoupled code that doesn’t call any static methods and everything is programmed to the interface, you can mock the intensive operations very easily.

Although if you’ve tried unit testing a class that calls static methods that perform such intensive operations, you quickly realize that you must separate them out from your code so that they can be mocked. But if the methods are in a library you can’t modify, you usually end up very frustrated. There are a few easy ways to mock static methods, and you can choose which option works best for your needs.

Background

In our example, we have a class that has a single static method. Let’s pretend that this does some intensive activity that you don’t want to do while running your unit test suite. This class is in a library that you can’t modify and make non-static – we’re just looking at the code here as an example.

namespace SomeLibraryYouCantModify
{
    public static class SomeStaticClass
    {
        public static bool SomeStaticMethod(string input)
        {
            // Let's pretend this method hits a database or service.
            return !string.IsNullOrEmpty(input);
        }
    }
}

So we have one method that takes a string and returns bool. Keep this in mind.

Now, here’s an example of the static method being used. Note that we can not (by default) mock the static call – it’s a tight coupling that can not be easily broken.

namespace SomeLibraryYouCanModify
{
    public class SomeUntestableClass
    {
        public int SomeMethod(string input)
        {
            var value = SomeStaticClass.SomeStaticMethod(input);

            return value ? 1 : 0;
        }
    }
}

Below you will find a variety of options to make this class unit testable without the static call.

Option 1 – Wrapper Class

The first option which is extremely easy to do and very Inversion-of-Control-friendly is to make a wrapper class that has the exact same signature as the static methods you’re needing to call, but the only difference is that they are non-static. Each of these methods calls the static version and returns the value (if not void). Then, you can extract an interface to use for wiring up with IoC and mocking (such as with Moq).

In this example, we take the same signature as our static class above, but create a non-static wrapper class.

namespace SomeLibraryYouCanModify
{
    public class StaticWrapper : IStaticWrapper
    {
        public bool SomeStaticMethod(string input)
        {
            return SomeStaticClass.SomeStaticMethod(input);
        }
    }
}

With our static wrapper in place, we now extract an interface:

namespace SomeLibraryYouCanModify
{
    public interface IStaticWrapper
    {
        bool SomeStaticMethod(string input);
    }
}

Perfect. Now we have a non-static wrapper class to our static methods that can be mocked. Here’s how to use it in the caller class:

namespace SomeLibraryYouCanModify
{
    public class WrapperMethod
    {
        IStaticWrapper _wrapper;

        public WrapperMethod(IStaticWrapper wrapper)
        {
            _wrapper = wrapper;
        }

        public int SomeMethod(string input)
        {
            var value = _wrapper.SomeStaticMethod(input);

            return value ? 1 : 0;
        }
    }
}

This class uses constructor injection, but you can do any Inversion-of-Control style you prefer (property injection, etc.). The main point is that we now have a hook where we can insert a mocked wrapper that does not call the static method. Here’s how our test class might look:

    [TestClass]
    public class WrapperMethodTests
    {
        private class TestWrapper : IStaticWrapper
        {
            public bool SomeStaticMethod(string input)
            {
                return !string.IsNullOrEmpty(input);
            }
        }

        [TestMethod]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var wrapper = new TestWrapper();

            var wm = new WrapperMethod(wrapper);

            var output = wm.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }

Notice how the TestWrapper is a private class just used for unit testing, and it does not do any time or I/O intensive operations. This allows our unit tests to execute quickly, providing quick turn-around when things break.

You could also use a mocking framework like Moq to create a mocked IStaticWrapper in the test example above.

Option 2 – Delegates

If the amount of static operations you’re trying to mock is small, say one or two method calls, you may want to go the delegate route. In this approach, you take optional delegates into the constructor so that by default the class calls the static method, but in your unit tests you can specify a custom delegate (such as a lambda method) that is called instead.

Here’s our caller class using the delegate method:

namespace SomeLibraryYouCanModify
{
    public class DelegateMethod
    {
        Func<string, bool> _delegate;

        public DelegateMethod()
        {
            _delegate = SomeStaticClass.SomeStaticMethod;
        }

        public DelegateMethod(Func<string, bool> method)
        {
            _delegate = method;
        }

        public int SomeMethod(string input)
        {
            var value = _delegate(input);

            return value ? 1 : 0;
        }
    }
}

If you aren’t familiar with generic delegates, Func<T, TResult> used above is a delegate for a method that takes a parameter of type T and returns a result of type TResult. So now our class, by default, sets the private delegate field to the static method, but in our unit tests we can specify a custom method instead. Here’s a unit test using this approach that passes a lambda into the constructor:

    [TestClass]
    public class DelegateMethodTests
    {
        [TestMethod]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var dm = new DelegateMethod(i => !string.IsNullOrEmpty(i));

            var output = dm.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }

We get the same result as the wrapper method – the test executes quickly, does not call the static method, and we can verify that the logic inside SomeMethod is correct.

Option 3 – Moles

Moles is an isolation framework from Microsoft that allows you to mock static method calls without rewriting any implementation code. You can even mock calls to .NET framework methods and properties, like DateTime.Now. The benefits are easy to write unit tests and less refactoring time, although at the expense of maintaining tightly-coupled code. Another drawback of Moles I’ve experienced is that it does not work well in a team environment with Team Foundation Server, because it creates proxy DLLs that are hosted in your unit test project, and multiple users checking out and checking in these DLLs becomes a pain very quickly, especially since the default checkout action is an exclusive lock. However, if you’re a sole developer working on a project, it is a worthwhile choice.

You can download Moles (with or without Pex) from Microsoft Research’s Moles Project site. Make sure that you download the correct version for your CPU (x86 vs x64).

After installing, you can right click the reference to the library you’d like to mole in your unit test project, and select Add Moles Assembly.

Now that a Moles assembly has been added to the project, you can now create a unit test and mock that call. You must make sure to import the “.Moles” version of the namespace as seen in the example below. All types in the assembly that can be mocked begin with the letter “M”, and for static methods, the method becomes a property (named with the method name followed by all of the parameter types) that is of a delegate type. Then you can “set” that property to a new delegate, such as a lambda in the example below:

using SomeLibraryYouCantModify.Moles;

namespace LibraryTestProject
{
    [TestClass]
    public class MoledTests
    {
        [TestMethod]
        [HostType("Moles")]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var c = new SomeUntestableClass();

            MSomeStaticClass.SomeStaticMethodString = i => !string.IsNullOrEmpty(i);

            var output = c.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }
}

I’ve bolded the interesting lines. First, you have to import the “.Moles” namespace, as I mentioned earlier. Second, you must add the HostType(“Moles”) to any methods that are to be run in the Moles host. If a test method is not run in the Moles host, it will not be able to use the Moled type, and will let you know with an exception. Finally, the “SomeStaticClass” has a moled “MSomeStaticClass” that provides the mockable methods. The “SomeStaticMethod” method becomes “SomeStaticMethodString”, with the String being added to the name to represent the type of the first and only parameter to the method. This allows for method overloading, as different parameter types will cause different property names on the moled type. Then, the property is set to the given lambda, which is identical to the Delegates example above.

Conclusion

Out of the three methods, I end up preferring the Wrapper method the most, because it is easy to use with IoC containers and Moq. However, it is probably the most amount of work, because you have to create 2 new types, one for the wrapper class and the other for the interface. Also, it means that you have an entire type that has zero coverage, because you can not write unit tests for this wrapper class as it would call the static method.

The delegate method is great for one or two method isolation, as it’s easy to do, doesn’t need to involve the IoC container, and can be easily mocked with constructor overloads. However, it’s the least intuitive code to read, and is clunky to use for more than two method calls.

The Moles method is certainly clever and very impressive on first use. It works great for small projects with one developer, and can allow you to achieve greater code coverage very quickly. However, it is slower to start the unit test run due to the Moles host, it doesn’t help you decouple your code, and it is a pain for multiple developers working on the same project due to source control conflicts.

Obviously, the ideal situation is to have a non-static method to call. If you can get the developer of the library to do it for you, they can create a non-static version of the type/methods that are called by the static version, so that their existing static API is maintained and you get the benefit of being able to wire up the dependency with dependency injection. Clearly, though, this isn’t always possible.

Hope this helps!

ObservableStack

2010-12-27T09:45:00.001-05:00

I had been looking around in the .NET framework for a Stack<T> equivalent of ObservableCollection<T> to use in a WPF application. Couldn’t find one, so I implemented one based on those two classes. Hope this helps!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections.Specialized;
using System.ComponentModel;
using System.Collections;

namespace AdventuresDotNet
{
    public class ObservableStack<T> : IEnumerable<T>, ICollection, INotifyCollectionChanged, INotifyPropertyChanged
    {
        T[] _array;
        const int _defaultCapacity = 4;
        static T[] _emptyArray;
        int _size;
        object _syncRoot;
        int _version;

        static ObservableStack()
        {
            _emptyArray = new T[0];
        }

        public ObservableStack()
        {
            _array = _emptyArray;
            _size = 0;
            _version = 0;
            _syncRoot = new object();
        }

        public ObservableStack(IEnumerable<T> collection)
        {
            if (collection == null)
                throw new ArgumentNullException("collection");

            var is2 = collection as ICollection<T>;

            if (is2 != null)
            {
                int count = is2.Count;
                _array = new T[count];
                is2.CopyTo(_array, 0);
                _size = count;
            }
            else
            {
                _size = 0;
                _array = new T[4];
                using (var enumerator = collection.GetEnumerator())
                {
                    while (enumerator.MoveNext())
                    {
                        this.Push(enumerator.Current);
                    }
                }
            }
        }

        public ObservableStack(int capacity)
        {
            if (capacity < 0)
                throw new ArgumentException("Invalid capacity.");

            _array = new T[capacity];
            _size = 0;
            _version = 0;
        }

        public void Push(T item)
        {
            if (_size == _array.Length)
            {
                T[] dest = new T[(_array.Length == 0) ? 4 : (2 * _array.Length)];
                Array.Copy(_array, 0, dest, 0, _size);
                _array = dest;
            }

            _array[_size++] = item;
            _version++;

            OnCollectionAdded(item);
            OnPropertyChanged("Count");
        }

        public T Pop()
        {
            if (_size == 0)
                throw new InvalidOperationException("Empty stack, can not pop.");

            _version++;
            T local = _array[--_size];
            _array[_size] = default(T);

            OnCollectionRemoved(local, _size);
            OnPropertyChanged("Count");

            return local;
        }

        public T Peek()
        {
            if (_size == 0)
                throw new InvalidOperationException("Empty stack, can not peek.");

            return _array[_size - 1];
        }

        public event NotifyCollectionChangedEventHandler CollectionChanged;

        public event PropertyChangedEventHandler PropertyChanged;

        void OnCollectionReset()
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));
        }

        void OnCollectionAdded(object item)
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add, item));
        }

        void OnCollectionRemoved(object item, int index)
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, item, index));
        }

        void OnPropertyChanged(string propertyName)
        {
            var p = PropertyChanged;

            if (p != null)
                p(this, new PropertyChangedEventArgs(propertyName));
        }



        public IEnumerator<T> GetEnumerator()
        {
            return new Enumerator(this);
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
        {
            return new Enumerator(this);
        }
        
        public void Clear()
        {
            Array.Clear(_array, 0, _size);
            _size = 0;
            _version++;

            OnCollectionReset();
            OnPropertyChanged("Count");
        }

        public bool Contains(T item)
        {
            int index = _size;

            var comparer = EqualityComparer<T>.Default;

            while (index-- > 0)
            {
                if (item == null)
                {
                    if (_array[index] == null)
                        return true;
                }
                else if (_array[index] != null && comparer.Equals(_array[index], item))
                {
                    return true;
                }
            }

            return false;
        }

        public void CopyTo(T[] array, int arrayIndex)
        {
            if (array == null)
                throw new ArgumentNullException("array");

            if (arrayIndex < 0 || arrayIndex > array.Length)
                throw new ArgumentOutOfRangeException("arrayIndex");

            if ((array.Length - arrayIndex) < _size)
                throw new ArgumentException();

            Array.Copy(_array, 0, array, arrayIndex, _size);
            Array.Reverse(array, arrayIndex, _size);
        }

        public int Count
        {
            get { return _size; }
        }
        
        public bool IsSynchronized
        {
            get { return false; }
        }

        public object SyncRoot
        {
            get { return _syncRoot; }
        }

        void ICollection.CopyTo(Array array, int index)
        {
            Array.Copy(this._array, 0, array, index, this._size);
            Array.Reverse(array, index, this._size);
        }

        public struct Enumerator : IEnumerator<T>, IDisposable, IEnumerator
        {
            ObservableStack<T> _stack;
            int _index;
            int _version;
            T currentElement;

            internal Enumerator(ObservableStack<T> stack)
            {
                _stack = stack;
                _version = _stack._version;
                _index = -2;
                currentElement = default(T);
            }

            public T Current
            {
                get
                {
                    if (_index < 0)
                        throw new InvalidOperationException();

                    return currentElement;
                }
            }

            public void Dispose()
            {
                _index = -1;
            }

            object IEnumerator.Current
            {
                get
                {
                    if (_index < 0)
                        throw new InvalidOperationException();

                    return currentElement;
                }
            }

            public bool MoveNext()
            {
                bool flag;

                if (_version != _stack._version)
                    throw new InvalidOperationException("Version mismatch.");

                if (_index == -2)
                {
                    _index = _stack._size - 1;
                    flag = _index >= 0;

                    if (flag)
                        currentElement = _stack._array[_index];

                    return flag;
                }

                if (_index == -1)
                    return false;

                flag = --_index >= 0;

                if (flag)
                {
                    currentElement = _stack._array[_index];
                    return flag;
                }

                currentElement = default(T);
                return flag;
            }

            public void Reset()
            {
                if (_version != _stack._version)
                    throw new InvalidOperationException("Version mismatch.");

                _index = -2;
                currentElement = default(T);
            }
        }
    }
}

HttpContext.Current and Threads with QueueUserWorkItem

2010-10-04T14:51:00.003-04:00

If you’ve got an ASP.NET (including MVC) application that uses ThreadPool.QueueUserWorkItem with a reset event or anything of the like, you can not access HttpContext.Current (or rather, it is null) on those threads. This makes exception logging difficult, especially if you want to log the URL that is currently being requested.

After a little digging, I discovered that the current HttpContext is actually in thread-local storage, which explains why child threads don’t have access to it. Luckily, you can pass a reference to it in your child thread. Include a reference to HttpContext in the “state” object of your callback method, and then you can store it to HttpContext.Current on that thread. If you notice, HttpContext.Current is not a read-only property – it has a setter as well. Set HttpContext.Current = myStateObj.HttpContextReference where myStateObj is your state object.

I feel like this post is a bit self-explanatory, but here’s an obligatory example if you don’t follow:

private AutoResetEvent s_reset = new AutoResetEvent(false);

protected void Page_Load(object sender, EventArgs e)
{
    var state = new WorkerState() { HttpContextReference = HttpContext.Current };
    ThreadPool.QueueUserWorkItem(new WaitCallback(Worker), state);

    try
    {
        s_reset.WaitOne();
    }
    finally
    {
        s_reset.Close();
    }
}

void Worker(object state)
{
    var mystate = state as WorkerState;

    if (mystate != null && mystate.HttpContextReference != null)
    {
        HttpContext.Current = mystate.HttpContextReference;
    }

    HttpContext.Current.Response.Write("Threading!");

    s_reset.Set();
}

private class WorkerState
{
    public HttpContext HttpContextReference { get; set; }
}

And, of course, it works:

Hope this helps!

Combining and Abusing Delegates

2010-09-20T14:00:00.002-04:00

I had never before thought much about combining delegates until I came across some code that combined them using lambdas, and it got me thinking about other ways to use them. Consider the following example. Note: crazy code ahead!

public class Programmer
{
    Action<string> a;

    public Programmer(string name)
    {
        this.Name = name;
    }

    public string Name { get; set; }

    public bool ShouldDesign
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should design " + s); };
        }
    }

    public bool ShouldDevelop
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should develop " + s); };
        }
    }

    public bool ShouldDeploy
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should deploy " + s); };
        }
    }

    public void Work(string programName)
    {
        a(programName);
    }
}

And then used in a console app like this:

static void Main(string[] args)
{
    var paul = new Programmer("Paul");
    paul.ShouldDesign = true;
    paul.ShouldDevelop = true;
    paul.ShouldDeploy = false;

    paul.Work("my application");

    Console.ReadKey();
}

And the output…

I do not encourage the kind of code I’ve created here, but maybe this will get you thinking!

Thoughts on the Microsoft Ecosystem

2010-09-14T22:53:00.001-04:00

I had the great opportunity to touch a Windows Phone 7 device at the Jacksonville Code Camp a few weeks ago, and it sold me – I’ll likely give up my iPhone 4 for a Windows Phone 7 device when they ship this fall. The biggest selling point as a C# developer is that I can develop both data-driven apps in Silverlight and games in XNA for Windows Phone 7 in the language I use every day – C#. So that got me thinking about where else C# and the .NET platform can be used, both at work and at home.

Windows 7 client apps in WPF (with multi-touch for tablets)
Rich Internet Apps with Silverlight 4 (again with multi-touch)
Websites with ASP.NET and ASP.NET MVC
Scaffolding data-driven sites with ASP.NET Dynamic Data
Windows Phone 7 data-driven apps in Silverlight
Games for Windows Phone 7 with XNA
Games for PC with XNA
Games for Xbox 360 with XNA
Middleware real-time services with WCF
Middleware queued services with WCF, WF, and MSMQ
SQL Server integration with CLR stored procedures
Windows Media Center apps with the Media Center SDK
Embedded device apps with WPF (Windows Embedded)
Small-scale embedded devices with .NET Micro Framework (including Netduino)
Windows Home Server add-ins with the WHS SDK
Cloud apps with the Windows Azure SDK
SharePoint parts and sites
Office add-ins for Outlook, Excel, Word, and others
Surface development with the Surface SDK (which will be in our homes within a few years)
… and probably a dozen other things I’m forgetting.

That’s a huge list, and I’ve heard complaints from people that the ecosystem has gotten too big, and therefore too much to keep track of and learn. I don’t look at it that way – I view all of these varied and important areas as all using the same foundation, C# and the .NET framework. If you know C# and the framework, you can jump from one to the other with a minimal learning curve. A WPF developer can jump to Silverlight and then to Surface and then to Windows Media Center and then to Windows Phone 7 with Silverlight without much to learn. An ASP.NET developer can jump to ASP.NET MVC and to Windows Azure and to SharePoint, again with minimal learning. Compared to jumping to another framework or another language, jumping between any of these technologies is relatively painless.

It’s a great time to be a .NET developer, and the potential with all of these technologies excites me!

My First Workflow Foundation (WF) 4 App

2010-08-20T19:08:00.001-04:00

I came across a book in our company’s “library” today – Microsoft Windows Workflow Foundation, Step by Step – and I started thinking about whether or not I should try to learn WF. Frankly, I haven’t been interested so far. Being a front-end developer, I haven’t really developed many service-level applications or processes, and of the ones I’ve touched, it seems like remoting, WCF, and/or MSMQ works rather well for those tasks. However, I came across NServiceBus this past week and it got me thinking more in the mindset of a service designer, and WF piqued my interest. A good developer tries to be well-rounded and knowledgeable about other technologies, even if he or she doesn’t use them on a daily basis.

I started flipping through the first chapter of this book. I quickly realized that it’s a 3 year old book (a lifetime in software technologies) and is about .NET 3.0 – the red-headed stepchild release of .NET. WF, of course, has seen 2 revisions since, with .NET 3.5 and again with 4.0. Nonetheless, I enjoyed the first chapter, and I started to see where WF could be useful. (Despite, that is, a question I posted on twitter asking if anyone has used WF, to which I got zero responses.)

I came home, fired up my beast of a work laptop (Core i7 4core/8thread, 8GB RAM), and launched Visual Studio 2010. File – New Project. Immediately I noticed a difference from the first chapter of this book. In the .NET 3 version, you have to choose between a Sequential or State Machine workflow type and then between a console app or library, or an “activity library”, or an empty workflow project. In VS2010, you only have 2 non-library Workflow project types – WCF Workflow Service, and Workflow Console App. I chose the Workflow Console App because it more closely matched the example. Then the similarities came to a screeching halt.

I hadn’t kept up with WF, otherwise I should have known this. WF in 4.0 uses XAML to describe workflows, and the only “code” in the workflow are “expressions” in… wait for it… VB. Yes, even though I created a C# Workflow Console App, the expressions are in Visual Basic. Furthermore, the example in the book is a .cs file (not .xaml), and has an accompanying .Designer.cs file as a “code-behind”. Better still, when you create “Code” activities in the older WF, they are methods in a C# file. The only equivalent to the “Code” activity I found in WF 4 is the “InvokeMethod” activity, which can only call a method on a type not defined in the workflow.

Still, I was able to accomplish a fairly basic If/Else workflow in WF4. Here’s what it looks like:

Fairly trivial. If a “PostalCodeIsValid”, then I write a line to the console saying it’s valid, and if not, I write a line saying it’s not. Notice the VB ampersands for string concatenation in the “Text” fields.

Look at the Condition field. I’m executing a method on a “Workflow1Helper” static class I created for simplicity. That method simply returns “PostalCode.Length == 5” which is not a true postal code validation routine, but could be replaced with one. Luckily, the Workflow1Helper class is written in C#.

It seems like this is the pattern for WF4 workflows – define your workflow in XAML, and farm out your code to other types. Makes since, especially from a separation of concerns aspect, but it’s hardly similar to WF in .NET 3.0.

So where does that PostalCode field come from? You must define it as an “Argument”. If you look at the bottom of the workflow designer, you’ll see this pane:

The Arguments tab brings up this pane:

That’s where I created the PostalCode argument. You can define any type and number of arguments you want, think of them as “parameters” to your workflow when you invoke it (more on invocation later). Also note you can assign a Default Value, i.e. “New MyType()” (alas, sigh, again in VB.)

Lastly, the invocation. There’s a Program.cs file that gets created as part of the project, and it’s a standard console app entry point class. I just had to modify the invocation part to pass the PostalCode argument:

(I apologize for the code-screenshot, I am lazy and haven’t installed the PreCode plug-in yet.)

Obviously, hitting F5 will run the app, and we get a message saying it’s valid. Yay.

Now time for the dramatic conclusion. WF4 seems much more polished than WF in .NET 3 appears in the book. I love that it’s XAML (although you really don’t want to go in and modify it, it’s pretty ugly), and I love that the code is separated from the workflow logic. It’s all very professional – easy to understand, self-documenting processes, and very easy to grasp. I also created my second WF app, this time as a WCF service, and I think that’s a much more useful paradigm than a console app, especially if it’s possible to use with a MSMQ binding (which I haven’t tried).

For the negatives, I dislike the fact that a C# WF app needs to use VB expressions, because I dislike having to switch gears. I don’t mind coding in VB if I have to, but would it have killed them to allow C# expressions?

I want to read up more on WF, as well as it’s migration from 3 –> 3.5 –> 4, as well as play around more with the WCF version of it before writing another blog post on the subject.

Bottom line, fire up Visual Studio 2010 and create your first WF app and go to town. Come up with some cool real-world ways to use it, and let me know, will you?

Jax Code Camp - August 28th, 2010

2010-08-03T08:50:00.003-04:00

Last year about this time I was just in the process of moving to Jacksonville, but I made sure that despite living out of boxes, I made it to the Jax Code Camp 2009. It was a great event, tons of people (somewhere north of 600?), and had a great after party where you get valuable time socializing with the community.

This year, it's happening again, and I'm a speaker. It's on Saturday, August 28th, 2010 at the UNF campus. You can get more details at http://www.jaxcodecamp.com. Registration is free, and there's many sessions and tracks available, including one all-day session about Windows Phone 7 that you can pop in and out of.

My talk is titled "Dynamic Code with IL and Expressions" and from the IL side I'll be covering how to use DynamicMethod to create functions and methods at runtime with IL emit, as well as how to use AssemblyBuilder to create entire types and assemblies at runtime (such as creating derived "proxy" classes for aspect-oriented programming). From the Expression side, I'll show how to parse Expressions for simple key selectors to advanced LINQ providers, and how to create methods (much like you would in IL) with Expressions to do a number of common tasks.

Hope to see you there! Again, it's a free, all-day conference-style event with breakfast, lunch, and an after-party. You won't want to miss it!

A better, more type-safe, alternative to Cast()

2010-06-30T15:23:00.002-04:00

I ran into a limitation in the Cast extension method included with LINQ (Enumerable.Cast<TResult>(this IEnumerable source)), specifically that it does not allow for explicit/implicit conversion operators. The reason for this is that it is an extension method on IEnumerable, not IEnumerable<T>. Therefore the “Current” property (see previous post on IEnumerable<T>) is of type Object, and it can’t perform the cast from type A to Object to type B if there’s a conversion operator on either type.

I wrote a quick extension method to handle this:

public static IEnumerable<TDest> CastAll<TItem, TDest>(this IEnumerable<TItem> items)
{
    var p = Expression.Parameter(typeof(TItem), "i");
    var c = Expression.Convert(p, typeof(TDest));
    var ex = Expression.Lambda<Func<TItem, TDest>>(c, p).Compile();

    foreach (var item in items)
    {
        yield return ex(item);
    }
}

Basically it builds an Expression that takes TItem, performs a type-safe Convert expression to TDest, and compiles that expression to a lambda of type Func<TItem, TDest> once per call (this could be cached outside of the method), and calls this new function on each item. Now it does a direct cast from TItem to TDest, instead of the type-unsafe A to Object to B casting that Cast<T> does.

Hope this helps!

My Apologies

2010-06-10T09:33:00.001-04:00

I accidentally recently marked many valid comments as rejected when going through them (which was long overdue!). I apologize, there were some good posts there that are now lost. I was attempting to reject just one spam one but accidentally had others checked and Blogger decided I wanted to reject all of them.

Meanwhile, I recently discovered that one of my previous posts on extension methods was incorrect. I'll follow up soon (hopefully) with a corrected version.

Understanding C#’s “yield” Keyword and IEnumerable

2010-06-01T16:10:00.006-04:00

One of the interview questions I usually give candidates for .NET developer positions is around IEnumerable<T>. What is it? What pattern does it represent under the hood? How would you use it? You might be surprised to see how many candidates have no idea what it even is, yet they probably use it everyday, or at least it’s older brother, IEnumerable.

IEnumerable and IEnumerable<T> represent a sequence of items that can be iterated over (forward only), and may be lazy evaluated upon iteration. Note that I carefully didn’t use the term “collection”, rather “sequence”, because collection implies that the items are known ahead of time, before evaluation. With IEnumerable and IEnumerable<T>, you can generate objects on the fly as you iterate over the sequence if you wish.

Before we get to IEnumerable<T>, let’s look at IEnumerable. Bring back your .NET 1.1 hats, ladies and gentlemen. IEnumerable, as the “I” in the name suggests, is an interface only. It does not provide any functionality. IEnumerable only defines one method, called GetEnumerator(), that returns an IEnumerator. The purpose of separating IEnumerable and IEnumerator, I believe, is to logically separate the functions of a sequence of items as a whole, and performing the actual iteration over them.

Let’s create a class that implements IEnumerable, called OldEnumerable (since this is before generics in .NET 2.0).

public class OldEnumerable : IEnumerable
{
    public IEnumerator GetEnumerator()
    {
        return new OldEnumerator();
    }
}

Very simple, right? All we’re doing is returning an instance of OldEnumerator. Do note that an actual class that implements IEnumerable would probably be doing a lot more than this, such as providing utility functions or such. Also, a real-world implementation would probably pass some information about the sequence’s state or identity to the constructor of OldEnumerator, which is not only valid but encouraged, since interfaces can not define the required signatures of any constructors.

Now let’s look at OldEnumerator, before we look at a sample of how to use it.

public class OldEnumerator : IEnumerator
{
    int x = 0;

    public object Current
    {
        get { return x; }
    }

    public bool MoveNext()
    {
        return x++ < 100;
    }

    public void Reset()
    {
        x = 0;
    }
}

This class does one thing and one thing well – return numbers from 1 to 100. Notice that it implements the IEnumerator interface, not IEnumerable. This interface dictates the property and two methods you see above – namely the read-only property Current (note the return type of System.Object), MoveNext() which returns boolean, and Reset(). The names should be pretty self explanatory – Current returns the current item, MoveNext() tries to move to the next item (and returns false if it can not), and Reset(), which resets the enumerator to it’s (hopefully) original state.

In this example, we have a private variable x, which is simply returned by Current whenever it is requested. Note that a real-world example would probably throw an exception if MoveNext() had not yet been called. (And this is an important note: MoveNext() must be called to access the first item before Current can be called, according to the way that IEnumerable is used throughout the framework.)

Our MoveNext() method returns whether the value of x is less than 100, then increments x by 1. This allows 100 to be an inclusive maximum value of this sequence. By initializing x to 0, since MoveNext() should be called before any calls to Current, this ensures that the sequence will start at 1. Finally, the Reset() method sets x to 0, and upon the next MoveNext() call, x will start the sequence over again at 1.

So let’s look at an example of how to use our new OldEnumerable and OldEnumerator classes. (This is in the Main() method of a console application.)

var old = new OldEnumerable();

var oldenum = old.GetEnumerator();

while (oldenum.MoveNext())
{
    object i = oldenum.Current;

    Console.WriteLine(i);
}

Console.ReadKey();

As you can see, we first create our IEnumerable class, then call GetEnumerator to get our IEnumerator class. We don’t actually know that we’re working with GetEnumerator here, we’re merely working by contract with IEnumerator. Next, we have a while loop with a precondition of oldenum.MoveNext(), which returns whether or not we can access the next element in the sequence. If we can, we get the Current element (again of type Object), and implicitly call its ToString() method in the call to Console.WriteLine(). We now get the following output:

(I’m assuming you can trust me when I say it starts at 1. In retrospect, going 1 to 10 would have been a better example.)

When you look at IEnumerable/IEnumerator this way, you quickly realize that the values of x were not pre-calculated. Instead, they were lazy evaluated and calculated on the fly. This is why I chose to use the term “sequence” instead of “collection” earlier.

Obviously, calling GetEnumerator and storing it’s output into a new variable, and calling MoveNext() and Current from a “while” loop is not the cleanest way of looping over items. We’d much rather do this:

var old = new OldEnumerable();

foreach (var i in old)
    Console.WriteLine(i);

Console.ReadKey();

Much better. And, best of all, it still works as expected. Why? There’s a compiler trick going on here. To find what it is, we first step through the code.

After highlighting the foreach keyword and hitting F10 to continue stepping, it first highlights the “old” in the statement as seen above. Next step it highlights “in”:

And then on the next step, it highlights “var i”:

What’s going on here? Why is it moving backwards? Actually, it’s performing GetEnumerator(), MoveNext(), and Current in those three steps, in that order. When “old” is highlighted, it calls GetEnumerator() and stores the enumerator in a hidden variable. When “in” is highlighted, it calls MoveNext(), which upon the first iteration is very convenient because it’s called before Current is referenced. Then, when “var i” is highlighted, it calls Current’s getter method and stores the output in a variable (here inferred to be type Object) called “i”.

Thanks to Visual Studio 2010’s new Intellitrace feature, we can see this in action:

The blue arrows indicate code that has been automatically stepped over, and you can see at each stop point (indicated by red Stop-button icons) that the functions mentioned above are called. Furthermore, when we go another iteration through, we see the following:

We see the first call to Console.WriteLine() in the body of our foreach loop, and then MoveNext() is called again followed by Current. This will continue ad nauseum until MoveNext() returns false and giving us an escape from our iteration. If MoveNext() never returns false, the iteration could continue infinitely, or until an exception is thrown.

Also of note is on our second iteration, “old” is not highlighted. This is because we no longer need a new enumerator, since we already have one. So first “in” is highlighted (MoveNext) followed by “var i” (setting the value of Current to “i”).

At the beginning of this post, I mentioned a question I might ask to a candidate: what pattern does this represent under the hood? While it’s not the most straight-forward question (or the most straight-forward answer), it’s an interesting question to ask because it gets the candidate to think. The answer is a “state machine” pattern, where the object operates based on its state, which may be constantly changing, but the state is persisted in the object for a given period of time (such as the object’s lifespan). The “Current” value of x is our state (which could be the current index of an array, for example), and MoveNext() alters our state.

Now let’s look at the generic version of IEnumerable, IEnumerable<T>. It also has a generic enumerator counterpart, IEnumerator<T>. Interestingly enough, the namespaces that contain the generic versions are imported by default with a new project in Visual Studio 2010 / .NET 4, while the IEnumerable/IEnumerator non-generic versions are in a namespace that is not imported by default, System.Collections. I take this to mean that Microsoft is encouraging the adoption of the generic, type-safe versions of them instead of the non-generic versions. In our example, we get for free the added benefit of type inference as well as we no longer need to box the Int32 variable when we return it in the Current getter, probably resulting in better performance due to less IL being generated.

Like IEnumerable, we have GetEnumerator() in IEnumerable<T>. However, it now has an overload, one which returns IEnumerator<T>, the other which returns IEnumerator. The reason for this is simpler than it may appear on the surface -- IEnumerable<T> inherits from IEnumerable for compatibility reasons. You can safely cast an IEnumerable<T> type to IEnumerable for use with legacy code. However, with value types such as our example, you’ll end up adding boxing as well.

Here’s our IEnumerable<T> implementation:

public class NewEnumerable : IEnumerable<int>
{
    public IEnumerator<int> GetEnumerator()
    {
        return new NewEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new NewEnumerator();
    }
}

As you can see, we have the new, generic GetEnumerator as well as the old, non-generic one. In both cases we’re returning a new instance of the NewEnumerator() class, since it inherits from IEnumerator<T> as well as IEnumerator, making it a safe implicit cast for both. Here’s our IEnumerator<T> implementation:

public class NewEnumerator : IEnumerator<int>
{
    int x = 0;

    public int Current
    {
        get { return x; }
    }

    public void Dispose()
    {
        // do nothing
    }

    object IEnumerator.Current
    {
        get { return x; }
    }

    public bool MoveNext()
    {
        return x++ < 100;
    }

    public void Reset()
    {
        x = 0;
    }
}

Note that IEnumerator<T> not only inherits from IEnumerator but also IDisposable as well, meaning you can use any IEnumerator<T> inside a “using” block if you wish. Hence, we now have a Dispose method along for the ride. In our implementation, we don’t have any unmanaged resources we need to dispose of, so we do nothing.

We also now have two Current properties – one returns T (in this case, int), the other returns object. When working with the generic version, we’ll be using the T version of Current, and when working this enumerator as IEnumerator, we’ll be using the object version of Current. Since IEnumerator<T> only defines Current, we inherit MoveNext() and Reset() from IEnumerator, and so there’s no change there. Also, here you can see that since Current is now generic and returns int, there is no longer a need to box “x” to an object to return it.

We can now use the NewEnumerator class in exactly the same way as OldEnumerator, but now we don’t need to cast the value to use it as an int. (If we wanted to – we didn’t need to in the previous example as we were only implicitly using ToString() on System.Object.)

var newenum = new NewEnumerable();

foreach (int i in newenum)
    Console.WriteLine(i);

Console.ReadKey();

So that’s all well and good. Now, how do we use the “yield” keyword, and why did I tie it in with a post on IEnumerable<T>?

Because it builds for you an automatic IEnumerator<T>.

That’s pretty much all it does. That – and it maintains the state of the code around it until the next iteration. This may not be the best explanation of the “yield” keyword, but I think it fits.

Here’s a handy extension method to make your code feel more fun and expressive (or confusing and hard-to-maintain, depending on if you’re an optimist or a pessimist).

public static IEnumerable<int> To(this int value, int inclusiveMax)
{
    for (int i = value; i <= inclusiveMax; i++)
        yield return i;
}

This extension method, when placed in a static class in your project will allow you to this:

var ten = 1.To(10);

foreach (var i in ten)
    Console.WriteLine(i);

Since 1 is an int, it gets the extension method To() which returns an IEnumerable<int>. Notice that we have not created a class that inherits from IEnumerable<int>, nor a class that inherits from IEnumerator<int>. The C# compiler does this for us automatically with an anonymous, compiler-generated type. We can pull it up in Reflector and see this type:

Notice that the method starts with <To> – that’s the name of the method that uses this enumerator. Also notice the d__0 identifier – that’s how the .NET runtime knows how to access this compiler-generated type. And finally, notice that it inherits from both IEnumerable<T> and IEnumerator<T>, making it both an enumerable and enumerator at the same time. Our previous examples could have done this, but I separated them out for clarity. If you wanted to do this in the previous examples, just have GetEnumerator() return “this”.

There’s a bunch of thread-safe code going on underneath those method signatures, so try it on your own to see what’s happening – I’ll spare the details here.

Nonetheless, the code does what you would expect – it prints 1 through 10 and stops. As you can see, the yield keyword can save you a ton of code. Here’s another extension method to multiply each element so you can better see the benefits of yield:

public static IEnumerable<int> Multiply(this IEnumerable<int> value, int multiplier)
{
    foreach (int v in value)
        yield return v * multiplier;
}

Now we can use the two together like this:

var dbl = 1.To(10).Multiply(2);

foreach (var i in dbl)
    Console.WriteLine(i);

I hope this helps your understanding of IEnumerable, IEnumerable<T>, IEnumerator, IEnumerator<T>, and the “yield” keyword.

Aside: Sadly the “yield” keyword has no equivalent in VB. It’s a feature that’s been sorely missing, and is still missing in .NET 4.

Update: I realized that in the IDisposable.Dispose() method in the above examples, it should be calling Reset(). The reason for this is that many times IEnumerator<T> is used in a "using" block such that once it is disposed, it should be reset.

VS2010: A First Look at Beta 2 for ASP.NET – Part 1

2009-10-21T18:36:00.002-04:00

If you haven’t yet downloaded Visual Studio 2010 Beta 2, what are you waiting for? Until then, here’s a first look at what’s new for ASP.NET developers with .NET 4 and Visual Studio 2010.

Visual Changes

First off, there’s a new splash screen and icon! I know, I know, this really isn’t important for day-to-day use. But I feel it reflects Microsoft’s renewed commitment to great user experience. Personally, I absolutely love it.

This is the new icon that shows up in the taskbar.

Also there’s a new theme for the overall UI. A bit darker, and 100% more awesome. Even the menus are in WPF, so it feels more “2010” and less “2003”.

New ASP.NET Default Template

When you do File –> New Project and choose the ASP.NET Web Application project template, you now get a much more robust project template by default for new web forms projects, complete with authentication, much like the default ASP.NET MVC project template.

Snippets for ASPX Markup

The awesome snippets that make coding in C# and VB more fun have made their way to ASPX markup. Start typing “<button” and press tab twice to get a button snippet like this. One annoying issue I’ve noticed is that trying to type a normal <a> tag is painful, because it tries to put in an <accessdatasource> snippet instead. Hopefully this will be resolved by the next Beta/RC.

Client ID Mode

There is a new ClientIDMode attribute that can be applied to most server controls that changes the output ID to make it more JavaScript and CSS friendly. Given the following ASPX code:

<asp:Panel ID="pnlContent" runat="server" ClientIDMode="Static">
  This is some content
</asp:Panel>

The following HTML is outputted:

<div id="pnlContent">
  This is some content  
</div>

As compared to the following HTML output without ClientIDMode=”Static”:

<div id="MainContent_pnlContent">
  This is some content
</div>

Which, as you know, if that pnlContent panel was nested 5 layers deep in controls, you would see each of those layers’ IDs present in its ID. This makes the IDs of the elements predictable for use in JavaScript and CSS.

HTML Encoding Block Syntax

Especially when dealing with ASP.NET MVC, but also with WebForms, you end up needing to HTML encode output when using the ASP-style blocks. With the following code-behind:

protected void Page_Load(object sender, EventArgs e)
{
  FooterContent = "Hello <World> !";
}

public string FooterContent { get; set; }

And the following ASPX page:

<%= FooterContent %>

We get the following output:

But if we wanted to HTML encode that output, we previously would need to do this:

<%= Server.HtmlEncode(FooterContent) %>

Now, we can use a new block syntax to do the same, without the function call:

<%: FooterContent %>

And now we get properly escaped HTML output:

Hello &lt;World&gt; !

Which shows up properly in our browser as we would expect:

Creating Your Own IoC Container: Part 2

2009-09-30T18:30:00.002-04:00

In the first part of this post series (which, honestly, I didn’t intend to need a Part 2), I discussed how you can easily create your own container for basic inversion of control (IoC) needs. However, many people may need to use Dependency Injection (DI) as well, so I’ve modified the project to support DI.

Also, a colleague pointed out that there’s another reason why you may want to do this – to simply see how it all works. Sure, you can plop Ninject into a project and start using DI/IoC, but creating your own makes you realize what’s really involved and going on behind-the-scenes.

Here I’ve modified the previous example to support DI, and it took less than an hour.

Warning: I have only briefly tested this code, and have not created unit tests. Before using in production, I’d recommend testing it thoroughly. You’ll also need to get the previous post working on your end before integrating these features. I also noticed a bug after publishing this post reading through the code that if you request an IFoo, and Foo : IFoo has a constructor that is asking for an IFoo parameter, you'll end up in an endless loop and probably stack overflow. Ideally this should detect a circular Resolve() call, and throw an exception.

The IServiceResolver Interface

This bit is not required, however I realized as I was writing the DependencyInjector class below that I was tightly coupling it with ServiceResolver from the previous post. Since this is very much an anti-pattern, I decided to make ServiceResolver implement an interface, so that you can use your own IServiceResolver implementation with this DependencyInjector class. Here’s the interface:

using System;

namespace Core
{
   public interface IServiceResolver
   {
       void Register<TFrom, TTo>();
       T Resolve<T>();
       object Resolve(Type fromType);
   }
}

Notice that I’ve added a non-generic version of this class. This was done for compatibility, and now the ServiceResolver class looks like the following. The major changes are it now implements the IServiceResolver interface, and there is the new non-generic method which is called by the generic method. Also, it does not throw an exception if there has not been a registration for the given type. Instead, it creates a new object and looks for any injections. This is to remove the need to bind items to themselves. Note that there is still a tight coupling in the default constructor to DependencyInjector. You may wish to remove this.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Core
{
   /// <summary>
   /// Resolves abstract types or interfaces to concrete implementations. Use <see cref="ServiceLocator" /> for static/shared access.
   /// </summary>
   public class ServiceResolver : IServiceResolver
   {
       private Dictionary<Type, object> _store;
       private Dictionary<Type, Type> _bindings;
      
       /// <summary>
       /// Default constructor; instantiates a new ServiceResolver object.
       /// </summary>
       public ServiceResolver()
       {
           this.DependencyInjector = new DependencyInjector(this);
           _store = new Dictionary<Type, object>();
           _bindings = new Dictionary<Type, Type>();
       }

       /// <summary>
       /// Creates a new ServiceResolver with a given IDependencyInjector.
       /// </summary>
       /// <param name="injector">The IDependencyInjector to use for dependency injection.</param>
       public ServiceResolver(IDependencyInjector injector)
       {
           this.DependencyInjector = injector;
           _store = new Dictionary<Type, object>();
           _bindings = new Dictionary<Type, Type>();
       }

       /// <summary>
       /// Gets an implementation object of a registered abstract type or interface.
       /// </summary>
       /// <typeparam name="T">The registered abstract type or interface to look up.</typeparam>
       /// <returns>Returns an object of the given type.</returns>
       public T Resolve<T>()
       {
           return (T)Resolve(typeof(T));
       }

       /// <summary>
       /// Gets an implementation object of a registered abstract type or interface.
       /// </summary>
       /// <param name="fromType">The registered abstract type or interface to look up.</param>
       /// <returns>Returns an object of the given type.</returns>
       public object Resolve(Type fromType)
       {
           // check for registration
           if (!_bindings.ContainsKey(fromType))
               return DependencyInjector.GetInjectedInstance(fromType);
              
           // get destination type
           Type dest = _bindings[fromType];

           // check for already requested object
           if (_store.ContainsKey(dest))
               return _store[dest];

           // create a new instance of this type
           object obj = DependencyInjector.GetInjectedInstance(dest);

           // add to store for future use
           _store.Add(dest, obj);

           return obj;
       }

       /// <summary>
       /// Registers a type with its corresponding implementation type.
       /// </summary>
       /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
       /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
       public void Register<TFrom, TTo>()
       {
           _bindings.Add(typeof(TFrom), typeof(TTo));
       }

       /// <summary>
       /// Gets or sets a dependency injector to use for types that need injection.
       /// </summary>
       public IDependencyInjector DependencyInjector { get; set; }

   }
}

The InjectAttribute class

In order to tell our DependencyInjector class that we want to inject something, we need to decorate either a constructor or some properties (or both) with an [Inject] attribute. If you’ve never created your own attributes, all you have to do is create a new class with a name that ends in Attribute (the “Attribute” bit is cut off on use) and make it inherit from Attribute. Here’s our empty InjectAttribute class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Core
{
   [AttributeUsage(AttributeTargets.Property | AttributeTargets.Constructor)]
   public class InjectAttribute : Attribute
   {

   }
}

the IDependencyInjector Interface

Since we want to make our DependencyInjector loosely coupled with any use of it, we want to make it implement an interface.

using System;

namespace Core
{
   public interface IDependencyInjector
   {
       T GetInjectedInstance<T>() where T : class;
       object GetInjectedInstance(Type fromType);
       IServiceResolver ServiceResolver { get; set; }
   }
}

The DependencyInjector Class

Now that we have all of the plumbing out of the way, we can show off our new DependencyInjector class.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;

namespace Core
{
   /// <summary>
   /// A class for getting instances of objects that need dependencies injected to function.
   /// </summary>
   public class DependencyInjector : IDependencyInjector
   {
       /// <summary>
       /// Creates a new DependencyInjector with a default IServiceResolver for resolving types.
       /// </summary>
       public DependencyInjector() : this(new ServiceResolver())
       { }

       /// <summary>
       /// Creates a new DependencyInjector with a given IServiceResolver for resolving types.
       /// </summary>
       /// <param name="resolver">The IServiceResolver to use for resolving types to implementations.</param>
       public DependencyInjector(IServiceResolver resolver)
       {
           this.ServiceResolver = resolver;
       }

       /// <summary>
       /// Gets or sets an IServiceResolver to use for resolving types to implementations.
       /// </summary>
       public IServiceResolver ServiceResolver { get; set; }

       /// <summary>
       /// Gets an injected instance of a given type.
       /// </summary>
       /// <typeparam name="T">The type to instantiate and inject.</typeparam>
       /// <returns>Returns a new instance of the given type.</returns>
       public virtual T GetInjectedInstance<T>() where T : class
       {
           return (T)GetInjectedInstance(typeof(T));
       }

       /// <summary>
       /// Gets an injected instance of a given type.
       /// </summary>
       /// <param name="fromType">The type to instantiate and inject.</param>
       /// <returns>Returns a new instance of the given type.</returns>
       public virtual object GetInjectedInstance(Type fromType)
       {
           object obj = null;

           foreach (var constructor in fromType.GetConstructors())
           {
               // look for inject attribute
               var attr = GetConstructorInjectAttribute(constructor);

               if (attr != null)
               {
                   // get parameters to inject
                   var parmValues = GetResolvedParameterValues(constructor);

                   if (parmValues.Count > 0)
                       obj = Activator.CreateInstance(fromType, parmValues.ToArray());

                   break;
               }
           }

           // handle case where no constructor injections
           if (obj == null)
               obj = Activator.CreateInstance(fromType);

           foreach (var prop in fromType.GetProperties())
           {
               // look for inject attribute
               var attr = GetPropertyInjectAttribute(prop);

               if (attr != null)
                   prop.SetValue(obj, ServiceResolver.Resolve(prop.PropertyType), new object[] { });
           }

           return obj;
       }

       /// <summary>
       /// Gets an InjectAttribute (if any) for the given constructor.
       /// </summary>
       /// <param name="constructor">The constructor to inspect for an InjectAttribute.</param>
       /// <returns>Returns an InjectAttribute if exists, or null if not.</returns>
       protected virtual InjectAttribute GetConstructorInjectAttribute(ConstructorInfo constructor)
       {
           var attrs = constructor.GetCustomAttributes(typeof(InjectAttribute), true);
           return attrs.OfType<InjectAttribute>().FirstOrDefault();
       }

       /// <summary>
       /// Gets an InjectAttribute (if any) for the given property.
       /// </summary>
       /// <param name="prop">The property to inspect for an InjectAttribute.</param>
       /// <returns>Returns an InjectAttribute if exists, or null if not.</returns>
       protected virtual InjectAttribute GetPropertyInjectAttribute(PropertyInfo prop)
       {
           var attrs = prop.GetCustomAttributes(typeof(InjectAttribute), true);
           return attrs.OfType<InjectAttribute>().FirstOrDefault();
       }

       /// <summary>
       /// Gets a list of parameter values for the given constructor, resolved by the ServiceResolver.
       /// </summary>
       /// <param name="constructor">The constructor to resolve parameters for.</param>
       /// <returns>Returns a new list of parameter values.</returns>
       protected virtual List<object> GetResolvedParameterValues(ConstructorInfo constructor)
       {
           var parms = constructor.GetParameters();
           List<object> parmValues = new List<object>();

           foreach (var parm in parms)
           {
               if (parm.ParameterType.IsInterface || parm.ParameterType.IsAbstract)
               {
                   Type parmType = parm.ParameterType;
                   object parmValue = ServiceResolver.Resolve(parmType);
                   parmValues.Add(parmValue);
               }
               else
                   throw new InvalidOperationException("Unable to inject a parameter that is not an interface or abstract type.");
           }

           return parmValues;
       }

   }
}

I’m not going to cover line-by-line what this class does, but basically it looks for any InjectAttributes decorating a constructor or properties, and if it finds them, it resolves instances automatically using the ServiceLocator (another tight coupling) and fills them in.

Usage

Back in our ASP.NET MVC test app, we have created a new interface to use for testing, ILogger. It has one implementation (but could have many), and this one is WebLogger which writes out the log message to the current HttpResponse.

using System;

namespace CustomIoCMvc.Models
{
   public interface ILogger
   {
       void Log(string message);
   }
}

And here’s our WebLogger:

using System;
using System.Web;

namespace CustomIoCMvc.Models
{
   public class WebLogger : ILogger
   {
       public void Log(string message)
       {
           HttpContext.Current.Response.Write(message);
       }
   }
}

We, of course, need to wire up this implementation in our Global.asax.cs:

protected void Application_Start()
{
   RegisterRoutes(RouteTable.Routes);
  
   // register types
   ServiceLocator.Register<ICustomerRepository, CustomerRepository>();
   ServiceLocator.Register<ILogger, WebLogger>();

}

Our CustomerRepository is going to now use an ILogger for all of its calls. Here it is with a Constructor injection:

using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Collections.Generic;
using Core;

namespace CustomIoCMvc.Models
{
   public class CustomerRepository : ICustomerRepository
   {
       [Inject]
       public CustomerRepository(ILogger logger)
       {
           this.Logger = logger;
       }

       public Customer Find(int id)
       {
           Logger.Log("Find called with param value " + id.ToString());
           return FindAll().Where(c => c.Id == id).FirstOrDefault();
       }

       public List<Customer> FindAll()
       {
           Logger.Log("FindAll called.");
           var data = new List<Customer>();
           data.Add(new Customer() { Id = 1, Name = "Joe" });
           data.Add(new Customer() { Id = 2, Name = "Steve" });
           data.Add(new Customer() { Id = 3, Name = "Karen" });
           return data;
       }

       public ILogger Logger { get; set; }
   }
}

And here’s our CustomerRepository with Property injection:

using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Collections.Generic;
using Core;

namespace CustomIoCMvc.Models
{
   public class CustomerRepository : ICustomerRepository
   {

       public Customer Find(int id)
       {
           Logger.Log("Find called with param value " + id.ToString());
           return FindAll().Where(c => c.Id == id).FirstOrDefault();
       }

       public List<Customer> FindAll()
       {
           Logger.Log("FindAll called.");
           var data = new List<Customer>();
           data.Add(new Customer() { Id = 1, Name = "Joe" });
           data.Add(new Customer() { Id = 2, Name = "Steve" });
           data.Add(new Customer() { Id = 3, Name = "Karen" });
           return data;
       }

       [Inject]
       public ILogger Logger { get; set; }
   }
}

Both have been tested with the same result. But first, a little background about what’s going on here.

Our CustomersController is requesting from the service locator an instance of ICustomerRepository. It finds that we’ve bound ICustomerRepository to CustomerRepository, and goes to instantiate that class. What we’ve modified our code to do is to look, before we instantiate, if there’s a constructor with an [Inject] attribute. If there is, we fill in the constructor parameters with the needed types. If not, we go ahead and create the object with the default constructor.

Next, after we’ve instantiated the object, it looks for any properties with an [Inject] attribute, and does the same. Finally, it returns the object.

Therefore, in this case, our DependencyInjector is getting a request for a new CustomerRepository, it looks for a constructor with [Inject], sees one (in the first example) and resolves ILogger to the bound WebLogger type, gets an instance of WebLogger, and fills it in to the constructor. In the second example, it uses a default constructor but finds the [Inject] decorated Logger property, resolves ILogger to WebLogger, and sets it.

So here’s our output. You can’t really see it (because it’s a cheap quick hack), but theres a “FindAll called.” string at the top of the page:

Let me know in the comments if you have any issues or constructive criticism of this code. Hope this helps!

Creating Your Own IoC Container

2009-09-23T21:55:00.002-04:00

A few posts ago I covered how to take your first steps into Dependency Injection with Ninject. Continuing on the DI/IoC theme, let’s now look at how you can create your own Inversion of Control (IoC) container.

Suppose that your organization has very strict limits on what outside software you can use due to licensing, but you still want to do IoC. Or, perhaps you don’t need your IoC container to do very much other than the basics and you don’t want the weight of another full-featured DLL. This is what we will be creating today, with 2 classes: a ServiceResolver and a ServiceLocator.

(Aside: For those that feel I’m using the term “Service Locator” inappropriately, please forgive me. For this example that’s the name I came up with.)

A basic IoC container needs to do the following:

Register abstract types or interfaces to concrete implementation types
Resolve abstract types or interfaces to implementation objects
Keep track of the registered types
Keep already-resolved objects available for re-use
Create instances of the implementation types behind-the-scenes

Our two classes will accomplish that, but only one has most of the logic – the ServiceResolver. The reason for the ServiceLocator class is to provide static methods around the ServiceResolver, and maintain a static instance of the resolver. Since static methods are difficult to test, this allows you to test the functionality of the ServiceResolver class, and trust that the basic wrapper functionality of the ServiceLocator just works.

The Light At The End

Sometimes it’s fun to see what we’re aiming to do, instead of starting from the beginning, right? Basically we’re going to have a simple ASP.NET MVC site that is going to have a Customers controller. The Index action will ask the service locator for an implementation of ICustomerRepository so that it is loosely coupled. In our Global.asax class, we will register the binding of ICustomerRepository to CustomerRepository. The reason for this is we are pretending that CustomerRepository hits the database, so that for our unit tests we could create a mock repository that does not.

Our Global.asax.cs file looks like this:

 protected void Application_Start()
         {
             RegisterRoutes(RouteTable.Routes);
             
             // register types
             ServiceLocator.Register<ICustomerRepository, CustomerRepository>();

         }

Note that in a real-world app, you may wish to register types on each page request, not on application start.

And our Index action looks like this:

 public ActionResult Index()
         {

             var repo = ServiceLocator.Resolve<ICustomerRepository>();

             ViewData["customers"] = repo.FindAll();

             return View();

         }

The ServiceResolver Class

Let’s look at the ServiceResolver class that does all the heavy lifting (although there really isn’t much).

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;

 namespace Core
 {
     /// <summary>
     /// Resolves abstract types or interfaces to concrete implementations. Use <see cref="ServiceLocator" /> for static/shared access.
     /// </summary>
     public class ServiceResolver
     {
         private Dictionary<Type, object> _store;
         private Dictionary<Type, Type> _bindings;

         /// <summary>
         /// Default constructor; instantiates a new ServiceResolver object.
         /// </summary>
         public ServiceResolver()
         {
             _store = new Dictionary<Type, object>();
             _bindings = new Dictionary<Type, Type>();
         }

         /// <summary>
         /// Gets an implementation object of a registered abstract type or interface.
         /// </summary>
         /// <typeparam name="T">The registered abstract type or interface to look up.</typeparam>
         /// <returns>Returns an object of the given type.</returns>
         public T Resolve<T>()
         {
             // check for registration
             if (!_bindings.ContainsKey(typeof(T)))
                 throw new InvalidOperationException(string.Format("Requested type {0} has not been registered.", typeof(T).ToString()));

             // get destination type
             Type dest = _bindings[typeof(T)];

             // check for already requested object
             if (_store.ContainsKey(dest))
                 return (T)_store[dest];

             // create a new instance of this type
             T obj = (T)Activator.CreateInstance(dest);

             // add to store for future use
             _store.Add(dest, obj);

             return obj;
         }

         /// <summary>
         /// Registers a type with its corresponding implementation type.
         /// </summary>
         /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
         /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
         public void Register<TFrom, TTo>()
         {
             _bindings.Add(typeof(TFrom), typeof(TTo));
         }

     }
 }

First, notice the _store and _bindings members. Those are our ways of keeping track of registered types (_bindings) and reusable already-resolved objects (_store).

The Register<TFrom, TTo>() method adds to the _bindings dictionary the “from” and “to” types to use later, whenever Resolve<T>() is called. Since we’re just storing types in the dictionary, there is little overhead and it’s okay to register all our types in advance.

Finally, the Resolve<T>() method looks for a pre-registered type binding, and throws an error if it doesn’t find one. Then, it looks to see if an object has already been created for this type. If so, it returns it. If not, it creates an instance of the type and adds it to the _store dictionary before returning it.

You can certainly use the ServiceResolver class by itself for IoC, but I prefer using static methods for conciseness. That’s why we need a static wrapper class, called ServiceLocator.

The ServiceLocator Class

Here’s our ServiceLocator static wrapper class.

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;

 namespace Core
 {
     /// <summary>
     /// A service locator to resolve abstract types or interfaces to concrete implementations.
     /// </summary>
     public class ServiceLocator
     {

         private static ServiceResolver _instance = null;
         private static object _lock = new object();

         /// <summary>
         /// Gets a shared instance of the ServiceResolver.
         /// </summary>
         /// <returns>Returns the shared instance of a ServiceResolver, or a new one if it has not yet been accessed.</returns>
         private static ServiceResolver GetInstance()
         {
             lock (_lock)
             {
                 if (_instance == null)
                     _instance = new ServiceResolver();

                 return _instance;
             }
         }

         /// <summary>
         /// Binds an abstract type to a concrete implementation.
         /// </summary>
         /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
         /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
         public static void Register<TFrom, TTo>()
         {
             GetInstance().Register<TFrom, TTo>();
         }

         /// <summary>
         /// Gets an implementation of the given type.
         /// </summary>
         /// <typeparam name="T">The abstract type or interface to look up.</typeparam>
         /// <returns>Returns an implementation of the given type.</returns>
         public static T Resolve<T>()
         {
             return GetInstance().Resolve<T>();
         }

     }
 }

Notice that we’ve got one static instance of the service resolver, and a GetInstance() method that instantiates it if it doesn’t exist. Also notice our Resolve and Register methods that have the same signature (albeit static) as our ServiceResolver class.

This enables us to simply call ServiceLocator.Resolve<T>() without needing to find an instantiated resolver or create one.

Just to show you that this was tested, here’s our view:

 <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

     <h2>Customers</h2>
     
     <ul>
     <% foreach (Customer c in (List<Customer>)ViewData["customers"])
        { %>
         <li><%= c.Name %></li>     
     <% } %>
     </ul>
     
 </asp:Content>

Here’s our CustomerRepository:

 namespace CustomIoCMvc.Models
 {
     public class CustomerRepository : ICustomerRepository
     {

         public Customer Find(int id)
         {
             return FindAll().Where(c => c.Id == id).FirstOrDefault();
         }

         public List<Customer> FindAll()
         {
             var data = new List<Customer>();
             data.Add(new Customer() { Id = 1, Name = "Joe" });
             data.Add(new Customer() { Id = 2, Name = "Steve" });
             data.Add(new Customer() { Id = 3, Name = "Karen" });
             return data;
         }

     }
 }

And here’s the output:

Hope this helps! Please leave constructive comments below. Also note that I'm still playing around with formatting code, please forgive me if it doesn't render correctly!

Pair Programming in the News

2009-09-22T08:45:00.003-04:00

I’ve been a huge fan of pair programming for a while now. It really is more productive, and it effectively is a real-time code review as you write it. I’ve had the chance to do some pair programming here at the new gig, and it’s worked out really well. A new favorite quote of mine when paraphrased goes something like “You don’t learn from people that agree with you” and with pair programming that is definitely the case. You learn from the mistakes you make when your partner disagrees with what you just wrote.

So I was very excited to find an article about pair programming in the New York Times. Check it out and let me know in the comments what your thoughts are.

I’ve got a few new discoveries with ASP.NET MVC and Dependency Injection that I’m gearing up some posts about, and as you may have noticed, I’m still trying to figure out the best way to get code into this blog as a formatted, copy-and-paste-able format.

I’m looking forward to the next meetings (and my first) of JaxDUG (Jacksonville .NET User Group), ArcSIG (for Architects), and the Jacksonvile SQL Server Users Group. I’m a big fan of community, and if you’ve never been to a local .NET user group, I strongly encourage you to give it a try.

Update: It appears that at least one person is asserting a more pessimistic view of this article. I really am not a proponent of that kind of negative, borderline arrogant language, as I try to make this blog positive and forward-thinking for beginners as well as experts -- but it's an interesting read nonetheless.

ASP.NET: WebForms Validation with Data Annotations

2009-08-19T10:23:00.001-04:00

Last night at my last regular trip to the Lakeland .NET User Group I had a discussion with someone about how it’s great that Data Annotations is being used by Dynamic Data, RIA services, and now ASP.NET MVC 2, but that there isn’t a WebForms validation control (like the PropertyProxyValidator in the Validation block of Enterprise Library) to auto-validate against Data Annotations. I suggested we write one. I did so this morning.

If you aren’t familiar with Data Annotations, it’s a really cool feature of .NET 3.5 SP1. Check out those 3 links above (Dynamic Data, RIA, and MVC) for more info of how they’re used elsewhere.

The DataAnnotationValidator Class

Here’s the code for the Data Annotations Validator that I built for WebForms. I just created this as a class file in the App_Code folder of my web project for testing, but you’d probably want to move it into your shared library (if you have one). You’ll need to add a reference to System.ComponentModel.DataAnnotations first.

And there’s just 2 properties in this class:

Data Annotating Your Class

Here’s a test class I wrote using some common annotations:

Here you see you can add multiple validators together (such as Required and StringLength in this example). And there’s also a RegularExpression validator:

Usage

To use this DataAnnotationValidator on your page, you must first register the namespace. (Note: you can also do this in the web.config to force it on all pages in your site.)

The namespace value must match the namespace of DataAnnotationValidator.

To add a validator to a form field, just create a new <val:DataAnnotationValidator> tag for each field:

Notice the SourceType property? That value must match the full type name of the object you’re validating.

Now when you try and submit your form you get this:

(In this example, the Address 2 field is not marked as required.)

You can also simply add a ValidationSummary to the page to show what is wrong:

And now we get a helpful list of errors:

You’re probably thinking, though, “what’s so special about this? I could just use a RequiredFieldValidator.” True, but we now have multiple validators per property with just one validator tag, and we don’t have to make the front end logic match the back end annotations. Separation of concerns!

Here’s the RegularExpression data annotations validator at work:

You can see where this becomes handy – you annotate your class once, and you can then use it in RIA services, ASP.NET MVC 2, and now WebForms, and you don’t have to have any validation logic in your front end code. This idea could easily be modified for Windows Forms or WPF as well. You could also easily modify the code to set a CSS style for the textbox that would change the background color on error.

Hope this helps! Let me know any questions or concerns in the comments.

Also, I couldn’t have done this without some guidance from the Enterprise Library PropertyProxyValidator source code, and this Stack Overflow question/answer.

Update: Using DisplayName

I realized that I was forgetting a key part of data annotations – that it supports the DisplayNameAttribute! This removes all of the string error messages from the class definition and generates them for you. Below are the modifications to support DisplayName. If a display name is not given, it will use the property name instead, which is great for single word property names like “City”.

In your class file that you’re annotating, import System.ComponentModel.

In the DataAnnotationValidator class, modify the routine to look up the DisplayName or property name like this:

Also make sure you modify the Me.ErrorMessage line to use attr.FormatErrorMessage(displayName) like above.

Now, you can yank out all of those error message strings! If you’ve got a single word property name, like Id, you can just do this:

And if you need to add a display name, you can add the DisplayName() attribute:

Once we’ve made these modifications (which make the class definition much more concise), we get the following output on our form, without having to write our own error messages:

You’ll still want to keep the error message specified for the RegularExpression annotation validator, because it actually shows the RegEx expression in the error message, which will confuse your users.

First Steps into Dependency Injection with Ninject

2009-08-17T18:49:00.001-04:00

I recently started playing around with dependency injection, but it was very much a by-hand process using constructor injection without any kind of framework. It worked well for my proof of concepts, but I had a breakthrough today when I tried Ninject. If you’re looking to get into DI/IoC, this hopefully will be a good place to start. I’m right there with you, I’m a newbie to DI as well.

If you’re already confused by the first paragraph, Dependency Injection (hereafter called DI) and Inversion of Control (hereafter called IoC) are almost synonyms for a development methodology where you aim to reduce coupling between classes as much as possible. Coupling means that one class depends on another, which increases complexity for large projects and almost ruins testability. For example, if your class needs to use a database connection, you might not want to couple it with SqlClient.SqlConnection, you might just want to couple it to the interface IDbConnection instead, so that it can accept any type of connection. (SqlConnection implements IDbConnection.) This makes your code more flexible for testing, because you can create a mock connection that implements IDbConnection and perform unit tests without hitting your database. This is just one example, although there are many reasons to use DI.

While there are other methods of injection, I’m only going to talk about 2 in this post – constructor injection and property injection.

In this example, let’s say you have a Customer class that needs to use a database connection. Since you want to roll your own database connection wrapper classes, you also want to implement logging so you can keep track of your database requests.

Let’s start out with a console application.

Disclaimer: This is demo code only. It doesn’t actually connect to a database, and does not implement best practices for security or anything else. Please keep that in mind!

Downloading Ninject

You can download Ninject and take a short tutorial at www.ninject.org. The download is a .zip file with all of the Ninject DLLs that you’ll ever need, but really we’re just concerned with the Ninject.Core assembly.

Add Ninject as a Reference

Create a new console application, and from the My Project pages, add the extracted Ninject.Core.dll file as a reference.

It’ll also make it easier later on to go ahead and import the Ninject.Core namespace from the References property page:

The Old Way

First, let’s look at how we might previously have implemented the Customer class without DI.

Here you can see that we’ve got a private SqlConnection object that is created in the constructor. There’s no way here to swap that out for a mock connection for testing, and we’ve got a coupling between Customer and SqlConnection.

Now let’s look at how SqlConnection does its logging (note that this class is obviously just for demo purposes):

As you might have guessed, our SqlConnection object now has a tight coupling with ConsoleLogger. What if we wanted to log to a database or email instead? With this method, we can’t.

Dependency Injection By Hand

As I mentioned earlier, I started out by doing DI by hand, so let’s see what that might look like.

First let’s make an interface for our database connection:

Now, here’s what our SqlConnection class looks like:

We still have a dependency on ConsoleLogger, but we’ll remove that later.

Now our customer class no longer has a dependency on SqlConnection:

And here’s how we use it in our console app:

And the result is (with our ConsoleLogger output):

We still have to inject the SqlConnection by hand, which would work in front end code, but is not ideal.

So, proceeding onto removing the dependency on ConsoleLogger, how would we accomplish this with the method above? Well, we’d probably have to pass in a new ConsoleLogger (implementing ILogger) into our customer object as well. However, then we’d have to pass that logger from the customer into the SqlConnection by a constructor or property. And what if we have to create multiple objects that use the same connection or logger? It becomes a mess very quickly. This is where Ninject steps in to help.

Let’s wrap up a few more things, such as creating an interface for our loggers:

Then we’d make ConsoleLogger implement ILogger.

Setting Up our Injections

How Ninject and other DI solutions work is by automatically wiring up our dependencies for us. For example, we need to wire up 2 dependencies: anytime we want an IDataConnection in this app we want to use a SqlConnection, and anytime we want an ILogger we want a ConsoleLogger. This makes the code testable because you can wire up in your tests to use a mock IDataConnection instead, with another type of logger if you wish.

We’re going to use those two methods of injection as mentioned here before. First, constructor injection. We want to use the constructor of the Customer object to inject a dependency on SqlConnection. Here’s how we mark that constructor for injection:

Next, we want to use property injection to inject a dependency of ConsoleLogger into the SqlConnection.

Note that we’re accomplishing the same goal, but using a Property instead of a Constructor.

Tying It All Together

Ninject uses the idea of a “kernel” to generate all the dependencies. And the kernel can have passed into it multiple “modules” to wire them all together. First we’ll create the DataModule, although you can call it whatever you like:

Note that it must inherit from StandardModule for this to work.

Those 2 lines of code inside the Load method are pretty powerful. They’re saying, using generics, that anytime a class requests an IDataConnection, we want a SqlConnection, and anytime a class requests an ILogger, we get a ConsoleLogger. This is dependency injection at work!

So now that we have our loosely coupled classes (because no class depends on another) and our module for wiring up our connection and logger, we need to actually use the kernel.

Hooray for DI! Now, our front end code doesn’t need to know that it’s using a SqlConnection or ConsoleLogger, it’s happening for us behind the scenes. We could even make the SqlConnection or ConsoleLogger a singleton so that there’s only one instance of it in our application, just by adding the <Singleton()> attribute to the class.

I hope this shows off the basics of using Ninject in an application. Beyond this, I’m not an expert. I only recently got involved in DI, and only today with Ninject. But I’m really impressed so far, and I think once you play around with it you will be too.

Please do not hesitate to (kindly) let me know your questions or concerns in the comments.

Jacksonville, here I come!

2009-08-13T15:59:00.001-04:00

I am happy to say that I have taken a position as a .NET developer at Football Fanatics in Jacksonville! It’s a booming business with a lot of smart developers and they’re really doing some cool things. I’m excited to take on the challenge!

And, to show that it will be a learning experience, they pointed out in my interview that my last post, Conditionally Removing Items from a Generic List, is probably not the best way to do things. After the interview, a large forehead-slap was in order.

So yes, you can remove items conditionally from the list by just using the RemoveAll function with a lambda passed in.

D’oh.

A New Adventure

2009-08-10T12:18:00.001-04:00

After 2 years of living in Lakeland, my wife and I decided that now was a good point in our lives to make a very risky jump – to move to Jacksonville without any jobs lined up to speak of. With a bad job market, this may end up being a bad decision, but we’re confident that things will work out in one way or another. Jacksonville is more our speed, and we just aren’t really happy here. I let my work know today, and it’s going to be a nice, clean, professional break. The job opportunities I’ve been connected with seem like great ways to advance my career and work with some smart people, so I’m excited!

In a month or so we’ll be relocating to Jax and starting the next chapter of our lives. In the mean time, I’ll make my last visit to the Lakeland .NET User Group as a resident of Lakeland, try to write at least another blog post (I still need to finish up one draft), and pack everything up.

I look forward to joining the Jacksonville user groups and I’ll be attending the Jacksonville Code Camp (and helping Russ Fustino with his “It’s All About The Tools” channel9 episode filming) on August 29th. Hope to see you there!