I am doing a spike in ASP.Net MVC now (and I'll talk about this at length at another time). I hit the wall when I wanted to do something that is trivially simple in MonoRail, limit a routing parameter to be a valid integer.

Luckily, just looking at the API signature told me that this is a supported scenario:

Unfortunately, that is all that it told me. This method accept an object. And there is no hint of documentation to explain what I am suppose to do with it. A bit of thinking suggested that I am probably supposed to pass an anonymous type with the key as the route parameter and the value is some sort of a constraint. But what sort of a constraint.

Type information is one of those things that static language actually do, and from experience in both dynamic and static languages, while it is often a PITA to specify types, it actually help for people who read the code. Not often, I'll admit, but it is helpful for the uninitiated.

I am... unused to having this type of problem in C#.

So I did what any developer would do, hit google and tried to find some information about it. Didn't work.

I pulled reflector and started to track down what is going on there. Following a maze of untyped paths that I have not seen the like since the 1.1 days, I finally figured out that the value that I need to push is an instance of IRouteConstraint.

Obvious, isn't it?

In short, and the reason of this post. I am seeing a lot of parameter signatures that look like that, and have barely defined semantics. I would file this under C#.Abuse();

Yesterday I was at the PhizzPop design party in New York. The purpose of the party was to show off the capabilities of the new Expression 2.0 product line. The way chosen to do so was by getting several companies to participate in a content to get the best result. It might have been a good idea, but it back fired tremendously.

One of the reasons that I went to that party was the expectation that I would be impressed by the new capabilities. Instead, what I saw there was... disappointing.

The best candidate application there was adequate. In fact, it was pretty good, but not nearly good enough to take part in a design contest. It is bad when I, a developer with negative UI sense, can spot problematic UI and see how they had to fight with the platform to get it to do things.

And that was the best they had. One of the other application (in a design contest!) had a RadioButton1, RadioButton2 and other things like that showing. They could literally not be bothered to change something as basic as that.

I was very disappointed, and the impression that I got from the entries in the contest is that the platform is a really lousy one. Especially considering the amount of time that was supposedly invested on the entries.

To conclude, I want to quote myself: "I know of people who can do better and faster than that drunk, and while writing the XAML on a stone tablet with a chisel."

Very disappointing.

I got the chance to get an early CTP of Visual Studio 2010. 

This is the post I use to record my first impressions. There is no order to this post, it is just impressions jotted down as I see them.

We seem to have a new start page:

Following the MS & OSS new approach, one of the samples is Dinner Now using Lucene, which is the first project that I found to test.

TFS is still broken:

I really don't like to see this kind of issues in a source control system. It means that it cannot be trusted.

Looks like we have something new here. On first impression, it looks like we have UML integrated into VS.

I took a look at the generated XML, which is the backing store for the diagrams, and it looks like it should work with source control much better than the usual modeling stuff in visual studio.

Another feature that is very welcome for anyone doing presentations is the use of CTRL+Scroll Wheel for zooming.

We are also promised performance improvements for large files, which is nice. Part of the walkthroughs talk about integrating functionality using MEF, which is good.

Looking at the walkthrough for creating syntax highlighting, tagging and intellisense, it looks like a lot of ceremony still, but it seems significantly easier than before.

WPF - It looks like VS is moving to WPF, although this CTP is still midway.

C# has dynamic variables!

dynamic doc = HtmlPage.Document.AsDynamic();

dynamic win = HtmlPage.Window.AsDynamic();

This was talked about in the MVP Summit, a dynamic object is an object that implements IDynamicObject:

Note that we accept an expression parameter (using Linq expressions) and we return a meta object. Show below.

This looks like C# + DLR integration, which is cool. I am looking forward to see what we can do with it.

VS also get some R# like features:

There is also a quick search, apparently, but I am not really impressed. Again, show me something that I don't have.

There is CLR 4.0, so we somehow skipped CLR 3.0. I am glad to know that we have a new runtime version, instead of just patching the 2.0 very slowly.

Threading

System.Threading.Tasks is new, and looks to be very interesting. It also seem to have integration with Visual Studio. It is also interesting because we seem to have a lot more control over that than we traditionally had in the ThreadPoll.

Parallel extensions are also in as part of the framework, not that this would be a big surprise to anyone.

In the CTP that I have, there is nothing about Oslo, models or DSL, which I found disappointing. I guess I'll have to wait a bit more to figure out what is going on.

That was a quick review, and I must admit that I haven't dug deep, but the most important IDE feature, from my perspective, is the CTRL+Scroll wheel zooming. The diagrams support is nice, but I am not sure that I like it in my IDE. Threading enhancements are going to be cool, and I am looking forward to seeing what kind of dynamic meta programming we can do with it.

No, I am not going to bore you with another repetition of the news. Yeah, Microsoft is going to bundle jQuery with Visual Studio and the ASP.Net MVC. That is important, but not quite as important as something else that I didn't see other people pointing out.

This is the first time in a long time that I have seen Microsoft incorporating an Open Source project into their product line.

I am both thrilled and shocked.

The Managed Extensibility Framework is "new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you."

(I was too lazy to think about my own description for it, so I just copied the official one.)

Probably the first thing that you should know about MEF is what will undoubtedly be the most common cause for confusion.

The Managed Extensibility Framework is not an IoC container.

This is not a slug at MEF, it is an important distinction. If you try to judge MEF through IoC container glasses, you will come away confused. It may walk like a duck, but it meows.

MEF is, first and foremost, a composition framework. And its target audience are BIG applications. Those two, taken together, are important to understand what MEF is and how we should look at it.

What is the difference between a composition framework and an IoC container? On the surface, they are doing much of the same thing, managing dependencies for the application in an automated fashion. The difference (and the devil) are in the details.

IoC containers have long ago stopped just managing dependencies. They are taking care of a lot of additional responsibilities. Managing lifecycles, proxies, aspect orientation, event aggregation, transaction semantics and a lot of other features.

In addition to that, there is a lot of focus on problem solving by utilizing the container. Things like generic specialization or component selectors allows you to approach a lot of very complex problems in a completely different mindset.

A composition framework, on the other hand, is focused on a single goal: dependency management.

It sounds like MEF is a subset of what an IoC container is doing, I know. This is not the case. MEF, the bits we have right now, are doing a lot more in the area of dependency management than the containers are doing. Where a container is usually static and opaque, MEF primary focus is to make the dependency management itself a dynamic and transparent process.

This is where the second part of the MEF design goals come into place. MEF is targeting Big applications. The really big ones. One of the immediate customers of MEF is Visual Studio itself.

Things like ( take a deep breath ):

• being able to query meta data without loading assemblies
• statically verify the dependency graph for all the components and reject those that would put the system in in valid state
• being explicit by default
• contract adapters
• discovery
• metadata tagging

All of those are key concepts in the overall dependency management theme. And all of those are the product of having a Visual Studio being one of the first consumers of this project. Visual Studio needs this kind of things, across tens of thousands of components. And MEF is setup to handle those kind of scenarios.

So, MEF is very similar to IoC containers, but it has very different goals (or maybe it would be more accurate to say that it has very different priorities).

Another important aspect of MEF has nothing to do with it at all and everything to do with where it is going to be used. MEF is going to ship with .Net 4.0, which put it in a position to be very widely distributed, but more importantly, since it is on the framework, it can be used by other parts of the framework. Which is where it get interesting.

There are a lot of places in the framework that could make use of a container. IControllerFactory is a good example of something that should not exists, for example. I am ambivalent with regards to that, because I think that the correct abstraction for those kind of things is not necessarily MEF, but that is beside the point.

And that is enough for now, I am going to toss a coin and see if it is going to be Erlang code or meta documentation next.

It is not public yet (but you can call and ask for it), but it will be when SP1 goes to Windows Update. This is the fix for the ExecutionEngineException that appeared in .Net 3.5 SP1, and was found by Rhino Mocks.

It took a while (but not unreasonably so), and it is here, yeah!

This is fixed,  you can get the fix here: http://support.microsoft.com/?id=957541

Here are a few interesting things that I found about .Net 3.5 Service Pack 1:

1. Serialization hangs or throws an OutOfMemoryException with static delegate and ISerializable on 3.5 SP1
2. ExecutionEngineException with ParameterInfo.GetOptionalCustomModifiers and GetRequiredCustomModifiers on 3.5 SP1
3. .NET 3.5 SP1 breaks use of WPF under IIS
4. .NET 3.5 SP1 seems to break .NET 2.0 applications with assembly loading error.
5. .NET Framework 3.5 SP1 breaks type verification

I just googled for "3.5 SP1" on connect.microsoft.com, and took only the verified (by Microsoft) items for the SP1 RTM. There are more, but I didn't feel like spending a lot of time digging there.

I don't remember previous service packs having regression bugs. Certainly not regression bugs as big as these. Number 2 is the one responsible for breaking Rhino Mocks, by the way.

Those are all regressions. That is, it used to work in previous version, now it doesn't.

Not happy at all.

Here is a challenge to Microsoft, Fix This. And fix this in a way that ensure that everyone get the fix. If this means SP1 Refresh, great. But fix this in a way that means that I don't have to answer "you need to call PSS and get KB32423 before you can run" for the next two years.

And fix this from Connect, if you ever want Connect to be useful for something.

Okay, now that we are over the sensationalist headline, the actual problem is more complex than that. Let us assume that we have the following interface:

public interface IComplexGeneric<T>
{
	void GenericMethod<K>();
}

Up until .Net 3.5 SP1, Rhino Mocks was perfectly happy to deal with such an interface (well, not happy, exactly, that requires some hard core code). With .Net 3.5 SP1, this generate an Execution Engine Exception.

Fabian Schmied was kind enough to prove that select is broken here. This is the connect site issue, and I would appreciate it if you can vote for it.

The work around for this would mean that I will have to remove support for mocking F#, C++ and Spec# from Rhino Mocks, and I am reluctant to do so.

This is fixed,  you can get the fix here: http://support.microsoft.com/?id=957541

Some people pointed out that the distinction between public and published can be done using InternalsVisibleTo. This is sort of possible, I agree, but it only works if you think about this as a unit testing measure.

Jon Skeet asked about good usages of InternalsVisibleTo aside from unit testing, and I decided to check and see what the framework is using it for. From cursory observation, it appears to be heavily misused. Just from observing the allowed dependencies make me cringe.

• System.Data allows:
• System.Data.Entity
• SqlAccess
• System.Data.DataSetExtensions
• System.Web allows:
• System.Web.Extensions
• System.Xml allows:
• System.Data.SqlXml
• System.Data.SqlXml allows:
• System.Xml <-- I don't want to know how they got this cycle
• Microsoft.NETCF.Tools allows:
• System.Web.Services <-- This one really scares me
• Microsoft.Office.Tools.Common.v9.0 allows:
• Microsoft.Office.Tools.Word.v9.0
• Microsoft.VisualStudio.Tools.Office.Designer.Office2007
• Microsoft.VisualStudio.Tools.Office.Designer.Office2007Tests
• Microsoft.VisualStudio.Tools.Office.Outlook.UnitTests
• Microsoft.Build.Conversion allows:
• Microsoft.Build.Conversion.Unittest
• Microsoft.Build.Engine allows:
• Microsoft.Build.Engine.Unittest
• PresentationCore allows:
• System.Windows.Presentation
• PresentationFramework allows:
• PresentationFramework.Luna
• System.Core allows:
• Dlinq.Unittests <-- this is annoying, I don't get internals access to that, and I am also writing a linq provider
• System.Design allows:
• System.Web.Extensions.Design <-- well, if I want to write a designer, I have better work for MS...

I am a bit late on posting this, but I suggest taking a look here to read some of the community reactions to the issues we have observed in the Entity Framework.

I will let the document stand on its own, since there is no way I can be impartial here.

I would like to state something (which I also told the Entity Framework team in person):

If someone manages to come up with a kick ass OR/M solution that does what I need (allow me to create maintainable and flexible solutions and has the expendability points to be used on real world projects) and which I, personally, don't have to (help to) write, I would be utterly overjoyed.