Bill Blogs in C# -- .NET General

Bill Blogs in C# -- .NET General

Created: 11/19/2010 2:49:25 AM

I often  use analogies to explain software engineering  concepts to non-technology people. While driving a couple weeks ago, I had one of those experiences to illustrate one of the challenges of multi-threaded programming.

I was driving on the interstate early Sunday morning. Traffic was moving along nicely. At one point everyone came to a complete stop. Several minutes and half a mile later the answer was clear. Two lanes were closed for bridge work. People slowed down,and stopped to merge three lanes of traffic into one.

This little episode illustrated one of the hazards of multi-threaded development. That single lane over the bridge represented a synchronization region. Drivers were moving in parallel until they needed to cross the bridge. The path across the bridge was single threaded. That single-threaded section was the bottleneck.

When traffic entered this single lane at a rate no greater than the throughput rate of the bridge, traffic proceeded at a normal rate. That’s what we hope happens in our multi-threaded programs.

Bottlenecks happen because too many cars try to enter the one-lane section. In the same way, multi-threaded programs suffer when too many threads are waiting for a scarce resource.  Suddenly, processes that ran at full speed when each thread could run interrupted suddenly bog down when multiple threads are stuck waiting for their turn for a critical section.

What’s even more interesting is that traffic slowed down to a rate slower than it would normally travel along a two-lane road (one lane in each direction). As more and more cars queued up at the construction, the wait times continued to increase. Having part of your program run in multiple threads may actually hurt overall performance if the critical sections increase the overall wait times.

So often, non-developers think that multiple threads automatically means more performance. If you have two threads, code should run twice as fast, right? Ten threads means 10 times as fast. That depends on how often those threads share data, and what happens when many of the threads have too wait (and for how long). Multiple threads can be great (just like interstates let us drive faster than we could over the earlier 2 lane high ways). But, when those parallel threads must wait for a single threaded section, performance may suffer even more.

Created: 9/24/2010 4:15:25 PM

I had a question from a reader of Effective C# on what, exactly, is the relationship between Equals() and GetHashCode().

It is a strangely complicated concept, and FxCop rules even get involved.  Sadly, the guidance in Effective C#, while technically correct, can be misleading.

I’m going to stay brief here, and refer to the information in Items 6 and 7 of the second edition of Effective C#. I go into quite a bit of detail there on the interaction and the default behavior for Equals(), operator ==, and how GetHashCode() relates.

Briefly, GetHashCode() matters if you intend to use a type as a key in a hash-based container (such as Dictionary<TKey, TValue>). I think it’s best to be somewhat defensive, and avoid making assumptions about how your types will be used. Therefore, this is one of those fundamental behaviors that is important to handle correctly.

One of the rules for GetHashCode() is that if two variables (a, b) are equal, then a.GetHashCode() must return the same value as b.GetHashCode(). Very simply, if that rule isn’t followed, you won’t be able to find objects in a dictionary.

Now, the important question: Which ‘equal’ do I mean above?  It may mean a couple things.  First, it may mean the concept of equality as defined by System.Object.operator == (). Part of that is easy: if a and b both refer to the same object (referential equality), a and b are equal. After that, it gets a bit more involved to understand.  System.Object.operator==() will call a.Equals(b) to determine if a and b are equal. Of course, that’s a virtual method, so any override of Equals() on the runtime type of a will be used.

But, what about overrides of operator==()?

This is where many folks start to lose their understanding. operator==() is a static method. Therefore, it must be resolved at compile time. That means in most cases, if you override operator==(), it won’t be called when some code in the base class library makes an equality comparison.

Effective C# could be misleading, because I said that GetHashCode() required equal objects as defined by operator == to generate the same hash code. That’s true, but it’s the operator == in System.Object, not any version you provide.

The bottom line recommendation is that no matter how you test for two objects being equal, you should get the same answer. The code in the base library is written such that it will end up using System.Object.Equals() (which you can override) for any comparison.  However, if any of the ways you can compare two objects return the same result, you’ll be fine.

Created: 8/23/2010 7:17:20 PM

Some members of the C# community were discussing optional parameters and the implications for future versions when optional parameter values change.  In short, you need to realize that changing the value of optional parameters in a public API is a change that is observable at client code. The ramifications vary greatly, from “no big” to “stop the world”. I’ll give a brief explanation of how the feature works, and what you need to watch for and how to separate reasonable caution from irrational fear from using a feature.

Let’s review the feature first. 

Optional Parameters lets you define default values for parameters that a caller does not specify. You can write:

        public
        static Point Scale(this Point src, double scale = 1.0)
{
returnnew Point
{
X = src.X * scale,
Y = src.Y * scale
};
}


Let’s ignore the fact that there is already a fine method in the BCL that scales points. This is meant to show syntax and language features.

Callers could omit the second parameter, and the operations scales a point by the factor of 1 (the identity transform):

var pt = new Point { X = 5, Y = 10 };
var pt2 = pt.Scale();


The behavior is the same as if you had placed ‘1’ in for the missing parameter:

var pt = new Point { X = 5, Y = 10 };
var pt2 = pt.Scale(1);

That fact illustrates the important concept to understand on optional parameters:

The compiler inserts the value of the default parameter at every callsite where the caller did not explicitly set a value.

Changing in the future

That concept helps us understand and define what we mean by a breaking change to an API.  Let’s suppose at some later time, you (as the library designer) decide that Scale() should move any point to the origin, instead of being the identity transform. The change to the API is a simple matter of changing the value of the default parameter:

 

        public
        static Point Scale(this Point src, double scale = 0.0)
{
returnnew Point
{
X = src.X * scale,
Y = src.Y * scale
};
}


