JMPInline

The Demand For Computer Science Graduates

2012-12-18T07:46:00.001-08:00

Today, Olivia Leonardi is contributing a post about the growing demand for computer science graduates and the new, open source programs designed to help meet this need. This article is meant to help those who stumble across the posts regarding the technicalities of C# found on NerdBank a way to break into the industry and join in the conversation. Typically Leonardi is a writer for a website offering information about computer science certification.

The Demand For Computer Science Graduates

Trained computer programmers are needed now more than ever. Modern society has experienced an exponential growth of technology that has revolutionized the economy and the workforce and the education system is struggling to keep up. Based on current figures, there are simply not enough individuals who have been properly trained to design and implement these various programs. However, this deficit may improve as a result of web-based programs that allow students to bypass brick-and-mortar university studies, most of which are extremely competitive and drop the majority of students who apply to them, and learn various aspects of computer programming online. Often times, for free.
According to the US Bureau of Labor Statistics, trained computer programmers essentially act as intermediaries between software engineers and computer systems. Many of them are fluent in multiple code languages; the most widely used languages today include Java, C, C++ and HTML. As new software is developed, programmers must test it and, if necessary, debug programs by correcting errors in the code. This all-important task has implications in virtually every area of web-based development; from corporate websites and online business journals to blogs and social media. Project lengths vary; smartphone apps, for instance, take days to develop and optimize, while complex systems may take more than a year to finish.
Programmers are well compensated for their expertise, and also for their relative rarity in the job market. The BLS reported in 2010 that the median wage for computer programmers was $71,380 – one of the highest in the nation, and according to Forbes, the mid-career median salary for those who earn a master’s degree in computer science is $109,000. These high paying jobs are also not few and far between as associated employment opportunities are projected to grow by 22.3 percent.
The problem, according to a recent article in Science, stems from shortcomings in computer science education programs. Technology is evolving at a much more rapid rate than the curricula taught to college-level computer science students. As a result, most receive a very generalized education without learning supplementary skills, such as specific code languages or complex systems programming. Fortunately, aspiring programmers now have access to several web-based outlets if they wish to learn these supplementary skills. Some of these programs include:
Codecademy | Launched in August 2011, this startup offers free lessons for programmers. Current courses include JavaScript Fundamentals, Python, JQuery and Code Year. According to Forbes, the site received 200,000 visitors within 72 hours of launching – and to date has logged more than 50 million completed exercises.
C# Corner | This step-by-step tutorial trains students how to “write and compile C# programs, understand C# syntaxes” and perform other functions related to this commonly used language. The course is free, though previous code experience (such as C#, Pascal or Java) is recommended.
Coursera | Launched in April 2012, this educational platform has served more than 1 million students to date. The site aggregates free courses offered by a number of prominent institutions, including Massachusetts Institute of Technology, Stanford University, Duke University, and Johns Hopkins University. Upcoming courses related to programming include Functional Programming Principles in Scala (offered by École Polytechnique Fédérale de Lausanne) and Heterogeneous Parallel Programming (offered by University of Illinois at Urbana-Champaign).
University of Oklahoma Online | The OU Supercomputing Center for Education & Research currently offers an online tutorial that introduces principles of supercomputing. Though the concepts are complex, the course is designed to approach topics in a user-friendly manner that, with diligent study, will be digestible for students.
Online courses like these allow computer scientists to fill any gaps left by limited high education programs. If they prove to be effective, then the deficit of trained programmers stands to improve considerably in the coming years.

DotNetOpenAuth ships with Visual Studio 2012

2012-07-04T07:34:00.001-07:00

Some of you may have already heard the announcement on .NET Rocks (time index 41:30), but in case you haven't: Visual Studio 2012 will include DotNetOpenAuth in all its ASP.NET project templates. Woot! Yes, my friends, it has finally happened.

Q&A

Q: With the announcement, Scott Hunter mentions being able to hack into a site that accepted Twitter logins, and may have suggested that the site used DotNetOpenAuth. He also mentioned that Microsoft "hardened" the library to fix some security issues. Does DotNetOpenAuth have security holes?

A: Please don't be alarmed. I worked closely with the Microsoft ASP.NET team who added DotNetOpenAuth to VS2012, and they never found any security holes in the library. I don't actually know what Scott is referring to here. Since a web site can certainly use DNOA improperly, security holes in web sites certainly are possible, but not likely from a fault in the library.

Q: Is DotNetOpenAuth a Microsoft project now?

A: No. DotNetOpenAuth continues to be independently owned and developed, although Microsoft has begun making source contributions to it. Another example of this is jQuery, which Microsoft ships with ASP.NET as well, but Microsoft doesn't own or directly control it.

Q: Will DotNetOpenAuth continue to get regular releases, or are they now tied to Visual Studio releases?

A: DotNetOpenAuth will continue to ship independently of VS. The copy of DotNetOpenAuth that ships with Visual Studio 2012 is actually one of DotNetOpenAuth's own past releases. The way the ASP.NET project templates bundle it is as a NuGet package, so if you create a web project based on these templates, NuGet can help you upgrade to the latest version of DotNetOpenAuth right away.

Q: Is Microsoft contributing to DotNetOpenAuth now?

A: Yes. You may have noticed the new DotNetOpenAuth.AspNet package available on NuGet. This is Microsoft's contribution to the DotNetOpenAuth library. Whereas the rest of DotNetOpenAuth is strictly a protocol library (no specific APIs for individual popular online services), the DotNetOpenAuth.AspNet package adds an assembly which does target all the popular identity providers explicitly, making it easier to add buttons for "log in with Google", "log in with LinkedIn", etc.

Q: What is DotNetOpenAuth.AspNet?

A: DotNetOpenAuth.AspNet is Microsoft's front-end to DotNetOpenAuth that the ASP.NET project templates use instead of DotNetOpenAuth directly. Internally, DotNetOpenAuth.AspNet uses DotNetOpenAuth so you're still using the time-tested library underneath. So if you create a new ASP.NET project in VS2012, you'll be able to switch on DotNetOpenAuth.AspNet by uncommenting a few lines of code.

Q: How does DotNetOpenAuth.AspNet compare with the core DotNetOpenAuth library? Should I switch my existing code to use DotNetOpenAuth.AspNet?

A: To keep things simple, the ASP.NET team decided to conceal the core DotNetOpenAuth API behind theirs and they set several DotNetOpenAuth settings to their simple or "stateless" mode values. This means that things are more likely to work in web farms right out of the box if you're using the DotNetOpenAuth.AspNet frontend, at the cost of a slightly less secure set of defaults. Some settings are harder to reach if you're using the DotNetOpenAuth.AspNet frontend. If you have existing code by all means keep it. The library you're using is still active developed and what DotNetOpenAuth.AspNet uses behind the scenes so you're by no means going to be using obsolete code in the foreseeable future. If you're writing new code, DotNetOpenAuth is still a fine choice, but if you're just acting as a relying party and want a simpler API to use against only popular identity providers, then DotNetOpenAuth.AspNet is a reasonable choice.

Q: How else is DotNetOpenAuth.AspNet different than the rest of the library?

A: It is less configurable than the rest of the library. In particular it doesn't offer any way to be configured via your web.config file. Although since the core DotNetOpenAuth is still active underneath the API, the normal web.config settings you use for DNOA may still apply in some cases. Also, I don't actively support DotNetOpenAuth.AspNet myself. Any feedback or issues filed against it I forward to the ASP.NET team, who maintains that project.

Q: So… this is a Good Thing, right?

A: Absolutely. It has never been easier for ASP.NET developers to build web sites that delegate authentication responsibilities to popular identity providers. This is a boon for web developers, and especially a boon for all our web visitors out there that are now more likely to be able to reuse a few Internet identities instead of maintaining dozens of accounts on all the web sites they visit.

GC pressure series: hidden boxing

2012-06-24T07:11:00.001-07:00

Last time we talked about GC pressure from enumerating collections using their interfaces rather than their concrete types. It turns out that the garbage produced by using the interfaces is directly caused by boxing, which we’ll explore more in depth and in a broader context here.

Before diving into boxing and when it can implicitly occur, let’s first review some terminology. If you’re already fluent in value types vs. reference types, feel free to skip to the boxing section.

Value types

In C#, value types are structs. Primitives you’re very familiar with like integer, float, and Guid are structs, as well as the ones you may define yourself. If you pass a struct as a parameter to another method, that method gets a copy of that struct – not the original struct. Consider this example:

static void Main() {
   int seeds = 5;
   AddOneSeed(5);
   Debug.Assert(seeds == 5);
}

static void AddOneSeed(int seeds) {
   seeds++;
}

The AddOneSeed method received a copy of the integer, which is a struct. Therefore any changes it made do not propagate back to the caller. Note that if a “ref” keyword is added to the parameter in the method’s signature that the method accesses the caller’s original struct instead of a copy, allowing the method to modify its caller’s value.

Value types store their data directly in their container. In the above case, the value types appear as local variables within methods, so the data of these value types is stored directly on the stack of the thread executing these methods. This also means that value types can vary in size, and the container must know exactly how large the value type is so that enough memory can be allocated for it.

Reference types

In C#, reference types are classes. Reference types store their data on the heap, and anyone holding a reference type is actually just holding a reference: a memory pointer to that object on the heap. Classes may contain structs as fields. This means that value types may actually appear on the heap. Consider this simple example:

