There and Back Again : Visual Studio 2008

Building NHibernate 1.2.1GA on .NET 3.5

hdierking — Fri, 21 Mar 2008 00:49:14 GMT

I recently reached a point where for reasons that I'm sure you can all relate to, I decided to clean my laptop and rebuild. I therefore did a clean install of Vista with SP1. As a quick aside, SP1 does actually seem to improve performance - particularly when starting up or closing down. Anyway, after I was back up and going again, I setup NAnt and then downloaded the NHibernate 1.2.1 GA source. However, I ran into 2 major problems building, so I thought I would share those, along with how to work around them.

Both problems can be corrected by modifying the markup in the build-common/common.xml file.

The first problem had to do with the fact that the build was expecting the clover library. The solution was simply to add a condition to the property set declaration. I'm not going to spend any more time on this one, because the problem/solution is documented here.

The second problem is that there is no target in the build file for .NET 3.5. On most machines, this isn't a big deal because you've probably upgraded framework versions incrementally, and the build file can target 2.0 with no problem. Because I have a fresh OS/Framework install, I got an error saying that .NET 3.5 is not supported for my build of NHibernate. This can be worked around by adding a target declaring a configuration for .NET 3.5, like so:

<target name="set-net-3.5-framework-configuration">
    <property name="nant.settings.currentframework" value="net-2.0" />
    <property name="current.build.defines" value="${build.defines}NET,NET_2_0" />
    <!-- not using SDK_v2_0 because ndoc throws an exception -->
    <property name="link.sdkdoc.version" value="SDK_v1_1" />
    <property name="merge.targetplatform" value="v2.0" />
</target>

When you get into the config file, you'll see that all I did was create a target with 3.5 declared as a part of the target name, and then coped the body from the 2.0 target inside of my 3.5 target. Initially, I had actually configured the properties to make them specific to .NET 3.5. Unfortunately, I later discovered when I tried to use the compiled assemblies that many of the source files have preprocessing directives that are specific to the defines declared in the build properties. For example, the ISet<T> source code is wrapped with the following directive.

#if NET_2_0

Anways, after making these 2 changes, I was able to build with no problem, and NHibernate continued to work as advertised.

Wow - That Was Annoying

hdierking — Mon, 19 Nov 2007 05:18:53 GMT

So I'm in an awkward place right now when it comes to programming. In addition to the fact that I no longer program on a day-to-day basis (which is starting to bug me a little more than it used to as I'm afraid I'm starting to atrophy a bit), I'm also now up on Visual Studio 2008 - which is really great in a lot of respects - but at the same time is kind of bumming me out. I'm not bummed because of anything inherent in Visual Studio - I'm bummed because Resharper just doesn't really work all that great in it. Don't get me wrong - R# works - but the semantic analysis tools don't yet work with a lot of the C# 3.0 language enhancements - and as much as I tried to ignore the R# compiler errors on things like Linq queries, I finally just got tired of it an uninstalled R#, impatiently awaiting the 4.0 release.

Firstly, let me just say that not having R# is miserable from a refactoring standpoint.

Secondly, losing R# led me down the path to another headache (which is the subject of this post) - I no longer have a VS add-in runner for NUnit. Yes, I know - I could (and probably should) go back and download TD.NET - but instead, I was curious to see how easily it would be for me to just convert my NUnit tests to VS 2008 unit tests. In short, it's not terribly difficult, but getting there was a frustrating journey.

Why? Because unlike NUnit, where a test fixture is explicit in code (and only in code) via the TestFixture attribute, VS tests rely on a second piece of metadata in order to have them run via the VS test manager/test runner. That metadata is not found in the *.vsmdi file - instead, it's actually a property in the project file of your unit test project.

Therefore, if you started from a regular class library project and need to have it recognized by VS as a "test project", open the *.csproj file in notepad and add the following to any PropertyGroup.