Let’s look at what happens to the call site when this change is made.  There are two cases to consider

  1. The caller does not recompile (a binary in-place upgrade to the assembly containing Scale).
  2. The caller does recompile (either it’s in the same assembly, or the caller decides to recompile)

In the first case, it’s one kind of breaking change.  If the caller does not recompile, the call to Scale() still performs the identity transform.  It no longer  performs “the default behavior for scale”. However, it sti

ll does exactly what it did before. That’s good, because it means that applications that were tested with the old behavior will still do exactly the same thing.

In the second case, the breaking change is a different one:  Calling code that has been recompiled still performs “the default scale behavior”.  However, now the default scale behavior is to move the point to the origin. This is a different kind of breaking change.  Code now does ‘the default thing' but the default behavior is different.  It’s still correct, because we can safely assume that since you did recompile, you wanted the to upgrade to the new behavior, and you are prepared to test those changes.

Ok, So now what?

We’ve learned that changing the default value for parameters causes problems for callers. The language rules and the implementation of the feature minimizes the pain, but it still hurts.

Changing anything public is a breaking change

This phenomena is not unique to Optional Parameters.  If you change any code that has public access, you need to understand that you probably broke some client code. If you change the observable behavior, that’s a breaking change. Change the number of parameters, order of parameters, types of parameters, or return type, you probably broke code.

Rule:  Optional Parameters in public methods should receive the same consideration as anything else declared with public access.

Optional parameters are no more evil than any other language feature. They just require reasonable forethought when used as part of a public interface. That makes them just like any other language feature you would use in a public method.

Created: 6/10/2010 7:39:25 PM

A recent email conversation about TDD and its costs and benefits reminded me that our industry is incredibly bad about selling concepts to our customers. The thesis of the email was that the author considered testing very important, and had invested in testing activities, but had not received the ROI he expected from adopting these activities.

The bulk of the pro-testing guidance available makes it very easy to fall into this situation.  We often take sound practices and distill them into provocative slogans. These slogans are easy to remember, but can lose the justification for why we use these practices. Even worse, they can lead decision makers to wonder if we have their interests in mind. I don’t want to spend lots of space giving examples of arguments that don’t work, so instead I’m going to look at some of the critiques I’ve heard against TDD and related development ideas, and my counter-arguments.

Your application architecture gets overly complicated due to testing. This makes it more expensive to add people to the project, and very hard to transfer ownership of a project.

It is true that designing for automated tests does have a complicating effect on an application’s architecture. You will program to interfaces more often. You’ll have multiple paths to create objects and connect them to other objects. You add those paths so that it’s easier to create and use some kind of fakes, whether Mocks or Stubs. However, there are many benefits to following this architecture regardless of your testing strategy. You’re more likely to minimize coupling, and much more likely to following the Single Responsibility Principle. These benefits provide you flexibility in the future. It’s easier to replace one piece of your application with another if it’s decoupled. Change databases? Not quite as hard. Use a new UI framework? Much easier than it might have been otherwise. The ROI can be hard to measure because it’s in the future.  But every manager I’ve talked to gets it when I say “How often have your developers told you that some request that seems simple requires a major rewrite?” They nod. We discuss why that happened and it’s almost always because whatever they want to replace has become integrated throughout the application. A by-product of architecting for testability is that this doesn’t happen nearly as much.

Tests aren’t maintained over time. It’s just like out of date documentation.

The only answer I have here is that this is a case of broken window syndrome. If, as an organization, failing tests are acceptable, then you’ll have plenty of them. The number will grow over time. Failing tests mean something. They may mean code is broken. They may mean that assumptions about functionality are no longer valid and some tests should be removed. In either case, failing tests indicate there is work. If failing tests are allowed to  remain for any appreciable amount of time, you’ve failed. I learned this lesson very painfully at a company I worked for in the early 90’s. A key senior developer left for vacation, and a crash bug in his low level library surfaced.  For the next two weeks, every check in had the test comment “It crashed on exit before I started the change, and it still crashes on exit.”  Three weeks later, the bug was fixed, and we had more than 20 new crash bugs. If your organization allows backsliding, you will backslide very far.

People just run unit tests and never run the actual application.

This one bites me sometimes too. I think this is part of learning, and I don’t believe I have all the answers. And, the right answer, sometimes is “It depends.”  I’ll describe three different scenarios on projects I’ve been on within the last 6 months.  All used testing somewhat differently because of the differences in the projects.

In one project, I was responsible for a series of libraries that were part of tens of different departmental levels of applications. Unit tests were, and are, critically important. They are often more important than application level testing. The tests on the public API represent the contract expected from the library. If I change the library behavior, I need to be sure that I’ve preserved the behavior in all applications, not just one. The unit tests represent that guarantee. Fixing one application but breaking even one unit tests likely means breaking other applications. That alerts me to find a different solution to the original problem. I also make sure I write new unit tests to cover new or modified behavior so that my work doesn’t regress in future changes.

The second project was my first attempt at learning WPF. I like WPF (more on this in future blog posts), but I don’t know it very well yet. Oftentimes, my assumptions ran counter to what WPF expects from underlying business logic. It didn’t make sense to write unit tests that ensured my code obeyed my flawed assumptions about what would work in a WPF application. It was completely backwards.  In this case, I prototyped functionality in WPF, testing the application.  Once I understood how to make my other classes work with WPF, I stopped working with the application and created unit tests for my core classes. I knew how I wanted them to behave, and automated tests are re-executed much more quickly.