class Fruit {
   int seeds;
}

Fruit is a reference type that contains a field that is a value type. This value type always appears on the heap because it’s within an object on the heap. The memory allocated on the heap by the Fruit object actually includes the value type directly. In the case of Fruit above, the object on the heap is 12 bytes in size: 8 for the CLR header that exists for every object, and 4 more bytes for the seeds field.

Boxing: When a value type becomes a reference type

Sometimes a value type must be represented as a reference type. The CLR allows anything to be represented as a System.Object. But System.Object is a reference type. Anyone with a reference to Object expects it to be a pointer to an object on the heap, and the size of Object to the holder of the reference is always 4 bytes regardless of the size of that object on the heap (or 8 bytes in a 64-bit process). How can a value type, which may vary in size, be assigned to a System.Object, which is always exactly 4 bytes? Boxing.

Boxing happens when the compiler has to assign a value-type to a reference type. When boxing, the CLR allocates a new object on the heap just large enough to store the particular value type being boxed, and copies the value type into that object. Now the reference to that object can be passed around simply as System.Object without anyone knowing how large the object really is. To actually look at the value type again, it must be unboxed, where the value is copied back onto the stack, and possibly into a field typed as the matching value type.

Let’s consider the simplest example of boxing. We have an integer value type on the stack as a local variable in this method. Then we assign this value type to a reference type. IComparable is an interface. Value types can implement interfaces. But as soon as you refer to the value type by an interface it implements it gets boxed. Check this out:

static void Main() {
   int number = 5;
   IComparable comparable = number;
}

The C# compiler compiles the above code to the below IL:

.locals init (
        [0] int32 number,
        [1] class [mscorlib]System.IComparable comparable)
nop 
ldc.i4.5 
stloc.0 
ldloc.0 
box int32
stloc.1

It’s not important that you understand all the IL, but notice the box instruction. This tells the CLR to allocate an object and copy the value at the top of the stack into it, and then push a reference to that object onto the stack in its place. The last instruction then assigns that object reference into the local variable typed as an IComparable.

But wait… if a struct implements an interface already, why does it have to be boxed when it is assigned to a variable typed as that interface? The answer lies in its size. Anything can implement an interface (struct or class), and sizes can vary. But folks holding a reference to an interface have to know in advance how much space to allocate for that reference. Since value types vary in size, value types don’t qualify. Instead, when you’re dealing with interfaces you’re always dealing with reference types, meaning that value types get boxed inside an object on the heap as a reference type.

The important thing to realize here is that although the C# code did not have a new keyword anywhere, an object was allocated anyway. This is under-the-covers magic by C# and the CLR so that things just work, and normally it’s a good thing. But this is a post on GC pressure, so of course we’re going to study how boxing can work against you, and how you can avoid it.

How to avoid boxing

The easiest way to avoid boxing is to always refer to a value type by its concrete type rather than by System.Object or an interface the value type implements. You can still call methods on that struct that implement interfaces just by calling those methods directly. For example, consider these two calls to CompareTo:

static void Main() {
   int number = 5;

   // CompareTo is found on the IComparable interface
   IComparable comparable = number; // box number
   int result = comparable.CompareTo(8); // box 8

   // CompareTo is also a public method on int directly.
   // In fact two overloads of CompareTo are available
   // on int, one that takes System.Object and another
   // that takes an int, so the C# compiler will choose
   // to call the one that takes int, avoiding both 
   // boxes that the above example causes.
   int result2 = number.CompareTo(8);
}

The example demonstrates two things. First is the discrete second boxing that can happen. Once we’ve boxed the int to an IComparable, there is only one CompareTo method for the compiler to choose from: CompareTo(object). That means that in addition to having already boxed the 5, the 8 must also be boxed in order to call CompareTo(object). On the other hand, leaving 5 as an integer avoids the first box, and allows the CompareTo(8) method to bind to int.CompareTo(int), which means the 8 can also remain as a value type. To better understand what is happening, consider how the Int32 and IComparable types are defined:

public struct Int32 : IComparable, IFormattable, IConvertible, IComparable, IEquatable {
   public int CompareTo(int value);
   public int CompareTo(object value);
}

public interface IComparable {
   int CompareTo(object obj);
}

As you can see, when you have an IComparable reference, all the compiler can do is call CompareTo(object). But when you have an Int32, you also can call CompareTo(int) and avoid both boxes.

Keep in mind as well that returning a value type from a method whose signature returns an interface also boxes:

static IComparable GetNumber() {
   return 5; // boxed!
}

Some pathological cases

An occasional box here and there isn’t going to hurt the performance of your app. But there are some things you can do that can lead to enough boxing to really hurt in frequently called code.

Boxing in a loop

Suppose you have no choice but to box a value type to call a method that takes an interface. If you were calling that method in a loop with the same value type each time, you can take care to avoid boxing for each iteration of the loop.

static void BoxEachIteration() {
   int number = 5;
   for (int i = 0; i < 500; i++) {
      Work(number, i);
   }
}

static void BoxJustOnce() {
   int number = 5;
   IComparable boxedNumber = number;
   for (int i = 0; i < 500; i++) {
      Work(boxedNumber, i);
   }
}

static void Work(IComparable number, int iteration) {
}

Boxing in non-mutating methods

When you implement public methods that don’t mutate state, you should generally be very careful not to box at all. For example, folks expect that retrieving a value from a dictionary should have no side effects including not allocating memory. This is important because your cheap, non-mutating methods are often the ones that end up being called in loops which may end up being perf critical to the application.

Earlier this week I investigated a performance problem that I found was due to GC pressure caused by a hashtable-like collection that boxed in its Get method. Ouch. Here was the Get method:

public T Get(string key)
{
    return this.Get(new KeyedObject(key));
}

There's a new keyword there, but KeyedObject was a struct, so supposedly no heap allocations there. But it gets more subtle. Take a look at how the struct is defined, and how the Get overload that is being called is defined:

private struct KeyedObject : IKeyed
{
    private string name;
    internal KeyedObject(string name);
    string IKeyed.Key { get; }
}

public T Get(IKeyed item)
{
  // ...
}

Do you see the problem? Although the Get(string) method creates a struct, which doesn’t cause GC pressure, it then passes that struct to a method that accepts an interface. That struct implements that interface, so while the C# compiler allows it, it first has to box the struct, which means all the work the authoring developer went to by using a struct to avoid allocations didn’t actually avoid the allocation after all. Since this Get(string) method was being called thousands of times in this perf critical scenario, we were generating garbage like crazy and the GC had to keep interrupting the app to clean up.

One possible fix to this is to add a Get(KeyedObject) overload that does the work directly with the value type. Then the C# compiler would call that one instead of the one taking the interface, and the boxing would disappear.

Non-generic collections

Generic collections aren’t just sugar. They can help performance tremendously. Consider a table of value type pairs. If you use the non-generic Hashtable collection, where keys and values are typed as System.Object, each key and value must get boxed before storage. That at least is a somewhat fixed cost – it’s not directly garbage because the box is persistent for as long as that entry is in the collection. But now think about every lookup operation. Let’s say you have a hashtable where the keys and values are both integers. You have a key and you want to look up the value. You are compelled to box the key first, making it impossible to query for values without allocating memory.

var table = new Hashtable();
table[5] = 8; // boxes 5 and 8
int value = (int)table[5]; // box 5 (again)

If on the other hand you use Dictionary<int, int>, all the internal storage mechanisms and methods are strongly typed to take and return integers rather than System.Object, so no boxing occurs. This can have a dramatic impact on performance due to GC pressure as well as memory availability since each integer takes only 4 bytes in memory instead of the minimum 12 bytes required by every GC heap allocated object.

Should I define my type as struct or class?

That’s a broad question and there is more to consider than GC pressure when making this decision. In my personal experience, almost every time I’ve nobly started with a struct I’ve ended up converting it to a class. So my personal default is to use class unless struct is required. There are several reasons for this, but most pertinent to this post are two things to consider:

Structs allow you to allocate and pass around the values without allocating memory on the heap. Classes must always be allocated on the heap.
Structs can be boxed many times, but classes will only allocate memory once.

Every time you assign a struct such that boxing is required, a new object is allocated. So the same struct can actually end up acquiring lots of memory and producing lots of garbage. Whereas if you’d just chosen to use a class, the memory is allocated once and shared across all who reference it. So be careful when you define structs and ask yourself how folks with that struct will use it. If the likelihood is high that most instances of the struct will get boxed sometime in their lifetime, consider making it a class instead to help keep the GC pressure down.

GC pressure series: Introduction and enumerators

2012-06-08T14:50:00.001-07:00

As you may already know, I’m a Microsoft developer who works on Visual Studio. Improved performance and responsiveness is a major goal for the 2012 release. As much of the new code in Visual Studio 2012 was written in C#, I learned a lot about how much GC pressure can degrade performance.

Q: Wait. What is GC pressure?

A: GC pressure happens when your .NET application produces lots of “garbage” by allocating and releasing memory. .NET has to “collect” all this garbage periodically by walking your application’s memory graph to determine which objects are still used and which have become garbage, then the memory for the garbage is freed.

Q: Right. That’s what garbage collection is all about. So what’s the problem?