The first Guid identifies your project as a test project (the second is the language I believe - feel free to correct me if I'm wrong).

Linq-i-fying My Existing Projects - Part 1

hdierking — Wed, 14 Nov 2007 19:09:39 GMT

To be honest, I don't know how many parts there will end up being - since the longer I'm away from day to day developing, the fewer projects I have to go back through. However, I can think of a few more off the top of my head - so I still think that "Part n" is a fair statement.

Anyway, for a sample golfing application, I have the following hierarchy (fragment).

Now, ignoring for the moment the fact that I didn't make Round a generic and thereby avoid the need for it, the following method in Round validates that either Players or Teams can play a round of golf, but not a mixture of both (e.g. - a single player cannot go up against a team).

private void ValidatePlayerTypeConsistency(Player[] players) {

foreach (Player player in players) {

if (!player.GetType().Equals(_expectedPlayerType))

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

Using a C# 3.0 Linq query, the imperative structure of the foreach loop can now be replaced with a more declarative one as follows.

private void ValidatePlayerTypeConsistency(Player[] players) {

bool hasUnexpectedPlayers = (from p in players select p)

.Any(p => !p.GetType().Equals(_expectedPlayerType));

if(hasUnexpectedPlayers)

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

A couple of quick things to notice here:

In the Linq query, the C# 3.0 language extensions do not cover the entire breadth of Linq functionality (e.g. - the "Any" quantifier). When you run into cases like this, remember that it is perfectly acceptable to mix the language extensions syntax with the standard extension method/lambda syntax. You can do this by simply enclosing the language extensions syntax block in parentheses and then calling additional methods on the result.
My Linq query syntax didn't really reduce my total line count and the declarative syntax is arguably harder to read. To this, I can only say a) this is a really simple example and b) like anonymous delegates and generics, you get used to it. That said, this example should illustrate that you should take a pragmatic approach to incorporating new features like Linq into your applications.

A final note here - I am ONLY able to do this type of code replacement because I have a great set of unit tests backing me up. In fact, when I first tried out the Linq approach, my test failed. DO NOT make changes like this to working applications without having good tests to back you up.

Hopefully, I'll bring you some more complex examples soon.

ALT.NET Conference, Day 2 - Taking the Good With the Bad

hdierking — Sun, 07 Oct 2007 07:57:27 GMT

Today's post is actually a nice continuance of yesterday's because it deals very specifically with one of the issues that I raised yesterday - specifically the issue of the emerging tenuous relationship between the ALT.NET community and the rest of the professional .NET developer community. That said, today was fantastic - great people, great discussions - and a great show of forthcoming technology by ScottGu. So, in sum, we'll deal with the good and the not so good in tonight's post (IMHO <g>)!

The Not So Good - How to Be a Catalyst for Change In the Community

I went into this session hoping that individuals would come in wanting to share success and/or failure stories related to creating an environment that bought into at least some of the principles of agile - or at the very least became more passionate about writing great software. I also went in expecting there to be a fair amount of Microsoft bashing because of designers, code generation, NIH, etc... (I would mention MSDN/MSDN Magazine here, but that session is tomorrow, so I'll deal with that in the morning). What actually unfolded actually surprised me a bit. So firstly, I should say that there were some success stories shared. J.P. Boodhoo talked about some of the successes he has had with "lunch & learns" - Scott Hanselman and Jay Flowers talked about growing influence exponentially via a style that for this post we'll call "influencing the influencers" (Jay - you had mentioned a book that dealt with this topic - if you're reading, please post the title in the comments). Past those (and a few other) examples, though, the conversation took what I considered a fairly cynical and elitist turn. Earlier I mentioned that I was surprised a bit by what unfolded. What surprised me was that the frustration expressed was not as much directed at Microsoft, but was directed at the general development community. It basically came across as "why won't all these people stop calling me dogmatic and listen to what I'm trying to tell them?!?" Several in the room made the argument that energy should only be expended on influencing those who wanted to be influenced. Huh?? If they...want to be influenced....doesn't that already....nevermind. Anyway, I basically came away from that session with 2 concluding saddening thoughts about many in the ALT.NET community.

They will always be 10 steps ahead of the rest of the professional development community because they are incredibly smart, talented, and motivated.
They will always be frustrated because they are narcissistic.

OK - maybe it was because I drank more coffee, maybe it was something else, but the day got much better as it progressed. Let's move on.

The Good - DSLs/NHibernate

I'm grouping these together because I walked in half way through the DSL talk and I just didn't take that many notes from the NHibernate talk. In fact, I think I'm just going to do bullet points here.

DSL

I hadn't realized that Microsoft released the source code for the .NET Framework Class Library. Totally cool - especially since, as ScottGu mentioned, they shipped it with the symbols, so profiling and debugging into the framework itself is now simple.
There was a lot of talk about DSL support in Ruby. I haven't worked in Ruby so I really can't speak to this - but now I'm curious.
One really interesting comment that ScottGu made, regarding DSLs is to make sure that you have mastered your GPL first, as this will provide you the best platform from which to jump into DSLs.

NHibernate

It was tough to blur the lines between where we crossed into a general DDD discussion and when we were still talking about NHibernate - particularly when we were discussing architectural patterns for DALs, etc...
To the NHibernate team (or someone with the time to look at this on the forge) - It would be totally cool if we could get JIT loading of HBMs, or at least have the option to suppress fail-fast when building the session factory. This came out of a discussion where many in the group were expressing the pain felt when one invalid HBM file caused every unit test to fail (or nearly every view to crash) because the session factory couldn't be created.
On that note, a MSBuild/NAnt HBM validator build task would be nice for plugging into the build.

The Rockin' - ScottGu's Show and Tell

So I haven't really had a lot of exposure to MVC in web applications (yes, I have let the whole RoR phenomenon pass me by - for shame, I know). And as a result, I really didn't see the point of the whole paradigm shift to MVC. I did DVC in MFC and it was a pain - so perhaps I was just avoiding the topic because of past aches, but for whatever reason, this was all new to me. So anyways, Scott demonstrated the new MVC framework that will be available in CTP form pretty soon. Honestly, it's pretty cool. I don't really buy into the argument that MVC is absolutely necessary to cleanly separate the logical layers of your application. I have been doing DDD for a while now and have never run into a major problem with bleeding of concerns on web projects - but maybe that's just me. However, if you're into having leaner, better controlled HTML and, more intuitive URLs, and reduced probability for concern-bleed, the MVC framework is definitely the way to go.

On a related note, let the record show that Scott Bellware is officially my favorite heckler. Scott - whenever you're in Redmond, the drinks are on me!

Back to the MVC discussion, my main next action is to see if I can actually find the bits so that I can get up to speed a bit. Who knows, maybe I'll even take the approach of one of my close friends at P&P and buy a Macbook Pro to play with RoR <g>!

The Confused - DDD

So since this post is getting long, I'm going to sum this session up with a pretty simple statement. Eric - A little help please? There continues to be a great deal of confusion and disagreement in the DDD community about some very fundamental concepts. Examples include the definition of a domain service, an application service, and the very distinctive characterics of DDD that make it different than simply good OOP heuristics.

On a closing note, I have never seen so many iPhones in one place.

So Mad Right Now

hdierking — Thu, 04 Oct 2007 05:24:38 GMT

All I want to do is install VS 2008 - that's all. Unfortunately, the uninstall story with VS 2005 is so complicated that in the process of individually uninstalling the 10+ different applications (according to MSI), I have somehow also corrupted my LifeCam software, so now I'm unable to webcam with my wife and new baby while traveling.

Maybe I had never noticed before because I was a full-time developer and I was in a constant state of reformatting my machine anyway, but seriously - is formatting the only viable option for installing Visual Studio?

At the moment, it certainly seems that way...

OBA - Are We There Yet?

hdierking — Sun, 26 Aug 2007 08:40:04 GMT

I am a beliver in the power of Office as the pre-eminant smart client for the majority of LOB applicaitons. However, I also think that we're still a little ways off from realizing my belief - not because of some entrenched NIH complex held to by consultants (though there is some of that (NOTE: because I was a consultant for at least half of my career, I take the liberty of making such broad generalizations in good fun <g>)). - but because in general, both the tooling and the guidance for building business apps based on Office as a platform has been somewhere between sketchy and non-existant.

Office 2007 brought us closer with the adoption of the OpenXML document formats - and with the forthcoming VSTO enhancements, like click once support for customizations, we take another step. Also, today I stumbled upon this piece of guidance for developers - I'm not sure that it's necessarily guidance, but it certainly at least lays out the different options (and it just looks cool).

So while we're not yet past having to deal with COM and all of its associated headaches, we can at least have a pretty WPF applet to play with.

C# 3.0 Object Initializers

hdierking — Mon, 13 Aug 2007 18:59:38 GMT

As I'm sure you are aware, C# 3.0 includes a new language feature called object initializers. Put simply, object initializers enable you to initialize the state of an object with a single expression that does not require use of parameterized constructors. A few million examples on the object initializer syntax ranging from the simple to complex are out there on the Internet, so there's no need for me to go into them here. I do, however, want to make a couple of quick points.

1. The object initializer syntax sits on top of the standard C# language - and it does not allow you to break the basic OO rules of the language. It feels to me like many of the language features coming down the pipe (at least for both C# 2 and 3) have their real value when taken in groups. For example, while a cool feature, anonymous methods didn't shine quite so brightly until used in conjunction with generic delegates and the type inference capabilities of C# 2.0 (obviously, lambda expressions are the latest incarnation of this capability). Similarly, object Initializers seem to have their most value when used in conjunction with anonymous types - and more specifically, when used with anonymous types in the context of a LINQ projection operation.

That said, object initializers should not be thought of as a way to side-step basic object heuristics (and from the implementation perspective, the C# compiler won't let you). For example, a basic tenant of OO design specifies that an object should be ready to use after constructed. As a result, many classes are designed such that there are no parameterless constructors (since the result would yield a class that still required initialization after the object was constructed). In this case, you must call a parameterized constructor even when using the object initializer syntax. It is worth pointing out, however, that the object initializer syntax is quite handy here in eliminating a lot of "shortcut constructors" from the code base. The constructor code can require only the parameters that are absolutely necessary to construct the object, while the object initializer syntax can be relied on for allowing the user to provide additional state to the constructed object.

Just in case you hadn't heard yet, this new language feature (and all of the other C# 3.0 features) were implemented without requiring any changes to the IL. Let's take a look, then, at an example of the syntax and the code generated by the compiler.

Customer jenn = new Customer("default",0) { Name = "jennifer", Age = 31 };

When the project is built and the assembly is reverse engineered, we can see that the generated code is as follows.

private static void Main(string[] args)
{
    Customer <>g__initLocal0 = new Customer("default", 0);
    <>g__initLocal0.Name = "jennifer";
    <>g__initLocal0.Age = 0x1f;
    Customer jenn = <>g__initLocal0;
}

We can see here that our parameterized constructor was called as it has always been, the constructed object is assigned to a temporary variable, our additional properties specified in the initializer syntax are set, and the reference held by our temporary variable is then assigned to our declared variable. Pretty straightforward.

2. Be cautious of using object initializers with value types. I have a real love-hate feeling for language features like this. On the one hand, they can make life easier and code cleaner. On the other hand, they can create a false sense of security if one assumes that the feature behaves the same in all contexts. Take another look at the generated code. For reference types, this is absolutely no big deal. A managed reference has a tiny footprint, and hey - what's one more reference for the GC to track <g>?

For value types, the story is a little different. Because you have 2 different variables, this single object initialization will end up consuming at least twice the memory required by the type itself. In the code shown, this is probably not a big deal. However, if your value type is a little bigger, and if you're initializing it a few hundred times in a loop, you can see how you could inadvertently increase the footprint of your code. For the DDD crowd, this is definitely something to be cognizant of - especially if you are using value types to implement value-objects.

Running Vista in VPC 2007

hdierking — Sat, 04 Aug 2007 02:10:37 GMT

I have my Orcas test bench environment setup in VPC 2007 using a Vista base image as the foundation for my Orcas differencing drive. That said, it has been driving me absolutely crazy how slow Vista performs under VPC - so after a quick search, I came across this post from a while back by Ben Armstrong. Just doing step 3 did wonders for me. Vista now performs at level that's more than acceptable for me (by acceptable, I mean that the performance is such that it doesn't compete with Orcas for my attention).

DinnerNow v1.3 Is Released

hdierking — Mon, 04 Jun 2007 06:14:33 GMT

If you're looking for a good sample that shows how to apply some of the new .NET 3.0 technologies, check out the latest distribution of the DinnerNow.Net sample application. More information here.

WF Custom Actions - Location Matters!

hdierking — Tue, 29 May 2007 03:47:50 GMT

Firstly, many thanks to Kavita Kamani for helping me figure this one out.

As you may or may not know, Windows Workflow Foundation contains a lightweight, forward-chaining rules engine (by lightweight, I mean to say non-Rete). In WF rules, a rule is defined by a condition, a collection of "then" actions, and a collection of "else" actions. One of the really cool things about the way that the rules engine is structured is that it allows you to create your own custom actions. Why would you want to do this? Quite simply, because within a custom action, you have access to both the validation context and the execution context. Therefore, custom actions in effect provide a means for extending the rules language.

There's only one gotcha to look out for when creating custom actions (there might be more, but here's the one that bit me). If you create the action within the same project that contains the workflow using the action, you will get the following error when you try to call it from within the rules editor.

After beating my head against a wall for a while trying to figure out the problem, I realized that if I moved my custom action to another project and referenced it from the project that contained my workflow, everything worked just fine. Kavita confirmed this behavior and explained that the WF Rule Editor uses CLR types rather than design-time types. As such, as far as the rules editor is concerned, my custom action doesn't exist so long as it is in the same project.

Partial Methods - I Object?

hdierking — Mon, 28 May 2007 07:48:28 GMT

No, not partial classes. Partial methods. As Wes talks about in his latest post on language enhancements in Orcas, partial methods are another new C# language feature that allows you to define the signature of a method in one part of a partial class and the method implementation in another part. For example, consider the basic entity class "SomeEntity".

   1: public partial class SomeEntity

   2: {

   3:     private string _someAttribute;

4:

   5:     public string SomeAttribute

   6:     {

   7:         get { return _someAttribute; }

   8:         set {

   9:             Validate(this, "SomeAttribute", value);

  10:             OnSetting(this, "SomeAttribute", value);

  11:             _someAttribute = value;

  12:             OnSet(this, "SomeAttribute");

  13:         }

  14:     }

15:

  16:     partial void OnSet(SomeEntity someEntity, object p);

17:

  18:     partial void OnSetting(SomeEntity someEntity, string p, object value);

19:

  20:     partial bool Validate(SomeEntity someEntity, string p, object value);

  21: }

On cursory inspection, this class appears like any regular entity-style class. However, check out lines 16, 18 and 20. What we see here is a method signature prototype - much like what we would see in an abstract base class. However, rather than using the abstract mechanism to facilitate extension, we are using a new keyword (well, new in this context anyway), "partial", to describe our extension mechanism. In order to extend any one of the 3 methods declared as partial, a developer simply creates another part of the partial class and implements a method using the partial keyword and the same method name. I'm hesitant to make any assertions about constraints on the signature as I have yet to get the Orcas beta 2 bits and do more detailed testing. However, if I read Wes' blog correctly, I think that there may be some room for parameter redefinition.

   1: public partial class SomeEntity

   2: {

   3:     partial void OnSet(SomeEntity someEntity, object p){

   4:         //log that the property was successfully set

   5:     }

   6: }

So, after this very basic example, the obvious question - why? I've heard a lot of answers to this question. However, the one rising to the top is that partial methods were added in order to provide performance optimization to code generators - most notably, Linq to SQL and Linq to DataSet. I've also heard partial methods described as a way of doing compile-time aspect weaving, but let's deal with the performance optimization characteristics in this post.

Wes has described the primary purpose of partial methods as a way to do lightweight event handling. I am really hesitant to use the phrase "event handling" as I think that partial methods are more of an alternative to virtual method calls than they really are to events. Therefore, I'm going to go out on a limb and say that partial methods are a more lightweight means of composing functionality at the method level. For you patterns folks, it is a performance optimization around the template pattern. How is it optimized? Because in the current world, where the pattern is implemented through virtual methods, the compiler calls a virtual method regardless of whether or not that method has been extended in a derrived class. In the world of partial methods, the compiler checks to see whether the partial method being called has a concrete implementation defined and, if it does not, the compiler does not generate a call to that method. Therefore, given our 2 examples above, if we reverse-engineered our compiled assembly, we would see that the set accessor for the SomeAttribute property looked like the following.

   1: public string SomeAttribute

   2: {

   3:     get { return _someAttribute; }

   4:     set {

   5:         _someAttribute = value;

   6:         OnSet(this, "SomeAttribute");

   7:     }

   8: }

So my general thinking on this is actually very similar to my general thinking on extension methods. It seems to me like both were added as general language features, but added to support a very specific use case - Linq. Now, that doesn't mean that I'm suggesting that they have no uses outside of Linq. It does mean, however, that I think that they should have VERY limited use out there in the general application development universe, as I believe they have the capacity to do a great deal of harm.

Why do I believe this? Because fundamentally, partial methods seem to take away from the expressiveness of code and add greater potential for side effects. The more time I spend thinking about partial methods, the less concerned I am with the first point. For example, considering our set accessor, when using partial methods we would never actually know whether our method call would be called called - as the compiler would determine this based on the definition of the other class parts. Initially, I thought that this was a really bad thing - until I thought more about how the template pattern was implemented by using virtual methods - and then thought about how it could be implemented with an interpreted language like JavaScript. In both cases, the expectation for the developer is essentially the same - "If I have a custom implementation of the method, run it; otherwise, if there is a default implementation, run that; otherwise, do nothing." With virtual methods, however, there was no semantic to express "do nothing" - you had to create an empty method body. Therefore, partial methods actually allow for a more expressive grammar.

That does not outweigh the badness of the second danger, however. With virtual methods, you at least have some determinism around the call order. For example, if I overrode a method in a class, I could sleep soundly at night knowing that my overridden method would be called every time it was called on my class. If I did not override a method, I could have that same level of confidence knowing that my base class method would be called. With partial classes, there is no 1:1 parent:child relationship - there is no limitation on the number of class parts that can be created - and the same is true of partial methods. There is then (IMHO) a huge risk of unintentionally introducing side effects that are really difficult to debug.

In conclusion, one of the questions I would raise is this. If partial methods were essentially a language supplied performance optimization for people writing code generators, why make it a language feature at all? Why not make it something implicit in the compiler - similar to how the C compiler automatically inlines simple methods?

Linq for NHibernate

hdierking — Tue, 10 Apr 2007 03:42:28 GMT

A while back, I posted on lambda expressions in C# 3.0. In that post, I concluded by saying the following.

"Personally, I would love to see somebody write an extension to NHibernate to allow use of Linq queries in the place of HQL – so if anyone's looking down that path, please let me know!"

Well, it looks as though the ball was already rolling – looks like one of the NHibernate community greats, Oren Eini, is currently working on an implementation – and the best part – it looks like he's reporting some of his discoveries along the way.

Orcas Certifications Follow-Up – Implications for MCPD

hdierking — Mon, 26 Mar 2007 08:43:58 GMT

I wanted to take a quick second to do 2 things.

Update you on our plans for a set of Orcas Technology Specialist exams and certifications
Explain the role that these new TS certifications will play in the MCPD certifications

So firstly, here's the updated plan for the Orcas/.NET 3.5 timeframe. The names here may be different than the final names, but you should be able to get the general idea. Also, I've highlighted the new exams.

Certification	Exams
MCTS: WPF	TS: WPF + 70-536
MCTS: WCF	TS: WCF + 70-536
MCTS: WF	TS: WF + 70-536
MCTS: ASP.NET 3.5	TS: ASP.NET 3.5 + 70-536
MCTS: ADO.NET 3.5	TS: ADO.NET 3.5 + 70-536

Next, I've received several questions asking what will be the impact of this new content on the MCPD certification. In order to best explain this, let's recap how the MCPD certification works. First, your MCPD is valid for 3 years, starting when you receive the certification. That means that even if we change the MCPD requirements a week after you obtain your certification, you do not have to fulfill the new requirements for 3 years (not to say, of course, that you shouldn't anyways).

Now, let's look at what are the requirements for the MCPD credential. It is a combination of 2 things: TS certifications + exams. One thing I want to make clear up front – Personally, I really don't like upgrade exams. Fortunately, the new gen program is really designed in such a way to support my ambitions of not having upgrade exams. Sometime this coming year (not trying to be ambiguous here – I just don't know when yet), we will release the MCPD renewal requirements. As an example, let's look at the MCPD: Web Developer. In an Orcas world, this certification might look as follows.

MCPD: Web Developer = TS: ASP.NET 3.5 + TS: ADO.NET 3.5 + EXAM: 70-547 (or new exam if we determine that Orcas technologies create new design decision trees)

After the change, new entrants simply need to obtain all of the requirements. For those of you who already hold an MCPD credential and need to renew it, you simply need to fulfill the requirements that you do not have. For example, in the example above, if we do not revise 70-547, you simply need to obtain TS certifications in ASP.NET 3.5 and ADO.NET 3.5.

This strategy ensures that we are able to keep up with the segments of the technology landscape that are changing without forcing you to reassess your knowledge on those areas that have not changed. Additionally, in many cases (ASP.NET) it will be fairly obvious to you which new technologies will become requirements in future MCPD changes. Because the TS certifications follow a release schedule that more closely aligns with those technologies, you can achieve many of the aforementioned MCPD requirements before we even make the program changes.

Hopefully, this strategy is one that makes sense to you and is one that you can agree with. As always, please let me know if you have any questions or concerns.

An Orcas Question…

hdierking — Sat, 03 Mar 2007 00:28:21 GMT

So far, I've told you that we're planning new Technology Specialist certifications around the 3 main technologies in the .NET 3.0 stack. Actually, because both the complete technology solutions and the exams will be released in the Orcas timeframe, these new certifications will roll up under the .NET 3.5 banner (I know – the whole new versioning strategy – yea – I get it…). Anyways, because we are going to be releasing in the Orcas timeframe, there are several additional technologies that will be available. Some of these technologies include language enhancements such as extension methods, lambda expressions, anonymous types, object initializers, etc… Therefore, my question to you is as follows. What are your thoughts around doing a .NET 3.5 foundation exam as a prerequisite exam to all of the other .NET 3.5 TS exams – much like how 70-536 was a prerequisite to the .NET 2.0 TS exams? There are a few options as I see them.

Create a TS-level exam which would cover the items mentioned above in addition to basic .NET FCL content (basically, the 536 content that actually *was* foundational – not GDI+ stuff, etc…). Make this exam a requirement for all .NET 3.5 TS certifications. The positive aspects to this approach, as I see them, are that a) we can focus the foundational content a bit better than we did in 70-536 and b) we can cover the new general features of the .NET Framework 3.5. The main problem with this approach is that it would require existing certification holders (folks who have already taken 70-536) to take another foundation exam. Now, let me say that I don't think that re-validating existing skills is necessarily a bad thing. However, I think it's problematic from a financial perspective – I would hate for existing certification holders to come away with the idea that such an exam was just another way to extract money from them.
Do not create a new foundation exam around .NET 3.5 and make 70-536 as a prerequisite to all of the .NET 3.5 TS certifications. Since a majority of the new language features in .NET 3.5 were added in support of Linq, move this content into an ADO.NET certification path. The positive aspects of this approach are that a) we can leverage an existing exam and b) existing certification holders need only take the 3.5 specific exams (as they will already have passed 70-536). The problem with this approach is that there is potentially some confusion around version numbers (requiring .NET 2.0 foundation as a part of the .NET 3.5 certification).
Do not create a new foundation exam around .NET 3.5 and do not require a prerequisite exam for the .NET 3.5 TS certifications. Since a majority of the new language features in .NET 3.5 were added in support of Linq, move this content into an ADO.NET certification path. The positive aspects of this approach are a) there is no bleed over of version number (see above) and b) there is only 1 exam required in order to achieve certification in .NET 3.5. The main problem (and this is big in my mind) is that new entrants are relatively unproven in terms of general .NET Framework skills.

Please keep in mind that the above in no way represents any formal plan. These are only my thoughts on the matter and I want to get them out there as soon as I can so that you can give me yours. It's always a relatively delicate balancing act to accommodate the needs of new entrants with the needs of existing certificate holders – and to complicate the matter slightly, I would really like to do that here without creating upgrade exams.

I look forward to your feedback.

More C# 3.0 – Extension Methods

hdierking — Sat, 10 Feb 2007 01:05:22 GMT

A while back I wrote a post about lambda expressions in C# 3.0 and how they are one of the enabling technologies behind Linq. I would like to continue that discussion today with a quick overview of something called extension methods. First, I want to say up front that I believe extension methods are one of those features that will be useful for framework developers – but bring a very high risk of abuse if used widely in a general sense. So with that out of the way, I'll cover what extension methods are, how they can be used, and what are some of the "gotchas".

First, an extension method is simply a new technique for extending a class without inheriting from the class, making a partial class, etc… The really interesting thing about this technique is in the implementation details. In C# 3.0, extension methods are implemented by creating a static class (which implies that the methods will be static methods) and using the 'this' modifier on the first method parameter. For example, consider the following.

   1:  namespace LinqTestsHarness.Extensions {

   2:    public static class TestExtensions {

   3:      public static void SayHelloFromInt(this int arg) {

   4:        Console.WriteLine("Hello " + arg.ToString());

   5:      }

   6:    }

   7:  }

As we have described, the extension method is identified by the fact that it is a static method (in a static class) and that it has the 'this' modifier on its first parameter. OK – so now we've go this extension method – what do we do with it? If you remember our working definition of an extension method from above, the method allows us to extend an existing type – and that's exactly what our new method does. For example, we can now run the following code.

using LinqTestsHarness.Extensions; 

... 

int n = 5; 

n.SayHelloFromInt();

And how did this work again? 2 things. First, we imported the namespace containing our extension method. Every time you import a namespace, you bring in every extension method that is defined within that namespace. The second important thing that allowed the above code to work is that we declared our variable (n) of type int – which is of course the type expected by our extension method. The following would not compile because of the type mismatch.

using LinqTestsHarness.Extensions; 

... 

string s = "howard"; 

n.SayHelloFromInt();

So by now you should have a pretty decent understanding of how extension methods work – so let's take a look at how they are used by Linq. Consider the following Linq expression.

IEnumerable<string> expr = from s in names 
  where s.Length == 5 
  orderby s 
  select s.ToUpper();

The Linq keyword such as 'where', 'orderby', etc… are simply shortcuts to extension methods defined in the System.Linq namespace. Therefore, the following is equivalent to the previous Linq expression.

IEnumerable<string> expr = names 
  .Where(s => s.Length == 5) 
  .OrderBy(s => s) 
  .Select(s => s.ToUpper());

So hopefully, you are now starting to see that Linq is not some sort of compiler magic. It is built on the very same language features that you have access to as you design and construct your solutions. Now, as we look at one potential application of extension methods, let me be quite clear that this is not a design pattern that I support – I am mentioning it here because I know that this is a pattern that many people do support, and if it is going to continue being used, extension methods are not a bad way to go about separating concerns. Let's consider object persistence. While there is significant debate over the "proper" architectural pattern for layer interactions, there is a school of thought that advocates the inclusion of persistence operations (Create, Read, Update, Delete) on business objects. One of the counter arguments to this approach is that you are then required to mix persistence code with business code and subsequently tie the business layer to a specific data access provider. In this context (let's forget about all of the other arguments both for and against this technique right now), extension methods provide a creative solution to the problem. For example, consider the following business entity class.

   1:  public class Person {

   2:    private string _name;

   3:    private int _age;

   4:    private bool _canCode;

5:

   6:    public Person() { }

7:

   8:    public Person(string name) {

   9:      Name = name;

  10:    }

11:

  12:    public Person(string name, int age) : this(name) {

  13:      Age = age;

  14:    }

15:

  16:    public string Name {

  17:      get { return _name; }

  18:      set { _name = value; }

  19:    }

20:

  21:    public int Age {

  22:      get { return _age; }

  23:      set { _age = value; }

  24:    }

25:

  26:    public bool CanCode {

  27:      get { return _canCode; }

  28:      set { _canCode = value; }

  29:    }

30:

  31:    public override string ToString() {

  32:      return Name;

  33:    }

  34:  }