The third project was an Azure project. I am really excited about the vision of Azure. I have projects in development running there. However, deploying a new build takes a few minutes. I’m not surprised, there’s a fair amount of work that must be done to deploy a new application in Azure. Starting the Developer Fabric also takes time. I have a much faster cycle time if I don’t have to spin up the azure environment to validate core algorithms. A great thing about the Azure story is that in many ways, it’s just .NET: core algorithms can be easily tested outside of the azure cloud environment. I try and do as much as I can in unit tests around my core algorithms.  There are some differences that only manifest themselves in the cloud, so application level testing is important, but I want to minimize those occurrences.

The theme that runs through all these scenarios is that running automated tests is easy, and you can do it often. That practice greatly decreases the likelihood of any regressions in functionality. We know that code will change over time. Running a thorough suite of automated tests means those changes can be made with more confidence. However, counter that with a thorough understanding of what functionality needs to be built so that your tests actually cover real expectations, not assumptions that have yet to be validated.

[Really paraphrasing] Our developers get and understand unit tests well, but when we integrate all the working pieces, the application fails at the integration points.

We’ve experienced this as well. I think it can be very hard to separate ‘the right tool for the job’ from ‘the job’. I tried to be very careful above to use the term ‘automated tests’ when I mean any kind of test that does not require humans running the application. I use ‘unit test’ when I mean something that tests the core logic for an algorithm. They are different, even if you use the same tool for both jobs. (Another blog post coming on this topic).

Chris Marinos started a practice where one set of unit tests is the 'guide’ for usage of a library. This was a great idea. It means one set of tests serves to show how to use a library, and validate that those critical success scenarios work. Wonder of wonders, most developers using a library would copy the tests and modify them in their production code. That really minimized integration errors.

Another practice is to write some integration tests: write some tests (in any tool) that validates some of the critical integration points between some components. The goal is automation, not writing tests.

And that, I think is where I want to close this post (which is already too long):

The goal of all this work is not to ‘write tests’. It’s not to create more work. Instead, it’s to develop work practices that enable you to move faster, with more safety. Don’t try to sell testing by explaining the work. Explain that you are using tools to automate every part of the development process that you can. It enables the expensive humans to do more thinking and less grunt work. There will still be human executed testing. There will still be integration testing (some automated, some at the application level).

In general, I’d counsel that you should automate any task you find yourself doing more than once. That saves you time. I’d expect that most organizations want to run a battery of tests more than once. There’s a large ROI in automating those tests. There’s no ROI in writing tests that don’t increase quality, or whose failures don’t tell you anything. Write tests that help you produce high quality software faster.

Created: 5/6/2010 12:46:44 AM

I received a great question that relates to using exceptions to indicate contract failures. I thought it would be of general interest, so I am sharing the answer and discussion here:

I am reading your book More Effective C# and just finished Ch3, Item25, Use Exceptions to Report Method Contract Failures. It all makes good sense but I'm left wondering what to do in the case of a Data Access Object. Supposing I have the following class:
public class OrderDao
{
        public Order GetOrder(int id)
        {
                // Query database
                return order;
        }
        public bool OrderExists(int id)
        {
                // Query database
                return orderExists;
        }
}
What happens if the order is not in the database? Should the GetOrder method return null or throw an exception? We can call the OrderExists method before calling GetOrder but then that would involve up to two database queries, which could be more expensive than just calling GetOrder and handling the exception. What do you think is the best strategy for this?

He correctly realizes that he does not want to make two round trips to the database. Of course, you don’t want to use exceptions as a general flow control mechanism either.

I don’t have enough context to give a definitive answer on this sample. However, that gives me the chance to discuss why you’d make different design decisions.

It may be that this class is correct exactly as it is shown. Suppose the data model is such that any code searching for an Order does so through some other table, and that a missing id would indicate a data integrity error. If that is the scenarios for this application, the correct behavior is in the class above. A query for an order when the order ID does not exist is a data integrity error. When you encounter a data integrity error, you almost certainly want to stop stop processing more requests. Something should trigger a full check and recovery of the database.

Of course, because you asked the question, this likely isn’t your scenario. It’s easy to come up with a scenario that requires a different contract. Suppose your application is a customer service app. Customers call, and give you their order number. A customer service rep keys in the order number, and your code queries that database to find that order. There’s lots of ways that can fail without being too exceptional: a customer may give the wrong ID, a customer may hear it wrong, type it wrong, and so on. There are a lot of ways that searching for an order could fail in this scenario.

The answer is to change the contract so that one method will check the database and correctly return the record, or tell you that it doesn’t exists. Suppose that instead of GetOrder() you followed the LINQ convention and wrote GetOrderOrDefault().  Now your class (in pseudocode) looks like this:

public class OrderDao
{
        public Order GetOrderOrDefault(int id)
        {
                Order order = null;
                // Query database
                // if order is found, set order = returned value.
                // else order remains null
                return order;
        }
        public bool OrderExists(int id)
        {
                // Query database
                return orderExists;
        }
}

You are still doing only one database query, and you can translate that into a single result that returns the answer, if it is found, and completes its contract even when the sought record is not found.

What’s important about this answer is that you, as a class designer, create the contracts your class adheres to. You can write those contracts in such a way that under any reasonable condition, your methods can fulfill their contracts. In this instance, the important concern is that you do not want your users paying for extra database trips. You need to create a contract that enables your users to call your methods in the way they want, and still performs the way you want internally.

Created: 1/29/2010 7:26:23 PM

The January Visual Studio Magazine marks the first time the C# Corner is written by Patrick Steele. I’ve bowed out after a long run with the magazine and its predecessors.

The most important part is that the C# column is in great hands. Patrick is excellent at explaining concepts, and he’s going to bring a wealth of new ideas and concepts to the magazine. I feel much better walking away from the column knowing it is in such good hands.

It was hard to walk away after so much time with VSM and its predecessors. But it was time. I’ve written on so many C# topics that I was having trouble coming up with ideas that felt new. I felt like I was covering the same ground over and over.