A: Normally the CLR’s heuristics for finding good times to pause your application to perform GC gives your application a lean memory footprint and high responsiveness. The problem comes when you’re in a performance critical section of code in your application, perhaps in a loop of some kind, and within that section you’re producing and discarding lots of managed objects. This causes “GC pressure” which leads .NET to interrupt your perf critical code to run the GC in order to keep your application from running up its memory use, which besides potentially slowing down the machine overall, can eventually lead to an OutOfMemoryException. The heuristics of .NET’s GC are complex and beyond the scope of my blog.

Q: How do I know if GC pressure is responsible for my performance problems?

A: Like most performance investigations, you find out that GC pressure is your problem by measuring using some profiler tool and noticing that native callstacks are executing while you’re allocating memory that include GC code.

For instance, some large Visual Studio solutions I measured were spending around 30% of the time simply running the GC. Imagine if I could wave a wand and make VS 30% faster. That would be significant, right? The good news is that GC pressure is very often a solvable problem. In several upcoming blog posts, I’ll review several discrete sources of GC pressure that are easily solvable, and which allowed us to greatly improve solution load performance (and other scenarios) significantly.

Enumerator structures vs. IEnumerable<T>

It’s often good design to use types that are only as specific as needed. For instance, your public methods should typically take IList<T> instead of List<T>. This allows others to call you with a custom list implementation if they need to. But this can actually cause GC pressure if you use a C# foreach to enumerate the list. Consider the following:

static void Main() {
   var numbers = new List<int>(new[] { 1, 2, 3, 4, 5, 6, 8 });
   foreach (var number in numbers) {
   }
}

In this case, the C# compiler knows that foreach is enumerating the List<int> type. The public List<T>.GetEnumerator() method returns a List<T>.Enumerator, which is a struct rather than a class. This means that C# can generate IL that enumerates the collection without allocating any new objects on the heap: no garbage. But now consider a only slightly different case:

static void Main() {
   IList<int> numbers = new List<int>(new[] { 1, 2, 3, 4, 5, 6, 8 });
   foreach (var number in numbers) {
   }
}

The only different is that I’ve explicitly typed the List<int> into an IList<int> local variable. Now when C# enumerates the list with foreach, the only GetEnumerator() method available to call is the one on IList<T>, which returns an IEnumerator<T>. This is typed as an interface, not a struct. Although the underlying List<T>.GetEnumerator() will still be invoked, the struct it returns will now have to be boxed so that it is addressible via its IEnumerator<T> interface. This boxing allocates an object on the heap, which will be discarded after the enumeration is over. If this foreach was itself in a perf critical loop then this could be a significant source of GC pressure.

To wrap up with a final comprehensive example, here are two methods you might define:

static void GarbageProducer(IEnumerable<int> numbers) {
   // numbers.GetEnumerator() can only returned a (boxed)
   // instance of IEnumerator<int>, forcing this method to
   // allocate one object each time this method is invoked.
   foreach (var number in numbers) {
   }
}

static void NoGarbageProducer(List<int> numbers) {
   // numbers.GetEnumerator() will return the stack allocated
   // List<int>.Enumerator struct, so no allocations are required.
   foreach (var number in numbers) {
   }
}

In the above snippet, GarbageProducer allocates memory, but its parameter is typed for maximum portability, whereas NoGarbageProducer never allocates memory but requires a very specific collection type to be passed in. Which is better? That depends, of course. If the method is private, and you’re passing in a List<int> anyway, by all means keep the parameter typed as List<int> and avoid the allocation (in perf critical code anyway). If the method is public you should probably use IEnumerable<T>. Yes, it almost guarantees an allocation will be required, but on the other hand it allows virtually any type of collection to be passed in. If you take List<T> and the caller only has a T[] array, the caller would first have to convert the array to a List<T> instance and then pass it in, and that’s much more costly to memory.

I did say “almost guarantees” an allocation. Can it be avoided? Yes, actually. With some extra work within the method:

static void NoGarbageProducer(IEnumerable<int> numbers) {
   List<int> optimizedCase = numbers as List<int>;
   if (optimizedCase != null) {
      foreach (var number in optimizedCase) {
         DoWork(number);
      }
   } else {
      foreach (var number in numbers) {
         DoWork(number);
      }
   }
}

private static void DoWork(int number) {
}

Obviously this is more code to write and maintain, so it should only be done where measuring performance proves it is worthwhile. Note that it only makes the enumerating alloc-free when the collection passed in is actually a List<T>, otherwise it falls back to the one-allocation code path. This is an example of how you might discover you have a very popular method in a perf critical path, and perhaps you observe that you tend to be called with List<T> so you optimize for that case. You could even optimize for multiple specific collection types, so long as each of them implement the alloc-free struct GetEnumerator pattern.

A brief survey of the various .NET unit test frameworks

2012-05-28T10:58:00.001-07:00

In summary, someone please fix NUnit to support async task methods.

MSTest

Pros: Best IDE experience for VS2010 and earlier (VS 2012 supports MSTest and other frameworks equally).

Cons: It requires an expensive product to develop and run. ExpectedExceptionAttribute considered harmful.

NUnit

Pros: Supports Fluent syntax. Attributes can specify that tests require STA, MTA, etc.

Cons: No support for “async Task”. Reuses test class instance for all tests within that class.

xUnit

Pros: Very few attributes keeps it simple. Straightforward use of constructors and Dispose methods to wrap tests.

Cons: Assert.Equals doesn’t allow accepting a formattable message to provide a more useful failure message. No Assert.Inconclusive.

How to get meld working with git on Windows

2011-10-02T15:24:00.001-07:00

Inspired by these instructions, I followed these steps:

Install Python 2.6
Install PyGTK All-in-one installer
Install meld

Then you need to configure git to be able to find and invoke meld. If you’re using the git bash shell, this can be done with these commands:

PATH=$PATH:/c/python26
git config --global merge.tool meld
git config --global mergetool.meld.path /c/Users/andarno/Downloads/meld-1.5.2/bin/meld

Of course you may want to set your PATH to include Python permanently rather than the above command which only works for your active window. The two git config commands have a persistent effect already, however.

Finally, you’re now ready to use meld to resolve merge conflicts. I haven’t found a way to get “git gui” to invoke the merge tool correctly, but this command from the git bash shell works great:

git mergetool

Immutable collections with mutable performance

2011-08-29T20:49:00.001-07:00

In my last post, I detailed the differences among read/write, read only, frozen and immutable collection types. I described how immutable collections come with a hit to the garbage collector due to the garbage they generate during mutations. I have a very positive update on that topic.

See my update on my Microsoft blog for the update.

Read only, frozen, and immutable collections

2011-08-21T16:15:00.001-07:00

[Update: a more recent post with new data on attainable performance of immutable collections]

The topics of immutability and functional programming has fascinated me lately. Mostly because of my work on the Visual Studio Common Project System (CPS) which is a large, highly multi-threaded code base that only remains sane because of its reliance on immutable types in many areas.

In my research and conversations on this topic, I’ve learned to appreciate the differences between several adjectives often used interchangeably among programmers that I’d like to share with you, detailing the differences including some pros and cons of each. At the bottom of the post I include a summary table and my own personal verdict for what kinds of collections (mutable and immutable) I prefer.

Although the principles here apply to any type in any language and platform, I’ll be using for some references and examples the collection types in the .NET base class library.

First a little terminology as I will use it in this post:

Mutable (a.k.a read/write): a collection or type that allows for in-place updates that anyone with a reference to that object may observe.
Immutable: a collection or type that cannot be changed at all, but can be efficiently mutated by allocating a new collection that shares much of the same memory with the original, but has new memory describing the change.
Freezable: a collection or type that is mutable until some point in time when it is frozen, after which it cannot be changed.
Read only: a reference whose type does not permit mutation of the underlying data, which is usually mutable by another reference.

The de facto read only standards in .NET

There are not yet any freezable or immutable collections included in the .NET base class library. But we have a couple of read-only views of data, as outlined below.

De facto standard #1: IEnumerable<T>

Often considered a convenient way to express data in a read-only way, IEnumerable<T> actually provides very few, if any, guarantees and almost no protections.

NO thread-safety to issuer or receiver. If the underlying collection changes while being enumerated from another thread, data corruption may result or exceptions may be thrown.
NO immutability guarantee to the receiver. The underlying collection may be changed.
NO immutability guarantee to the issuer. The receiver may cast the enumerable to ICollection or some other read/write type and may mutate the data through that interface if the underlying object allows it.
NO performance guarantee to the receiver. The enumerable may represent a deferred execution query (LINQ for example) that may incur significant cost including network overhead with each enumeration.

Avoiding these shortcomings usually requires enumerating exactly once into a cloned collection, which comes with a perf and memory hit, and doesn’t entirely protect you from thread-safety issues that may occur during that one enumeration.

De facto standard #2: ReadOnlyCollection<T>

Somewhat misleadingly named, this collection is neither immutable nor a general collection. It is merely a wrapper around a mutable list. Perhaps a more accurate name would be ReadOnlyListFacade<T>.

This collection type is better than IEnumerable<T> in several ways, but still deficient in others:

YES, immutable guarantee to the issuer. The collection owner never releases a reference to the mutable collection, as the ReadOnlyCollection<T> is a genuine wrapper around the mutable data, making it impossible for a receiver of the collection to mutate the data.
YES, thread safety to the issuer, since the receiver cannot mutate the data, the underlying collection may be mutated without fear that the issuer with throw an exception or corrupt its own data.
YES, reasonable performance guarantee to the receiver. The IList<T> that the ReadOnlyCollection<T> wraps is virtually never populated via deferred execution. Therefore enumerating the ReadOnlyCollection<T> repeatedly can generally be done with high performance and without side effects.
NO thread-safety to the receiver. If the receiver is reading the ReadOnlyCollection<T> while the issuer is mutating the underlying collection, the client may get an exception or perhaps even incorrectly perceive the contents of the collection.
NO immutability guarantee to the receiver. The underlying collection may be changed.

Considerations among collections

Thread-safety

Collections that are not thread-safe cannot be made thread-safe in a shareable way. For example, although you can put lock { } statements around all uses of a collection to make it thread-safe, you cannot share references to your collection or any part of it outside your class because outside holders of that reference will not synchronize access to it with the same lock object you do (and ICollection.SyncRoot seems increasingly unpopular if it were ever known at all). This suggests the importance of thread-safety built into collection classes.

Freezable collections

There are no freezable collection types in .NET (yet anyway). So a discussion on them is somewhat speculative. If the traditional List<T> class were to pick up a “Freeze()” method and an “IsFrozen” property, there would still be missing a type-safe way of communicating that a method expects or returns a frozen collection. You would have to perform a runtime check to see what is allowed or provided. Collection types that guarantee immutability are preferable for this purpose. If a method accepts an immutable collection parameter or returns an immutable collection, you have 100% confidence that that collection cannot ever change, period. If a List<T>.Freeze() method returned a FrozenList<T> object, and both the original List<T> and the FrozenList<T> pointed to the same data structure that could no longer be changed, that would provide a type-safe way of requiring or guaranteeing immutable data, however.

While one might consider that guarantee more theoretically aesthetic than practically useful, I can speak from some experience now that I avoid a lot of collection cloning code (and the perf problems that showed up as a result) because I know that a collection I just received cannot possibly be changed. It’s gotten to the point that when I see a method accepting an IList<T> I ask myself “Why? Is that method expecting the caller to further mutate that list during or after its invocation and that the method will need to see that mutation?” Call me a functional programming geek, but if a method does not expect the caller the tamper with a collection that it passes to the method, I now greatly prefer to see IImmutableList<T> as the method parameter.

Before freezing, freezable collections offer the high construction performance and compact memory utilization of traditional mutable collections. After freezing, any further mutation requires shallow cloning of the entire collection, with the perf and memory hit that comes with it.

One possible danger of using a collection that is freezable (but unfrozen) is that someone you share a reference to the collection with might want an immutable copy of the collection and may freeze the collection behind your back, not realizing that your class still “owns” the collection and thus expects it to not be frozen.

Performance

The performance of mutable collections, particularly when they are initially sized adequate for their contents, can’t be beat by immutable collections. However the performance of immutable collections can be remarkably good. Much better than one might expect, and certainly good enough for due consideration in your design.

Immutable collections primary shortcoming is that raw add performance tends to be 2-3X slower than the amortized cost of its mutable collection counterparts. This is chiefly due to the mandatory “spine rewrite” of the binary tree and the memory allocations that go along with it. I just compared against amortized cost of mutable collections because mutable collections have the shortcoming of occasionally breaking the bounds of their pre-allocated memory, which usually means allocating twice as much and then copying all the data from the old location to the new location.

Before you write off mutable collections due to their perf impact on initialization, keep in mind that this may rarely be where the performance problems in apps come from. In my experience the perf problems never come from creating a new collection, but rather from cloning a collection within a lock to provide immutability and thread-safety guarantees, which completely vanish when you switch to genuinely immutable collections. Also, the spine rewrite that leads to the slower fill performance can be avoided by using an immutable collection that optimizes around that scenario, as described in the below discussion on garbage collection.

Memory efficiency

When dealing with collections, there’s no tighter data structure than an array, which is the underlying data structure of choice for must flat collections. It has almost no overhead beyond the data stored, and that’s hard to beat. On the other hand, since arrays have fixed size, it usually means there is memory wasted in the slack between the last element in the collection and the last slot in the preallocated array. And when you have more elements than you have slots in the array, the array growth algorithm tends to be to allocate a new array of double the length and move all the data over, which means even more slack space wasting your memory.

Immutable collections can’t afford (in memory or performance) to use arrays because changing the collection would require cloning the array every time. Instead, performant immutable collections can use binary trees that allow for incremental, non-mutating updates to the collection. Without going deep into the theory of it, it allows (for example) an immutable collection of 500 elements to be mutated into a new collection with one element added or removed while sharing almost all the memory between the two collections. But because binary tree data structures require a heap-allocated “node” to represent each element in the array, with references to two other nodes in the tree, there is an overhead of at least 12 bytes per element in immutable collections.

Garbage generation and collection

Garbage generation is also an important concern when considering the memory impact of immutable collections. Every mutation of an immutable collection necessarily allocates more memory. And while most memory is shared across the different versions of the collection, when a particular version of a collection is no longer referenced, it automatically gets garbage collected. This is a convenient feature of immutable collections in that they optimally share and automatically free memory. However, since each mutation of the collection makes the last version of the collection uninteresting and thus available for garbage collection, it generally means that more garbage is produced than for the mutable counterpart.

What’s the problem with allocating objects if they are freed as soon as they are not used any more? The problem comes at garbage collection time. The more memory you allocate and release, the more frequently the garbage collector has to run, which usually suspends all other threads in your .NET application, potentially causing perf problems during or sometime after all that memory had been allocated and freed.

This garbage collection pain is usually most poignantly felt when initializing very large immutable collections. Without appropriate optimizations for this scenario, a large immutable collection will produce many times as much garbage during construction as its own final size in memory at completion. So if you built a collection that requires 1MB of RAM just for the collection itself, you might have just blown through 4MB of RAM during its construction (freeing 3MB immediately after). A well-written immutable collection class could optimize for this initialization case by allowing itself to reuse (i.e. mutate) tree nodes during initialization only, when such reuse could never be detectable outside as a “mutation”, which would solve the garbage generation problem for immutable collections, unless your collections tend to mutate very rapidly even after initial construction.

Summary

	Read only	Frozen	Immutable
Capabilities
Thread-safe	No	Yes	Yes
Type-safe declaration	Yes	TBD	Yes
Immutable guarantee	No	Yes	Yes
Allows mutation	Yes, shared	No	Yes, isolated
CPU
Isolated mutations performance	Poor	Poor	Great
Shared mutation performance	Great, except when underlying data structure is outgrown and must be cloned.	N/A. No mutations allowed.	N/A. All mutations are isolated.
Memory
Storage data structure	Array	Array	Binary tree
Memory across isolated versions	Full duplication	Full duplication	Efficient sharing
Garbage generation	Low	Low	Potentially high [update]

If you enjoyed this post, you may enjoy Eric Lippert’s blog posts tagged Immutability. Eric Lippert wrote a good post on different kinds of immutability back in 2007.

And please let me know if you found this post useful or interesting.

C# await for MSBuild

2011-07-16T08:33:00.001-07:00

The async CTP that adds the C# await keyword doesn’t include an awaitable MSBuild. It’s easy to add yourself. Just copy and paste the the BuildSubmissionAwaitExtensions class from the code below somewhere in your project and you’ll be able to await on MSBuild. Also included below is a sample of what it might look like.

C# await for WaitHandle

2011-07-15T10:37:00.001-07:00

The async CTP that adds the C# await keyword doesn’t include an awaitable WaitHandle. It’s easy to add yourself. Just copy and paste the following code somewhere in your project and you’ll have an awaitable WaitHandle.

Warning: don't use this on AutoResetEvents, or the behavior may not be what you expect.

What is 2-legged OAuth?

2011-06-13T08:22:00.002-07:00

Although there is an official spec for OAuth 1.0, the spec only outlines what the community refers to as "3-legged OAuth". An alternative form of OAuth is loosely referred to as "2-legged OAuth", and there are far too many variants of this and not a single finalized spec to conform to. As a result, there are various ways and forms to achieve what people, correctly or incorrectly, refer to as 2-legged OAuth. In this post, I will attempt to clarify what (at least in my mind) 2-legged OAuth really means.

I will not delve into the gritty details of the spec, but I will outline the flows and explain a bit.

3-legged OAuth

First, let's start with the spec's description of the OAuth flow (3-legged). Here is an illustration:

You can clearly see the 3 "legs" of this flow:

The consumer (the application that wants to access data) creates an OAuth session by obtaining an unauthorized request token from the Service Provider (the host of the data).
The consumer directs the user to the service provider, with the unauthorized request token in hand, so the service provider can ask the user to release the protected data to the consumer. The user logs in as necessary, and grants the requested permission. The service provider redirects the user back to the consumer.
The same request token the consumer held before is now authorized. The consumer submits it to the service provider in a direct web request to exchange it for an access token.

The access token may now be used by the consumer to submit requests to the service provider that will access the user's private data.

By the way: notably absent from this 3-legged flow is the consumer obtaining its own "consumer key" and "consumer secret". The process of obtaining these is explicitly outside the scope of the OAuth spec altogether, and is therefore defined by each service provider. This process is only completed once per application, usually by the application developer him/herself, and is not considered one of the legs of OAuth.