If you wanted to maintain your data access code in a separate assembly, yet still have the appearance of data access methods on this class, you could create your data access class as a static class and use extension methods for the data access functionality. This extension class would look like the following.

namespace LinqTestsHarness.DataAccess { 
  public static class DataAccessExtensions { 
    public static void Save(this Person arg) { 
      // ... 
    }

    public static void Delete(this Person arg) { 
      // ... 
    } 
  } 
}

Just like in the previous case, using the extension method is a simple matter of importing the LinqTestsHarness.DataAccess namespace. The first parameter on the extension method constrains the method to only instances of the 'Person' class. Of course, all of the usual OO capabilities apply to extension methods. Were I using an ORM tool for my persistence, I could also create a marker interface and constrain the extension method to that interface rather than the concrete type. You can also create generic extension methods. However, my goal with this post is to simply give you an overview.

Now – a word of caution. While extension methods can be a very handy tool for allowing frameworks to add functionality to existing object models, they should probably be approached with a degree of caution. Like any cross-cutting technique, extension methods can be a real pain when it comes to tracing and debugging. One thing that you absolutely must keep in mind with extension methods is that they are given the lowest priority in terms of method invocation. Practically, this means that if the object instance already contains a method (virtual or otherwise) with the same name as your extension method, that method will always be give precedence over your extension method. Therefore, there's always going to be some degree of brittleness if you design a solution that makes heavy use of extension methods because your extension methods and the object model on which the methods are applied will probably evolve quite independently.

Secondly, and even more dangerous is the fact that although it appears as an instance methods, extension methods are of course static. What that means in IL terms is that extension methods use the 'call' instruction rather than the 'callvirt' instruction. Why is this important? Because the 'callvirt' instruction, the instruction called whenever you call an instance method on an object (in C#), checks for null and throws a 'NullReferenceException' if the object is null – the 'call' instruction does not. Therefore, the following code is perfectly legal.

Person howard = null; 
howard.Save();

Now, obviously, there are a lot of cool things that you can do with extension methods, and I'm not trying to say that you should never use them. Obviously, the Linq team has gained tremendous value from them. However, like with all things in development – just because you have a new hammer, don't turn everything into a nail!