That got me thinking about how long it had been, and what a long, strange trip it has been.

I started as the original C++ Fundamentals columnist for Visual C++ Developers Journal in the 1990s. That was a new magazine published by TPD, for the MFC / C++ Developer. It were covering techniques to bridge the divide between 16 bit and 32 bit applications. There was this amazing new OS code-named ‘Chicago’ on the horizon.

A few  years went by. I kept covering more topics related to C++ and windows development. More MFC, ATL, language enhancements and how the Microsoft C++ compiler tracked (or didn’t track) the C++ standard.

At some point in this period, Visual C++ Developers Journal was bought by Fawcette. TPD stopped being involved.

The turn of the century brought more changes.  This amazing new .NET platform and the C# language showed up. I started writing about C#and .NET fundamentals, instead of C++. Although the change was gradual: In the beginning, I was writing 2 C++ columns for every 1 C# column. Over time that kept changing.

Next, came some initiatives to capture more of the web audience. Several of the columnists starting writing a column online (at the rate of one a week). These weren’t all tech columns. Some were more opinion, or ‘tip’ columns. That felt like quite a grind. I was constantly under deadline pressure to come up with a new idea every week. It soon got harder: The readers liked the ‘how to’ columns most. I was asked to replaces the ‘tips’ and ‘opinion’ entries with more regular columns.