2-legged OAuth

In 2-legged OAuth, the consumer tends to be installed on the user's machine, or is perhaps a widget embedded in a web page. The key scenario difference as you step into 2-legged OAuth is that the consumer is not requesting access to any user data. Instead, it is merely establishing an account with the service provider with no previous data in it at all, which it can subsequently use to store and later retrieve data.

However, since this particular installation or widget has its own "space" on the service provider to store data, the consumer can obtain user data directly from the user him/herself, and send that to the service provider, and later retrieve it. So we see that although 2-legged OAuth doesn't start with any user data, it may end up with user data that the consumer itself puts there.

Because no pre-existing user data is ever shared with the consumer, there is no need for the service provider to obtain authorization from the user. Therefore the second of the three legs can be entirely skipped. The modified flow is illustrated here:

Note that the "6.2" section is absent, and the User role has absolutely no interaction, leaving only two legs. Section 6.1 is also slightly different: instead of the service provider issuing the consumer with an unauthorized request token, this request token is pre-authorized. The consumer can then immediately exchange it for an access token and discard the request token.

At this point you may be saying to yourself: "That's silly -- why doesn't the service provider just issue the access token instead of a request token, and save another leg?" Well, it could, but then that wouldn't be OAuth any more. You could make the case that the above 2-legged flow is still OAuth because all the existing APIs and flows work as spec'd... the skipped legs doesn't alter the remaining legs so it requires little or no changes in a standard OAuth implementation to support 2-legged as well.

What's not 2-legged OAuth

I've recently seen a list of links that all claim to describe "2 legged OAuth", but are nothing like what I just described. Instead, what they describe is what I would refer to as 0 legged OAuth. That's right: none of the 3 legs are preserved in the flow they describe. Here is what they describe, in a nutshell:

The consumer's developer obtains a consumer key and secret.
(skips the entire OAuth 3-legged flow here)
Consumer accesses protected resources by submitting OAuth signed requests for resources using its consumer key, an empty access token, and signs the request with the consumer secret and an empty access token secret.

Remember from the 3-legged discussion above, that #1 in this list is not considered one of the three legs: it's a one-time step taken by the app developer. Nor is #3 in this list considered one of the 3 legs, as it is simply the actual request for the protected resource, and is alone repeated at each request.

Also consider that whereas genuine 2-legged OAuth can end up with the consumer storing user data in a private consumer-user data store at the service provider, this 0-legged OAuth cannot end up with user data in its service provider account, because all instances of the consumer share exactly the same account, and that would mix all the users' data together.

This 0-legged OAuth should look remarkably similar to username/password authentication, and in flow that's exactly what it is, where the consumer app is the owner of the username/password instead of the user. Why would someone go to the trouble of using/inventing 0-legged OAuth instead of just using username/password then? Two reasons: 1) it may be easier to leverage existing OAuth-supporting code than adding support for username/password, and 2) OAuth provides signatures that mitigates against replay attacks that HTTP basic authentication can be vulnerable to.

What's else is not 2-legged OAuth

Twitter has an interesting special case of OAuth as well, which also entirely skips the 3-legged flow, yet it is still per user. The user navigates his/her browser to twitter.com, and obtains an access token directly, with no request token preliminary step. The user copies and pastes (manually!) this access token into the consumer app, which then simply access the user's private data without ever going through any of the 3-legged flow. This also has been (incorrectly) referred to by some as "2 legged OAuth", but I hope this discussion can help you see this is a misconception.

Summary

Let's summarize terms and use cases then:

3-legged OAuth: includes user authorization through a web browser for the consumer to access the end user's previously established private user data with a service provider.
2-legged OAuth: skips user authorization, but still has non-empty request and access tokens. Consumers gain access to an empty account that they may then fill with user data the consumer obtains directly from the user.
0-legged OAuth: skips all three legs by having consumers simply access their own protected resources at the service provider using OAuth signatures based on a private consumer key and secret. Analogous to username/password for the consumer app.
Twitter access token option: also skips all three legs, but still provides access to a user's pre-existing data via a non-empty, manually obtained access token.

Please comment with your thoughts, and indicate whether you agree or disagree. With so many application-specific half-specs out there claiming to describe "2-legged OAuth", I expect some comments to this post telling me I'm wrong. That's fine. I'd be interested in hearing you make a logical case for how you reduce OAuth 3-legs to 2-legs then. And to reiterate, I'm not invalidating the use cases of what these 0-legged flows are doing, I'm merely suggesting we call it like it is: "0-legged OAuth".

.NET Obfuscator Product Review

2010-10-14T07:10:00.000-07:00

CliSecure .NET Obfuscator Product Review

Forward

.NET assemblies are (in general) remarkably easy to decompile and obtain reasonably intelligible source code. A .NET obfuscator can be run as a post-build step to make decompiling the assembly much less useful to thieves who are trying to steal your intellectual property. There are many .NET obfuscators out there.

In this post, I review the SecureTeam CliSecure tool, version 5.2.0.7.

Introducing the test case

My “test case” DLL is not a simple “Hello, World!” app. It’s dotnetopenauth.dll, which is just over 1MB in size and pushes the limits of the .NET Framework enough that a few bugs in the CLR, compiler and build tools were discovered while this assembly was written. It defines its own .NET configuration sections, compiles with Code Contracts’ IL rewriter and ILMerge’s IL rewriter and is strong-name (delay) signed. It also very carefully uses log4net.dll when present, but doesn’t whine when the log4net is not present (defying most people’s assumptions about .NET’s runtime dependency rules). This DLL is enough to make most obfuscators fail in some way or another.

That said, the disclaimer is that this is just one test case, and is not intended to warrant or otherwise guarantee results on your own assemblies. Your mileage may vary.

Usability

Since in course of this review I was a relatively new user to this software, and usability most impacts a new user, I’ll start with usability. If you care more about functionality than usability, just skip this section. (Does anyone buy an obfuscator because it’s user-friendly?)

I find CliSecure easier than most obfuscators that I’ve tried, but it still has its oddities. Launching CliSecure opens a non-intimidating GUI application with few enough controls that it looks like something a newbie can get a handle on, and it sports the new Ribbon UI that’s been so hot lately.

But the first two buttons on the toolbar, New and Open, don’t apply to a first-timer. The app opens with a “New” project, so the New button is a no-op, and “Open” opens CliSecure projects, not DLLs to obfuscate. The next buttons, Save and Options, didn’t seem to apply either. Finally a small button called “Add” on the Ribbon suggests maybe that’s the one I was looking for. Bingo!

There’s a field at the bottom that displays a derived a sub-path where the obfuscated DLL goes. Cool. But when I changed the DLL I was obfuscating, the sub-path didn’t change with it automatically.

The Options button led to a dialog box with a grid and an explanatory paragraph for each configurable setting. Most of the explanations were adequate, although the most interesting one to me (Control Flow Obfuscation: Basic or Advanced) didn’t explain one over the other. The help documentation did include this detail including the the pros and cons of each option.

I found the Help documentation quite decent – complete with screenshots and explanation of the high level concepts needed to make informed obfuscation decisions.

Noteworthy features

Support for strong-name and delay signing.

Whirlwind obfuscation run

CliSecure has a whole array of powerful obfuscation options. But beware: they’re all off by default. When obfuscating with the default settings in CliSecure the assemblies selected are not obfuscated at all but success is still reported.

After setting some reasonable obfuscation options, clicking “Build” (the button isn’t called “Obfuscate”) resulted in a few seconds of obfuscation during which there was an accurate progress bar. When it was done, there was no output window, no warnings or errors, and the “building” window just disappeared. Fortunately, near the button of the CliSecure window is a field that says where the “secured” assembly will be saved to, and it’s conveniently a read-only text field so I can copy the path out into Windows Explorer to open that folder (a click button to open the folder would have been a bonus though).

While the CliSecure UI was up after obfuscating my DLL, I was pleased to see it didn’t have any open file handles to the input or output DLLs, so I could run builds in another process without having to close CliSecure first.

CliSecure obfuscation settings

There is a plethora of options offered in the GUI app (all off by default):

Input. You can obfuscate several assemblies at once. Besides just batching for convenience, this should allow you to obfuscate internal members without breaking other assemblies with privileged InternalsVisibleTo allowing them to call these internal members.
Code Protection. This is probably the most unique obfuscation feature in CliSecure, and truly worth your careful consideration. It actually encrypts your IL and makes it completely invisible to .NET Reflector, only decrypting the IL at execution time at a per-method level. But this decryption requires that your app run with Full Trust, which means you can’t use it on assemblies you send up to a shared host web server, among other things. But it should be fine for an assembly that you ship to a customer. This comes with a performance hit to the app, however.
Renaming. This performs the most basic obfuscation function: renaming of types and members. CliSecure even will rename your “public” API and fix up any assemblies that call into that assembly. A great way to protect your own “internal” class libraries used by your multi-assembly application. It helps you get away from InternalsVisibleTo, which some argue encourages bad design.
Control Flow. Changes the idioms that compilers use for looping constructs, breaking a decompiler’s ability to reconstruct for and while loops.
Method Call Obfuscation. This feature protects the public APIs that your assembly calls in other assemblies. Depending on what you’re trying to obfuscate, this feature can be very important. Without it, every call to a method in .NET’s base class library will be apparent when people decompile your code, making it easier to figure out what you’re doing. CliSecure will replace these discoverable calls with dynamically generated delegates so a static analyzer or decompiler cannot discover them. This comes with a performance hit to the app, however.
Merging. CliSecure comes with ILMerge-like behavior built-in, allowing you to conceal even more code by merging your helper library .dll with your application .exe and thus removing all the public surface area your library would have otherwise left exposed.

For my next test, I turned on everything except Code Protection or Method Call Obfuscation so I could still use .NET Reflector to see what obfuscation had taken place (and because DotNetOpenAuth.dll runs in shared hosting web servers and requiring Full Trust isn’t an option). I also didn’t use the Merging feature. Although DotNetOpenAuth uses ILMerge and could therefore possibly benefit from this feature, not every SKU of DotNetOpenAuth would be obfuscated, so making every SKU take a dependency on running CliSecure doesn’t make sense.

Obfuscation quality

With so many protections turned on, obfuscation took a few seconds to complete this time. In .NET Reflector I saw just the public namespaces, and within those just the public types and members. All the obfuscated stuff was under the default (empty) namespace in a flat structure. Not only is this good for obfuscation, it’s good for the stuff that you want to be discoverable because all the obfuscated stuff doesn’t clutter up the stuff you want to be discoverable. Extra points for clean discoverability of public stuff.

The internal types were mostly obfuscated, with the necessary exception of the members that implemented public interfaces, and some internal types that are used to implement .NET .config file sections. I think these could have been obfuscated and were not, but configuration section types aren’t typically where people store their sensitive intellectual property anyway. Some of the types and members had such weird names that .NET Reflector crashed a few times as I was looking through the assembly. That’s just a bonus (since it discourages those snoopers).

Some methods were so obfuscated that .NET Reflector gave up on their implementations:

Others were decompiled, but quite uselessly so:

While most of this is unintelligible, I did manage to read that an HtmlLink object is instantiated here, which is puzzling since I turned on Method Call Obfuscation and thought that this type of thing would be hidden. I also found some internal strings that didn’t appear to have the obfuscated/encrypted values I expected since I turned on “String Obfuscation”. That said, .NET Reflector was unable to analyze where these strings were used, so that’s a half-win.

The bizarrely named methods were no more intelligible when you use .NET Reflector’s click-through to see the method implementation: the method “implementation” is merely a static field that holds a delegate and is initialized somewhere else that isn’t evident.

I’d give the obfuscator effectiveness a rating of 9.5/10. Yes, there were a couple words I could read here and there and the unobfuscated configuration section types, but it seems impossible to reverse engineer, and it obfuscated the names of properties, which other obfuscators say cannot be done. And remember, I haven’t even turned on Code Protection, which presumably would give it, what, a score of 15/10?

Verifiable Code

This is the trip cord for almost every obfuscator. If “peverify.exe” reports no errors on the original assembly, an obfuscator must produce a verifiable obfuscated assembly. Also, if the obfuscator injects code into the assembly that generates and executes IL at runtime, this code must also be verifiable (although peverify.exe cannot validate this unfortunately).

CliSecure passed this test by generating verifiable code when Renaming, Control Flow and String Obfuscation were turned on. But it generated 32 peverify errors when Method Call Obfuscation was turned on, and 2 more peverify errors when Code Protection was added. Since these two protections also impact performance and require the protected app to run with full trust, leaving these two protections off anyway makes sense for me. But for apps that would like to use these protection mechanisms the peverify errors they cause could cause verification/test issues at best and runtime failures at worst.

Does it run?

So although CliSecure passed the peverify.exe test, would the assembly actually run when dropped in-place of a non-obfuscated DLL? I had to find out.

I built the entire solution of DotNetOpenAuth and all its samples. Since CliSecure didn’t rename public types and members, a post-build in-place obfuscation should theoretically keep the sites working. Some of these sites are configured for only ASP.NET Medium Trust, so it would help validate that the obfuscator continues to run under this permission level as well.

Verdict: the obfuscated assembly appears to work. I qualify with “appears” to work because it’s a very complex assembly with many code paths and I haven’t finished testing all of them. But the core scenario works.

Debugging support

Any time you obfuscate an assembly you make debugging more difficult. The end user may report callstacks that are totally useless both to your user and to you! A good obfuscator will provide a way for you as the code owner to de-obfuscate stack traces, or even interactively debug your assembly with a reasonably similar experience to an unobfuscated assembly (provided you have the source code).

Amazingly enough, the obfuscated DLL was still debuggable using the original .pdb symbols file. The callstacks were obfuscated but stepping through the code still worked when the source code is available. Not all the breakpoints seemed to fire which may be a VS2010 bug or a bug in the obfuscation I don’t know. But stepping over and stepping into worked great once the debugger was stopped.

The callstack de-obfuscator failed, in that the callstack it generated was still illegible. That’s a real bummer when customer reports come in with a callstack that you then need to decipher.

Command line obfuscation support

CliSecure comes with a command-line version of their tool that takes all parameters at the command line, or takes a convenient single parameter that is the CliSecure project file that contains all the details within it. While there is no MSBuild task included, the command line syntax seems simple enough that an MSBuild “Exec” task could easily handle kicking off the process as part of an automated build.

Summary

This is by far the most feature rich .NET obfuscation tool I’ve seen. Its obfuscation protections are superb, even with the couple of semi-faulty options turned off. Debugging is pretty good, although de-obfuscating callstacks needs some work. During this review the SecureTeam behind the product were very responsive and fixed many bugs I reported rapidly, so I fully expect a new version coming near you will fix the remaining issues.

Review on the Dell Studio 15 laptop

2010-07-02T06:54:00.001-07:00

So I bought a new laptop from Dell two weeks ago. Here are the highlights:

The good

Very speedy (of course I paid for that).
Sleep/wake finally works well. Waking is very fast, and actually reliable!
The propping back legs on the laptop are conveniently placed and the heat on the underside of the laptop are also lending to holding the laptop on your lap without getting hot spots on your legs.
The face recognition auto-login feature is cool, but I suspect a photo of me would log me in, which makes it more of a toy than a tool.
I like the backlit keyboard. And the touchpad has two-finger zoom (which can be disabled) and a scroll circle feature which is pretty cool (although I haven’t used it).
It’s remarkably lightweight, especially considering how souped up the hardware is.

The Bad

When left on for long periods, the mouse touch pad grows to be burning hot, making it unusable.
It didn’t come with a TPM chip. These things were invented and shipping in laptops years ago. What’s up with that?
No room for a smart card slot, that combined with no TPM chip, means I have to use a flimsy USB card reader to remote into work.
It doesn’t come with a Windows DVD, or software to burn a recovery DVD based on the backup partition on the hard drive.
No hardware lights for disk access, or caps lock or anything else. The lack of classic feedback for whether the computer is busy is a little unnerving.
When the caps lock key is pressed, a small display appears that permanently steals focus from the active window (at least when you’re in Remote Desktop), so you’re typing away, press caps lock, and suddenly your typing isn’t going anywhere. Whoops.
The face recognition auto-login feature (and webcam) remains active while the screensaver is on. This keeps the CPU hotter than it needs to be, and it means if you approach your laptop (perhaps to see your loved ones in your photo screensaver) the screen saver exits and you get logged in. Where the real problem here though is that if the screen saver reduced your screen resolution and the face recognition auto-login exits the screen saver to log you in automatically, the screen resolution isn’t restored to normal, and the desktop is wacked.

The Ugly

The WiFi is very unreliable. It frequently drops the connection entirely and can’t find any hotspots. I have to disable/re-enable the Wireless Connection to get back online.
Bluetooth is even more unreliable. Pairing with my Bluetooth mouse was an exercise in patience. And it keeps losing the mouse, requiring a restart. In the meantime, most Bluetooth dialogs/windows hang, making troubleshooting the problem virtually impossible.
YouTube HD videos hang in the middle for minutes with a black screen mid-movie, and the video driver can otherwise randomly crash the machine for no apparent reason at all.

Verdict

I really like this laptop, but for me, the Ugly bits are deal-breakers. I rely on the Internet for most of my work, and my Bluetooth mouse is much more usable than a touch pad. When neither work well or reliably, the laptop is of very limited use. Tech support suggested I upgrade the drivers on my brand new laptop to resolve the problems, which doesn’t make sense to me anyway given they should have put the latest drivers on when they shipped it, but that didn’t help anyway.

DotNetOpenAuth v3.4.3 released

2010-04-13T21:50:00.001-07:00

DotNetOpenAuth has just seen a minor release to v3.4.3. Fixes center around corner case interoperability issues that cause a very small percentage (<0.5%) of OpenID users to be unable to log into your relying party web sites. A few other random fixes as well.

Go download it now.

The OpenID “dot bug”

The most noteworthy fix was a very difficult one to pull off, namely the bug where OpenIDs with trailing dots being unsupported. Back in the 1990s, classic ASP had the infamous “dot bug” where a trailing dot appended to a URL path would reveal the source code of the server-side script, which was a fatal security hole that was (of course) patched. I think that this might have inspired the .NET Framework’s Uri class design to include automatically removing trailing dots from each path segment in a Uri instance. Since FAT and NTFS file systems don’t support trailing dots on filenames, this doesn’t cause any issue if the web is run by Windows file systems.