I took a break and wrote a book (Effective C#, the first edition).

I wrote for a while, and then there were more changes.  Visual C++ Developers Journal merged with Visual Basic Programmers Journal to become Visual Studio Magazine. This was a challenging time to write for this magazine. The audiences for VCDJ and VBPJ were very different. And, most importantly, they were both afraid of losing content to the ‘other’ audience. C# aficionados were concerned that they’d lose coverage to the larger VB market. VB developers felt the same fear of losing coverage to the newer, and perceived to be cooler C#. That was a tough era. The editorial staff did a tremendous job to navigate a very tough set of market perceptions.

I stayed on break and wrote a second book (More Effective C#).

Then, I was approached to come back and write the C# Corner column for Visual Studio Magazine. Having finished the book, it was time to keep writing again. It was fun for a while. I was and still am impressed by the energy that 1105 media is bringing to the publication.  I had a blast over the past two years writing for a reenergized Visual Studio Magazine.

Then, while still trying to write the column, I updated Effective C#, covering C# 4.0, and other recent enhancements to the language.

I was running out of ideas for the column. Visual Studio Magazine deserves better content. That’s why I worked with Michael Desmond and the editorial team at VSM to turn over the column to Patrick. I’m glad it’s in good hands.

So what’s next?

I’m now writing content for the C# Developer Center. The cadence will be roughly once a month, and I’ll be writing on current and upcoming language features in the C# language.

Created: 1/11/2010 7:13:39 PM

A new year means it’s time for CodeMash.  Tomorrow I begin the annual geek pilgrimage into the water park for tech knowledge.  I’m amazed at how much the conference has grown, and the strength of the session list. It was difficult to decide where to spend time, but here’s my current plan:

We’ve got great keynoters this year, and I’ll be attending all of those. I am attending the precompiler again this year. Here’s the current plan:

  • Wed AM:  The Ruby Koans (Joe O’Brien and Jim Weirich
  • Wed PM:  Open. I’m not sure what

Thursday:

  • 9:45:  Silverlight from Zero (Jesse Liberty)
  • 11:00: User Stories: Closing the Agile Loop (Barry Hawkins)
  • 1:45:  Ruby and Rails for the .NET Developer (Matt Yoho)
  • 3:35: Funky Java, Objective Scala (Dick Wall)
  • 4:45: Engineering vs. Design – How to Work Together (Joe Nuxoll)
  • Friday:

    • 9:30: Going Dynamic in C# (Bill Wagner). Of course, I have to be there.  But, I hate pimping my own talk, so if I weren’t speaking at this slot, I’d pick:
    • 9:30 (alternate) Being an Evil Genius with F# and .NET (Chris Smith)
    • 10:45: Restful Interfaces to 3rd Party Websites with Iron Python (Kevin Dahlhausen) (I’m picking this because I’ve seen Jim Holmes’ Leadership talk, and I need to learn Python better)
    • 1:45: Iron Python with ASP.NET (Chris Sutton)
    • 3:35: What’s new in Silverlight (Jesse Liberty)

     

    Some of this will likely change, but I think you can see the goals:  I want to learn more about dynamic languages in general. I also want to take the opportunity to learn as much Silverlight as I can. Jesse Liberty is a great teacher, and I can’t pass on this opportunity.

    Of course, like every CodeMash, I’ll probably make a number of changes to this one as well.

    Created: 11/18/2009 8:07:43 PM

    That was a twitter comment I made this morning during the PDC keynote. A number of folks have reposted it.

    Twitter’s character limit means I’ll elaborate here.

    I don’t think this is a bad thing for WPF, or people that build WPF applications. Silverlight is gaining more and more features, and those features mean that over time, Silverlight will become a superset of WPF. That’s very different from the original vision where Silverlight was a subset of WPF.

    I think over time, you’ll see one advanced graphics / UX framework for .NET development. I believe it’s name will be Silverlight.

    I don’t know how long it will take, as there are still some gaps and differences. I also think there will be some continued enhancements to WPF in the short term. As time goes on, those enhancements will be smaller and smaller, and Silverlight will be the single framework.

    Of course, I also think that any investment in WPF (now and in the future) will be extended to the Silverlight ecosystem.

    In the end, I think this is branding. Silverlight has much more buzz than WPF. It’s clear that Microsoft should merge WPF and Silverlight into one framework. If there is going to be one UX framework, its name will be Silverlight.

    Created: 11/10/2009 9:19:21 PM

    I received the following question (paraphrased) this week:

    “You are an advocate of converting imperative style programming into re-usable frameworks as you did in your November VS Magazine column. I agree from a developer’s perspective. But, one thought that came to mind is the imperative style is quicker to grasp from a maintainer’s perspective because the code is in one place in contrast to several little functions that need to be pieced together. Is your thinking that once the framework of functions is setup and re-used, then a maintainer only has to learn it once and subsequently the idiom is quickly recognized? Effectively, there is a high cost the first time the idiom is encountered but then the future cost is lower?”

    Actually, I think the imperative code seems easier to maintain because we’ve all seen so much more of it. That’s probably even more true case of maintenance developers. Only some of our universities discuss declarative programming languages. There’s even less declarative programming in products and enterprise projects these days. Declarative programming is unfamiliar to many of the professional developers writing code today.

    In our regular day to day jobs, it’s not that what we do is incredibly hard. What makes some tasks feel hard is that we are unfamiliar with the tools or the task. Declarative program is one of possible tools that most developers are likely to avoid, because it is very unfamiliar. That’s a shame (in my opinion) because forcing yourself to think in different ways will make you a better software engineer. Furthermore, the problem you describe above will go away. The more exposure that developers have to declarative programming, the easier it will be to understand it and maintain it.

    On your specific concern, I honestly think that the declarative style makes it clearer to see exactly what each function does. Those smaller, simpler functions are easier to understand. In my opinion, that makes it easier to understand larger algorithms composed of these smaller functions.

    Created: 9/30/2009 11:32:00 PM

    I love it when I find those small new bits of functionality in the .NET framework. It’s all the big items that get all the love at conferences and in magazines.

    Lazy<T> is one of those items.

    Let’s imagine you’re writing an application and in some scenarios, but not others,  you need a particular object. Furthermore, suppose that object you need is very expensive to create and use. You don’t want to create it everytime your application runs. You only want to create it when you need it.

    Sure, you could manage all that yourself, but Lazy<T> makes it easy.  You just create a lazy wrapper on the expensive object:

    Lazy<ExpensiveResource> ownedResource = new Lazy<ExpensiveResource>();

    You can simply reference ‘ownedResource.Value’ to get at the expensive object. The first time you access ownedResource.Value, the expensive resource will get allocated, but not before.

    Lazy<T> also has a boolean propoerty, named IsValueCreated, that you can check to see if the value has been created. That would be useful when you need to store information from the expensive resource, but only if it’s been used.

    Supporting Types without default constructors

    Lazy<T> does not enforce the new() constraint. You can use Lazy<T> for types that must be instantiated using a different constructor, or even a factory method. A second constructor specifies a Func<T> that returns the new expensive resource:

    Lazy<ExpensiveResource> ownedResource = new Lazy<ExpensiveResource>(
        () => new ExpensiveResource("filename.data"));

    You can use this second constructor to better control what code creates the expensive resource. I’ve used a different constructor here, but you could use a factory method, an IOC container, or any method.

    We’re living in a Multi Core World

    There are two other constructors in Lazy<T>:

    public Lazy(bool isThreadSafe);
    public Lazy(Func<T> valueFactory, bool isThreadSafe);

     

    These two constructors indicate that you are running in a multi-threaded envrionment, and the lazy construction of of the owned object must be synchronized. (After all, it’s an expensive resource. You don’t want two of them.)

    It’s a simple type, but it’s one of those types you’ll find yourself reaching for over and over again.

    I’m glad it’s been added.

    Created: 9/17/2009 3:39:20 PM

    With some fanfare, the CodePlex Foundation launched itself late last week (http://www.codeplex.org).  This has generated quite a bit of discussion on blogs, twitter, email lists, podcasts, and everything else.

    I’m optimistic, with some reservations about how this will play out.

    I’ll preface this discussion with the obvious disclaimer: I am not a lawyer. My knowledge of copyright law comes from asking quite a few questions of editors and attorneys before signing the contracts for the books and articles I’ve written. This is not legal advice. It can’t be because I’m not licensed to practice law.

    The Barriers to Open Source Adoption

    In my day job, I work with a number of large companies.  Many of them have explicit policies against using Open Source code.  In addition, some ask for indemnification against IP claims for purchased closed source software. That’s a reasonable action, given the current state of our legal system, the very small number of people that understand software, and the amount of cash that large companies need in order to operate. (It takes a lot of money to make payroll for 100,000 employees).

    The probability of using stolen IP is small. That’s why many smaller companies accept that risk (sometimes without thinking). But, the cost of being wrong is very high. Furthermore, because of the way copyright law works, the users of open source software are at risk. If you incorporate stolen IP into your business, it doesn’t matter if you did it knowingly or not, you are at risk of civil penalty.

    So imagine you’re the CIO of a big company. You no longer want to spend your days looking at code. You’ve got important meetings to attend. What’s the answer to using Open Source?  Do you have someone perform the research and due diligence to satisfy your fiduciary duty?  Of course not. You (as CIO) are still responsible. It’s easier to just say no. Sure it costs more money to reinvent something. But it’s legal. Sure it costs more to pick a commercial solution. But you can ask for indemnification in exchange for buying the licenses.

    In short, the risk of outsized penalties keeps commercial software developers from benefiting from, and therefore participating in, open source projects.

    Purchasing Indemnification

    But wait you say.  Isn’t Linux used in many large organizations?  Certainly. In many of those cases, the large enterprise has purchased the software. Or, more accurately, the company has purchased indemnification against lawsuits. The company providing the software (RedHat, IBM, etc) and the license is accepting the risk, and is using the fees to do what they need to minimize their own risk.

    This is pure opinion.  I believe that part of Microsoft’s motivation for the CodePlex foundation is to make it easier for large enterprises to use .NET based Open Source projects. Note that many of the Open Source projects in widespread use today are championed by IBM, and run on the Linux Operating System. I believe Microsoft wants to enable the CodePlex Foundation to make a stronger ecosystem for .NET projects. Those .NET projects that are part of the CodePlex Foundation may find better adoption rates at large enterprises.

    Copyright Assignment

    One of the items on the CodePlex Foundation that is causing lots of concern is the sample license agreement that assigns copyright to the CodePlex Foundation. Here, I’m leaning heavily on my experience with publishers.

    First of all, the only way you can assign copyright to another party is if it is yours. OK, that’s obvious, but I think lots of people are missing that. When I sign the contract for a book with a publisher, I do assign the copyright to the publisher (in return for some considerations). The publisher needs me to warrant that the work is *my original work*.  The same would be true for Open Source software projects. Hypothetically, for me to assign my OSS project’s copyright, I would have to assert that it’s my original work.

    There is another way to assign copyright, which will be necessary for CodePlex and OSS to work. If you ask everyone that contributes to your OSS project to assign the copyright to the project (or you), you do hold the copyright, and therefore you can assign it. (The Apache Foundation Individual Contributor License Agreement contains language necessary to assign the copyright over.)

    Note that you can (as the original author) grant a non-exclusive license as an alternative to assigning the copyright. That’s also common in many OSS contributor agreements. I’m not sure how much weight that gives in IP legal entanglements, but it seems to work for the Apache Foundation, and the MySQL organization. I’ll defer to others with more knowledge.

    I’d imagine you could grant an exclusive license, but I’ve never seen that.

    What the Codeplex Foundation can accomplish

    Here’s the funny bit, and why the CodePlex can be a very strong positive force.  The originator of a work can’t assign copyright to ‘a project’. Copyright must be assigned to a legal entity. That means a person, a corporation, some other business entity, a non-profit organization, or government entity. The CodePlex foundation is a legal entity, and can be the recipient of a copyright assignment.

    The foundation has deeper pockets than most Open Source project leaders I know. I imagine that will continue to be true. The Foundation will, I believe, defend those copyrights that have been assigned to it.

    Every book author knows this drill: if your book is successful, websites will spout up that let people download an electronic copy for free.  When I find one of those, my only action is to let my publisher know about it. Some of the sites disappear, so it’s clear that the publisher’s attorneys have taken some action. I expect the CodePlex foundation to take similar action (and to take defensive action) when legal issues of IP ownership arise for those patents that have been assigned to it.

    My opinion is that the CodePlex Foundation is enabling ownership of copyrights in order to provide an umbrella to protect users of its projects.

    Note: I have no idea what, if any, recourse the Foundation, or a project owner, would have regarding a non-exclusive grant of use. See IANAL disclaimer at the beginning of this post.

    Why do I care?

    We just released an alpha of our first Open Source project (http://elevate.codeplex.com). I didn’t know what to expect. The experience was very positive. I enjoyed the project. I enjoyed the attitude that this project engendered even more.

    The most interesting attitude change working with Open Source was that you view the source as the product, rather than the the object code. Often when you’re working, and a ship deadline approaches, you may feel pressure to defer work that isn’t necessary to meet the shipping deliverables. Maybe there’s some refactoring that doesn’t happen. Maybe there are some algorithms that don’t get updated to use a more modern technique. You have to ship, and no one sees the underlying code, so maybe that work gets delayed.

    Working on Open Source gives you a different perspective.  The source is the product. It must work. That’s necessary, but not sufficient. People are looking at the source in order to evaluate your project. The quality must show in the source, and in the test code. This change in the deliverable manifests itself in a change in our collective attitude toward work. We release in different (smaller) cycles. We focus on the internal source quality as well as the external behavioral quality when we discuss release gates.

    That won’t necessarily raise the quality of code. I’ve seen very bad Open Source code. I’ve used closed source products that have excellent quality. And yet, it’s hard to ignore my change in attitude while working. It had the best of both worlds.  I enjoyed working on production code (which I don’t get while working on samples for articles and books). I enjoyed creating source that would help other developers learn (like writing books and articles). It really was the best of both worlds.

    That makes me interested in working in more Open Source projects. It makes me want Open Source projects to succeed.

    How to evaluate the future

    One of the most promising aspects of the Soft Launch of the ColdePlex Foundation is that Microsoft has not released this ‘totally baked’. They are openly asking for opinions, participation, and intend to replace the interim board with a permanent (er, permanent for one term. see the bylaws) board. I would expect Microsoft to be represented, but I would not expect them to have a true majority.

    I think the board of advisors (or a software due diligence committee) could be more interesting. Somehow, the CodePlex Foundation will need to make a decision on every project that asks to join the foundation. Should it be accepted? One of the most important tasks around that decision is to determine the pedigree of the code that makes up the project. As I said earlier, the probability is small, but the risks are great. One of the greatest services the Foundation could provide would be reference legal documents and accompanying procedures for running a project, accepting patches, and inviting contributors that minimizes the risk associated with IP ownership.

    Furthermore, running their organization so that large enterprises feel confident using those projects that are part of the Foundation would be a huge service.

    My criteria for measuring the success of the CodePlex Foundation in six months are these:

    1. The community is satisfied with the Foundation’s governance structure.
    2. At least 20 new projects in the CodePlex Foundation.
    3. At least one Fortune 50 company has adopted at least one CodePlex Foundation project.

    If the CodePlex Foundation achieves that, I’ll be very happy.

    My own Call to Action

    I’m excited enough about the CodePlex Foundation to take action.  Here’s my TODO list:

    1. Continue to participate in the discussions online, and in any other way that I can.
    2. Start or continue at least one project that gets accepted by the CodePlex Foundation. (I want to experience the process of getting a project accepted by the Foundation first hand.)
    3. Contribute to someone else’s CodePlex Foundation project. (I want to experience how the foundation treats external contributors first hand.)
    4. Convince one customer to use a CodePlex Foundation project. (Yes, this is probably predicated on the previous two items.)

    What are you going to do?

    Created: 7/23/2009 3:04:04 AM

    A friend asked me about some issues he was having using Enumerable.Cast<T>(). In his mind, it just wasn’t working. Like so many problems, it was working correctly, just not the way he expected. It’s worth examining.

    Examine this class:

                 1:
              public
              class MyType
                 2: {
                 3:
              public String StringMember { get; set; }
                 4:  
                 5:
              public
              static
              implicit
              operator String(MyType aString)
                 6:     {
                 7:
              return aString.StringMember;
                 8:     }
                 9:  
                10:
              public
              static
              implicit
              operator MyType(String aString)
                11:     {
                12:
              return
              new MyType { StringMember = aString };
                13:     }
                14: }

    Note:  I normally recommend against conversions, (See Item 28 in Effective C#), but that’s the key to this issue.

    Consider this code (assume that GetSomeSttrings() returns a sequence of strings)

                 1: var answer1 = GetSomeStrings().Cast<MyType>();
                 2:
              try
            
                 3: {
                 4:
              foreach (var v in answer1)
                 5:         Console.WriteLine(v);
                 6: }
                 7:
              catch (InvalidCastException)
                 8: {
                 9:     Console.WriteLine("Cast Failed!");
                10: }

    You’d expect that GetSomeStrings().Cast<MyType>() would correctly convert each string to a MyType usingthe implicit conversion operator defined in MyType. It doesn’t, it throws an InvalidCastException.

    The above code is equivalent to this construct, using a query expression:

                 1: var answer3 = from MyType v in GetSomeStrings()
                 2:               select v;
                 3:
              try
            
                 4: {
                 5:
              foreach (var v in answer3)
                 6:         Console.WriteLine(v);
                 7: }
                 8:
              catch (InvalidCastException)
                 9: {
                10:     Console.WriteLine("Cast failed again");
                11: }

    The type declaration on the range variable is converted to a call to Cast<MyType> by the compiler (See Item 36 in More Effective C#). Again, it throws an InvalidCastException.

    Here’s one way to restructure the code so that it works:

                 1: var answer2 = from v in GetSomeStrings()
                 2:               select (MyType)v;
                 3:
              foreach (var v in answer2)
                 4:     Console.WriteLine(v);

    What’s the difference? The two versions that don’t work use Cast<T>(), and the version that works includes the cast in the lambda used as the argument to Select().

    And, that’s where the difference lies.

    Cast<T>() Cannot access User Defined Conversions

    When the compiler creates IL for Cast<T>, it can only assume the functionality in System.Object. System.Object does not contain any conversion methods, therefore, Cast<T>() does not generate any IL that might call any conversion operators.

    Cast<T>() will only succeed if its argument is not derived from the target (or a type that implements the target if the target is an interface), Cast<T> fails.

    On the other hand, placing the cast in the lambda for the Select clause enables the compiler to know about the conversion operators in the MyType class. That means in succeeds.

    As I’ve pointed out before, I normally view Conversion operators as a code smell. On occasion, they are useful, but often they’ll cause more problems than they are worth. Here, without the conversion operators, no developer would be tempted to write the example code that didn’t work.

    Of course, if I’m recommending not to use conversion operators, I should offer an alternative.  MyType already contains a read/write property to store the string property, so you can just remove the conversion operators and write either of these constructs:

                 1: var answer4 = GetSomeStrings().Select(n => new MyType { StringMember = n });
                 2: var answer5 = from v in GetSomeStrings()
                 3:               select new MyType { StringMember = v };

    Also, if you needed to, you could create a different constructor for MyType.

    Created: 6/1/2009 6:53:38 PM

    And, it’s got support for VS2010 Beta 1.

    This is amazingly cool.  I downloaded and installed the Azure May CTP (both the SDK and the Visual Studio Tools (link here).

    Being that ‘let’s see if we can break this’ kind of person, I ran the same sample in VS2008 and VS2010 on the fabric on my box.  Both ran concurrently without problems.  The developer fabric kept each copy in its own sandbox.

    After you get the Azure toolkit, you can get the samples (separate download for both VS2010 and VS2008) here.

    Created: 5/26/2009 9:25:05 PM

    I’m just going to assume that all readers of my blog know that Visual Studio 2010 Beta one has been released.

    I’ve been running it almost exclusively since I downloaded and installed it. There’s a lot to like. For this first post, I’m going to limit my discussion to a very small set of IDE features that thrill me in the new release.

    Tear away editor and tool windows

    This is a neat feature for single monitor work, but is absolutely wonderful in a multi-monitor scenario.  In VS2010, you can grab the title tab in an editor window (design or code window) and move it out of the VS IDE frame window. It’s wonderful when you’re trying to do some work that requires examining more than one code file at a time.

    The fact is that this feature works for tool windows as well as editor windows.  In my setup, I’ve tried to maximize my main code window in the main monitor.  Properties, Solution Explorer, and the build output windows are on the secondary monitor. I’ll pull editor windows out when I need to see multiple code (or designer) files for a particular task.

    PascalCased IntelliSense

    Love this for discovering classes or methods in the .NET Base Class Libraries. Intellisense now picks up targets that contain the words you type, even if they are not at the beginning. For example, if you type ‘enumer’ in a code window, Intellisense will (as always) contain Enumerable. It will also contain IEnumerable, IOrderedEnumerable, and ParallelEnumerable.

    It’s a great way to discover something that might be the solution to your current coding problems.

    Real TDD Support: Generate From Usage

    Create From Usage means you can really follow a TDD methodology. You can right test scenarios that describe how you want to use a class. Once you’ve written the test, you have a test that doesn’t compile (like now). Right click on each item with red squiggles and select “Generate”.  Types allow you to generate a new class (quick default), or “Generate Other” which displays a dialog that lets you select a class, interface, enum, or struct. Furthermore, that dialog lets you select the access modifiers on the type, select a destination project (if you have multiple projects in your solution).  You can follow the same workflow to generate methods or properties once you’ve created the types.

    The IDE will create members that throw NotImplementedExceptions, so all your tests will fail. But, isn’t that the point of TDD?  Once you have those failing tests, you have a task list to make them green.

    In future posts, I’ll touch on more of the major features in VS 2010. I wanted to start with these hidden gems because they can be so easily overlooked if you just start using the new version with your old work patterns.

    Created: 4/10/2009 2:13:36 AM

    I’ll start this post with a couple caveats. I’m learning the Live Framework SDK, just everyone else. This (and upcoming) blog posts on the Live Framework are based on my initial learning on Live Framework. All the usual disclaimers apply.

    My plan is to work through some of the Live Framework SDK samples. As I’m doing that, my normal work pattern is to take lots of notes on what I’m learning. My blog seems as good a place as any. Unlike posts on technologies where I’ve spent lots of time, I’m a noob on the Live Framework too. But, there’s only one way to learn.

    The Project Manager Sample

    I decided to start with the WPF Project Manager sample. It’s a WPF application that lets you create projects. You can add milestones to those projects. Obviously, you can edit both projects and milestones. The projects are stored as MeshObjects. The milestones are stored as DataEntries in the MeshObjects (representing projects).

    This first post is mostly looking at the application, with a small look at the code.

    I ran the code, created a project and some milestones.  Cool enough.

    Then, I went to the developer mesh website, and looked at my mesh desktop. I expected to see new folders, or something that showed the projects and milestones I created. I was surprised that nothing was there.

    The answer was in the code. Remember from my first post on the Live Framework that the MyPhotos application used resource types of LiveMeshFolder, and LiveMeshFiles. That makes objects that are visible in the mesh, obviously as folders and files.

    This sample uses different resources types. The sample defines a “Project” resource type for the project, and a “Milestone” type for the milestones.

    Both Project and Milestone are C# classes. They are (more or less) POCO objects. They are decorated with the DataContract attribute (and their properties are decorated with the DataMember attribute).

    Here’s the Project type:

                 1: [DataContract(Namespace = "Microsoft.Samples.Workflow.ProjectManagerWPF")]
                 2:
              public
              class Project
                 3: {
                 4:
              /// <summary>
            
                 5:
              /// UUID of the parent MeshObject
            
                 6:
              /// </summary>
            
                 7:     [DataMember]
                 8:
              public
              string MOID { get; set; }
                 9:
              /// <summary>
            
                10:
              /// Title of the milestone (during save/update, this matches MeshObject.Resource.Title, 
            
                11:
              /// but is stored here when the custom object is databound instead of the resource)
            
                12:
              /// </summary>
            
                13:     [DataMember]
                14:
              public
              string Title { get; set; }
                15:
              /// <summary>
            
                16:
              /// Date when project will be started
            
                17:
              /// </summary>
            
                18:     [DataMember]
                19:
              public DateTime KickOffDate {get; set;}
                20:
              /// <summary>
            
                21:
              /// Estimated Date for Completion
            
                22:
              /// </summary>
            
                23:     [DataMember]
                24:
              public DateTime CompletionDate {get; set;}
                25:
              /// <summary>
            
                26:
              /// Date when project was shipped
            
                27:
              /// </summary>
            
                28:     [DataMember]
                29:
              public DateTime ShippedDate {get; set;}
                30:
              /// <summary>
            
                31:
              /// Description of Project
            
                32:
              /// </summary>
            
                33:     [DataMember]
                34:
              public
              string Description {get; set;}
                35: }

    Storing and retrieving the Project type from the Mesh is straightforward Live Framework code. Here’s the code to read a project:

     

                 1:
              //grab the Project Instance object from the mesh object and populate an instance of our Project Domain Class
            
                 2: Library.Project SaveProject = this.ExistingProjectMeshObject.Resource.GetUserData<Library.Project>();

    You simply convert the Resource to the POCO type, using the GetUserData<T> method to convert the resource. Cool. Saving it back is just as easy:

                 1: MO = ExistingProjectMeshObject;
                 2: SaveProject = ExistingProjectMeshObject.Resource.GetUserData<Library.Project>();
                 3: MO.Resource.Title = tbTitle.Text;
                 4:  
                 5:
              //Set the custom attributes of the mesh object to the values from the library/domain class, 
            
                 6:
              //this will popualte the userfield data with the deserialized content from the Project object created above
            
                 7: MO.Resource.SetUserData<Library.Project>(SaveProject);
                 8:  
                 9:
              //Set the type of the mesh object's resource to PRoject
            
                10: MO.Resource.Type = "Project";
                11:  
                12:
              //Update the object in the cloud.
            
                13: MO.Update();

    The SetUserData<T> call converts the POCO Project object to a mesh resource. Then, you just need to send the data to the cloud.

    Future posts will dive into the code in more detail, and start on some other mesh style programming. Just this little dive makes me think more about what I can build with this.

    Current Projects

    I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

    All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

    I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

    Or, if you have a group of volunteers, talk to us about hosting a codeathon event.