But when these URLs are actually OpenIDs, and those OpenIDs contain path segments that are base64 encoded where one of the two assignable characters is a period (ala Yahoo’s pseudonymous OpenIDs), then approximately 1.5% of base64-encoded OpenIDs have trailing periods. So what’s the problem? When an OpenID positive assertion comes into an OpenID relying party web site based on .NET with a claimed_id that ends with a period, .NET will quietly strip the period from the claimed_id, causing the login to fail or (arguably worse) to succeed but with OpenID discovery misdirected to the wrong URL (one where the trailing dot is stripped).

The .NET Framework provides no (supported) way to turn off this dot-stripping behavior. If your relying party web site is running with Full Trust you can set some internal flags using reflection to suppress the behavior, but it has some nasty side-effects. If you’re on medium trust, you’re sunk.

But I’m pleased to say that DotNetOpenAuth has a solution, handling both medium and full trust, that is as good as the .NET Framework will allow until a fix in the platform is made. I won’t bore you with all the gory details on this post, but suffice it to say, that if you just download and use the new version, you’ll be working with OpenIDs even with trailing dots. Phew.

How to upgrade your Blogger OpenID to a decent one

2010-03-09T20:07:00.001-08:00

If you host your blog on Google’s Blogger service you may have discovered that your blog is an OpenID you can use to log into various web sites that act as OpenID relying parties. But Blogger’s support for OpenID is limited to OpenID 1.1, which is very old and not supported by many relying parties nowadays.

You can upgrade your Blogger hosted OpenID to the new OpenID 2.0 version and log into many more web sites, all while still using your Google account to log in, thanks to Google Profiles.

Here’s how to upgrade your Blogger OpenID to OpenID 2.0:

Create a Google Profiles profile if you haven’t already done so.
Visit http://www.blogger.com/, logging in if necessary.
On the blog you use for an OpenID click Layout.
Click Edit HTML.

In the Edit Template area, add the following HTML within the <HEAD> tag of your template:

<link rel='openid2.provider' href='https://www.google.com/accounts/o8/ud?source=profiles' /> 
<link rel='openid2.local_id' href='http://www.google.com/profiles/YOURGOOGLEPROFILE' />
<link rel='openid.server' href='http://www.blogger.com/openid-server.g' />

Click Save Template.

Once you add OpenID endpoints to your blog, Blogger will automatically deactivate its own OpenID 1.1 support. Since Google Profiles only supports OpenID 2.0 RPs, the above instructions also re-asserts Blogger as the OpenID 1.1 Provider so that 1.1 RPs still work. So what we have is the best of both worlds now.

Thanks to Breno de Medeiros of Google for the tip on how to keep OpenID 1.1 RPs working.

DotNetOpenAuth’s “call home” reporting

2010-01-16T08:49:00.001-08:00

A few months ago I asked how people would feel if DotNetOpenAuth collected feature statistics and sent them back to the library's authors so we get a better feel for what features are used, errors that are common. The feedback I got was positive, so v3.4 has reporting turned on by default, but you can opt out either entirely or just omit certain details from the report by adding some simple tags to your web.config file.

This turns it completely off:

<dotNetOpenAuth>
  <reporting enabled="false" />
</dotNetOpenAuth>

This makes the reporting pseudonymous, in that no URLs from your own web site are sent back in the report, but a random GUID is still included in your report so that we know that the origin of the report is the same across multiple reports.

<dotNetOpenAuth>
  <reporting includeLocalRequestUris="false" />
</dotNetOpenAuth>

How is the report sent?

There’s an adjustable frequency that defaults to once daily. When certain features in DotNetOpenAuth are accessed, a quick time check is made, and if it’s time to send a report, a thread pool thread is queued to generate and HTTP POST the report to https://reports.dotnetopenauth.net/. We use a thread pool thread to minimize the performance impact this reporting has on your web site. In fact the entire reporting feature is finely tuned to have virtually no impact on your site’s performance.

If your site isn’t running for at least one reporting interval, a report will not be sent. So most of your self-hosted “localhost” sites run by Personal Web Server in Visual Studio will not generate these reports.

What’s in the report?

So what all information is actually in this report anyway? Well, here's a sample:

{be791692-2573-41b4-bd6f-6f4760cf186c}
DotNetOpenAuth, Version=3.3.4.10015, Culture=neutral, PublicKeyToken=2780ccd10d57b246 (official)
.NET Framework 2.0.50727.4927
====================================
requests.txt
http://localhost:4856/login.aspx
http://localhost:54347/User/Authenticate
====================================
cultures.txt
en-US
====================================
features.txt
OpenIdLogin
OpenIdButton
AXFetchAsSregTransform
OpenIdRelyingParty StandardRelyingPartyApplicationStore StandardRelyingPartyApplicationStore
ClaimsRequest
FetchRequest
ClaimsResponse
XrdsPublisher
====================================
event-Yadis.txt
4	XRDS referenced in HTTP header
8	XRDS referenced in HTML
1	XRDS in initial response
====================================
event-PositiveAuthenticationResponse.txt
2	https://www.myopenid.com/server
2	http://localhost:45235/provider
====================================
event-NegativeAuthenticationResponse.txt

At the top of the file is a self-identifying GUID. It means nothing, except that the GUID is the same for all reports that come from your web site, allowing the reporting database to update the records for your web site (whether we even know the URL of your web site or not) with the latest report.

Then we have the DotNetOpenAuth version and CLR you’re using. It turns out that we not only use this for statistical purposes, but it allows the reporting server that receives the report to check whether the version you’re using is on a list of versions with known exploitable security holes. Since for many web sites authentication is a feature that’s completed and never considered again, someone using an old version of an authentication library may be exposed to security holes that a newer version would correct. So what happens if the version of DotNetOpenAuth that’s reporting in is one with known security holes? Not much. But if you have DotNetOpenAuth error logging (usually via log4net) enabled, an ERROR is logged with a message describing the problem and warning the web developer to upgrade. In the meantime the library on the web site continues functioning. I actually debated with myself whether to install a kill-switch, since perhaps disabling authentication on a web site altogether is better than leaving the site operational with a nasty security hole. But decided against that… and I suspect most web site owners would agree that it’s not my decision to make whether to shut down your web site. :) So I leave it at emitting a warning in your ERROR log.

The requests.txt section gives just the first few URLs on the site that either host DotNetOpenAuth’s ASP.NET controls or programmatically process OpenID/OAuth/InfoCard messages. Currently the longest this list of URLs can get is 3, since some sites like blogs may have login controls on every one of their blog post pages and I mostly just want to get an idea of who’s using the library. Note that these URLs have their query strings stripped off before being included in the report to try to avoid accidental private information disclosure. You can omit this section in your reports by setting the <reporting> element’s includeLocalRequestUris=”false” attribute.

The cultures.txt section just reports what the browser that’s accessing your web site says is its primary culture. This will help me know which languages to offer localized error messages for. Each report is limited to only reporting 20 cultures. You can omit this section in your reports by setting the <reporting> element’s includeCultures=”false” attribute.

The features.txt section lists which parts of the DotNetOpenAuth library have been used by your web site. Pretty straightforward. You can omit this section in your reports by setting the <reporting> element’s includeFeatureUsage=”false” attribute.

The event-Yadis.txt section is just some random statistics on how OpenID identifier pages are constructed. You can omit this section in your reports by setting the <reporting> element’s includeEventStatistics=”false” attribute.

The event-*AuthenticationResponse.txt sections tell me which remote parties DotNetOpenAuth is able to successfully interop with and which ones have issues. Note that no user information is collected or reported. You can omit this section in your reports by setting the <reporting> element’s includeEventStatistics=”false” attribute.

Please comment with your thoughts, including any questions or concerns you may have.

DotNetOpenAuth v3.4 now available

2010-01-15T15:20:00.001-08:00

You can go download DotNetOpenAuth v3.4 today. Highlights of the new version include:

Support for Google Apps for Domains issued OpenIDs. This required special work since Google has their own flavor of OpenID discovery that had to be supported until something like Google’s scenario get’s standardized.
Identifier discovery extensibility (this is how Google Apps support was enabled, but the extensibility is exposed for others as well – but use with caution!)
A new ASP.NET MVC OpenID web project template.
Twitter image POST via OAuth fixed.
New SSO web-ring samples added, so organizations looking to use OpenID for their SSO solution can see how it might be done.
Minor bug fixes.

Please note that this is the first version to have statistical reporting enabled by default, which reports feature usage statistics and the URL of the site hosting the library to the library authors. To opt-out of this feature, you should add this to your web.config file:

<dotNetOpenAuth>
  <reporting enabled="false" />
</dotNetOpenAuth>

The details included in the reports may be selectively turned on or off as well, if you are willing to contribute statistics but don't want the URL to your web site exposed, for example. More information can be found in my follow-up post: DotNetOpenAuth’s “call home” reporting.

Don’t forget to donate to the cause if you like the library.

Rest in peace, ExtremeSwank OpenID and OAuth

2009-12-08T12:12:00.001-08:00

ExtremeSwankOpenID and ExtremeSwankOAuth, both libraries authored by John Ehn, have been discontinued according to the project sites respective home pages which have a new note that reads: “Note: This … Consumer is no longer in development.”

ExtremeSwankOpenID was stagnant in development lately, and when a recent OpenID vulnerability was identified as impacting the ExtremeSwankOpenID library due to a hidden “feature” in the .NET Framework’s handling of HTTP responses, it appears the library was retired rather than fixed. This library was one of only two OpenID implementations written in .NET that were recognized in many OpenID circles. It also touted a unique feature (which I never investigated personally) of allowing desktop applications to use OpenID to authenticate their users.

ExtremeSwankOAuth is one of many .NET OAuth implementations, and the reasoning for its retirement is less clear.

Notwithstanding ExtremeSwankOpenID’s recent lack of development, it was ironically John’s library that was under active development and supported OpenID 2.0 while a very early version of DotNetOpenId wasn’t being developed and only supported OpenID 1.1. It was seeing DotNetOpenId’s own users switch to John’s library that motivated me to re-engage development of DotNetOpenId, now rechristened DotNetOpenAuth, which is now the only OpenID implementation for .NET that I know of – and a dang good one too if I may say so.

Although I did not know John personally, I’ve shared a few emails with him and he seemed a courteous and motivated programmer. I wish him well on his future pursuits.

DotNetOpenAuth v3.3 is released

2009-12-03T01:23:00.001-08:00

It’s been nearly six months since v3.2 was released. So what’s in v3.3 that took so long to bake? Well, a lot of it was waiting for and getting used to Code Contracts to mature enough to bet on the technology.

The most exciting changes though are the new OpenIdSelector control, and the new project template that helps you get going fast and strong with a new web site that accepts OpenID and/or InfoCard to log users in. Seriously, you gotta get this version and try it out. You can see a live demo of the new login UX now.

Go download DotNetOpenAuth now. And get the project template too.

As usual, you can get more of the details of the changes on the VersionChanges wiki page.

Do you like what you see? Don’t forget to contribute so that future versions can keep rocking!

Feedback requested: New OpenID RP login UX prototype

2009-10-22T15:57:00.001-07:00

OpenID RP login UX

Live demo location: http://openidux.dotnetopenauth.net/

Design considerations

The DNOA login UX design document contains the design spec, and some of the reasoning that went into that design.

One high-level goal of all this work is to produce a set of HTML, CSS, and JS files that can work on any web platform, so that ruby, python, php, coldfusion, and (of course) ASP.NET RP web sites can benefit from a better UI for logging users in.

Interesting scenarios to experiment with and/or test

Login by clicking on Members Only. This invokes the full page redirect login UI.
Login by clicking Login in the upper-right corner of the page. This invokes the popup dialog UI.
Visit the account management page and add additional OpenIDs or InfoCards to your account so you can log in with multiple identities yet be recognized as holding just one account.
Login multiple times, using various OPs. Notice first that we highlight the button you chose the prior time. This helps the user not splinter his identity on a return visit in the event he has accounts with more than one displayed OP.
Notice that in the login UI some OPs support checkid_immediate, and on a return visit, a green checkmark appears in the lower-right corner of an OP button when an immediate login is available. If a green checkmark is not visible on an OP button, a popup window will be used to guide the user through the initial login process. Some OPs (such as Verisign and Yahoo) do not support checkid_immediate, and will never display green checkmarks.
When logging in, try using the OpenID button. Notice that as soon as you finish typing that discovery on that identifier begins and a login button appears within the text box. Next time you visit, the UX will remember what identifier you typed in and help you log in again.
Try using the OpenID button with an identifier that delegates to multiple OPs. Notice how the Login button that appears to help you go through checkid_setup (if no checkid_immediate requests come back positive) is a split button, allowing you to actually pick which OP to log in with, and these OPs are in priority order (adjusted for OPs that are down or misbehaving, which are moved to the bottom).
Use Internet Explorer, and log in with your InfoCard.

Special release notes

In this iteration, I've elected to go with the popup dialog approach to displaying the login UI rather than a popup browser window. This is still alterable, and your feedback and/or preferences on this decision is most welcome.

The current set of OP buttons displayed include 4 OPs: Google, Yahoo, Verisign and MyOpenID. The last two of these do not fit the qualifications given in the design document, but they are included here to assist in the feedback process, and because I don't know how to make four buttons (Google, Yahoo, OpenID and InfoCard) look good, so I jumped up from three to six.

In the OpenID text box area, after authentication completes a green checkmark is displayed, but sometimes no login button appears to complete login. This is a UX issue I haven't figured out how to solve yet. But the way to proceed with login is to click the original, large OpenID button again.

The browsers I've tested with are IE8, Chrome 3, FireFox 3.5 and Safari 4. If you test with other/older browsers, please leave feedback about how your experience was. But currently I'm not targeting older browsers, so any bug reports regarding backward compatibility may not be fixed.

How to leave feedback

Minify your EmbeddedResource .js and .css files in your MSBuild project

2009-10-10T15:57:00.002-07:00

If you write a C# or VB.NET class library that contains ASP.NET controls that also have .js or .css files embedded in your assembly, you probably want to minify those files for optimal download size in production, but keep the files readable for coding and debugging. What if you could add a single <Import> to your class library’s project file that would automatically minify these files in Release builds, while leaving them untouched in debug builds?

Well, I wrote a .targets file and associated MSBuild task that uses Dean Edwards’ excellent Packer algorithm to make .js files really small. Just import the .targets file right after your last <Import> and you’re done.

You can get it here:

http://teamcity.dotnetopenauth.net:82/project.html?projectId=project3

Just click "Artifacts" then "Download all (.zip)" in the upper-right corner.

Or the source for it if you're interested:

http://github.com/AArnott/JavascriptCssPackerTargets

Just click the "download" button to get it as a zip file.

Please take this as a tip and not an endorsement. This is not a Microsoft product—it’s just an open source project that I wanted to point out to you for you to evaluate whether it’s appropriate for your project. As far as the license goes, this MSBuild task uses code from Dean Edwards that is under the LGPL license, so the whole MSBuild task .dll ships under the LGPL license. While I don’t interpret that to mean that your shipping project must be under any particular license, you should consult your own attorneys and not take my word for it.

(cross-posted from http://blogs.msdn.com/vsproject/)

VS2008 project template for OpenID and InfoCard relying parties

2009-10-09T11:22:00.001-07:00

I finally built a project template to make it easier to write an OpenID relying party web site using C# and ASP.NET. Up to this point all we had were the sample RPs that ship with DotNetOpenAuth, which were deliberately kept simple. They didn’t use a real database, didn’t follow some best practices, and weren’t very real.

Now you can start your next web site with OpenID and InfoCard logins already working! Complete with role authorization, account management that allow for multiple OpenID/InfoCards per account, login and account creation.

And did I mention it’s free? (donations gratefully accepted)

Download it and copy the file "Project Templates\*.vsi" file into your %USERPROFILE%\Documents\Visual Studio 2008\Templates\ProjectTemplates folder and it will appear in your New Project wizard in Visual Studio 2008.

Yes, the site is still unbeautified, but that’s so you can brand it to look like yours.

Have fun. And let me know what you think of it or can contribute.

Optimal OpenID UX finally underway

2009-09-25T21:47:00.002-07:00

I’m finally making progress on building a set of HTML and javascript files that can be used on any OpenID relying party web site to allow visitors to easily log in with OpenID, without even knowing what OpenID is. I mentioned my goal to do this some time ago, and now I have a small partially functional prototype. Please try it out, and keep coming back and letting me know what you think of it and where you’d like to see it go.

Try out the OpenID login experience. Remember to comment on what you like and dislike, and what aspects you’d like to see added or changed.

At the moment, I’m struggling to decide whether to go with a fully bona fide popup window or a Javascript in page dialog. So I provide two links at the top of the page so you can try out each one. If we don’t go with the full popup window, we’ll have to either redirect the whole page to the Provider, which is sub-optimal for the user and for the RP, or we can use a popup window once the user has selected their OP.

How to easily fetch OpenID attributes, regardless of the Provider

2009-09-07T16:20:00.001-07:00

In a previous article, I bemoan the pain of writing an OpenID Relying Party that wants to fetch user attributes from their OpenID Provider, because of the at least 4 ways in which those attributes must be requested. And then later I promised that DotNetOpenAuth would offer help to alleviate that pain. That help has come. It actually came way back on June 26, 2009. But only now did I officially document that help.

Introducing the AXFetchAsSregTransform “behavior”, which is now fully documented on the project wiki site. I’ve spent some time recently (and will spend more in the near future) documenting the common scenarios that people have questions about, and since it is on the wiki instead of only on this blog, it will be more likely to be updated as new versions of the library come out.

The AXFetchAsSregTransform behavior makes it so that all you have to do is work with ClaimsRequest and ClaimsResponse – no matter what Provider you’re talking to. If the Provider only supports AX, it Just Works because the special behavior will automatically translate your sreg request into an AX request, and then translate the response back from AX to sreg. Woot.

DotNetOpenAuth v3.2 is done

2009-06-27T08:04:00.001-07:00

DotNetOpenAuth v3.2 just came off the presses. Lots of feature work and a few interop fixes in this release. The biggest highlights being:

Very simple story for both RPs and OPs interested in interoperating with others whether they use sreg or one of the several AX formats (finally!)
OAuth 1.0a support
PPID generation for OPs to protect customers' privacy.

Go download it.

As usual, see our VersionChanges wiki page for a more complete list of the work done for v3.2. (There are lots more noteworthy changes that I don't describe above).