Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

While C# has the "because" operator, VB.NET has the "why" query operator

Although VB.NET has in the past missed out on some fairly crucial language features such as anonymous methods and iterators (both absent from VB2005 which shipped with .NET FX 2.0) it seems that it is going to edge C# out in the race for the most obscure operators.  Mitch posted about the C# implementation of the "because" or "justification" operator.  The equivalent will looks something like:

1 + 1 = 2 because 2 - 1 = 1

1 + 1 = 3 because true

1 + 1 = 3 justbecause

Although the implementation is a little more wordy (literally) they extended this concept by adding the "why" operator.  For example

why 1 + 1 = 2

The real question would be what does the why operator return and where could you use it.  Well in the simplest terms the why operator allows the framework to expose any previously defined truths.  For example in Mitch's case where he defined the truth 1 + 1 = 3, you could write the query why 3 + 3 = 9 which would return a proof which includes the truths (1 + 1 = 3, 1 x 3 = 3) as well as an execution plan in the form of a proof tree indicating the order that these truths are applied.

You would think this would be something that C# could easily add into their syntax, allowing you to write:

¿ (1 + 1 == 2)

But unfortunately I have it on good authority that C# will not get this feature as they deem it to be too productive and is a security hole as it allows the developer to query the logic of the .NET Framework developers at Microsoft.

VB.NET needs Iterators

Just reading through the RSS sample I mentioned in my previous post on the Windows RSS Platform and noticed that they are using one of the new C# features in .NET v2, Iterators.  Anyhow the code snippet I'm referring to is:

public static IEnumerable<IFeed> CommonFeedList(IFeedFolder folder)
      Queue<IFeedFolder> queue = new Queue<IFeedFolder>();
      while (queue.Count > 0)
         IFeedFolder currentFolder = queue.Dequeue();
         foreach (IFeedFolder subfolder in (IFeedsEnum)currentFolder.Subfolders)

         foreach (IFeed feed in (IFeedsEnum)currentFolder.Feeds)
            yield return feed;

While not the most elegant piece of code (especially the explicit call to "DoEvents") it got me thinking about how I would do this in VB.  The long answer is that you need to code the full iterator yourself.  Please, please, please VB team can we have iterators?

VB.NET Event Handlers

I was just listening to Bill McCarthy chatting with Ron Jacobs on Arcast about the rich feature set of VB 2005.  One of the points of interest was around the declarative approach to event handlers that VB.NET uses.  For example say I have the following class with an event declaration:

Public Class ClassWithAnEvent

Public Event TestEvent As EventHandler

End Class

Now in VB.NET to wire up an object of this class so that I can receive notification on the TestEvent I can do it declaratively as follow:

Public Class ClassThatConsumesAnEvent

Private WithEvents x As ClassWithAnEvent

Private Sub TestEventHandler(ByVal sender As Object, ByVal e As EventArgs) Handles x.TestEvent

End Sub

End Class

The question is what does this do under the hood.  Well the easiest way to explain this is using our good friend, Reflector, to regenerate the code:

Public Class ClassThatConsumesAnEvent

<AccessedThroughProperty("x")> _
Private _x As ClassWithAnEvent

Private Overridable Property x As ClassWithAnEvent


    Return Me._x

End Get

Set(ByVal WithEventsValue As ClassWithAnEvent)

    If (Not Me._x Is Nothing) Then

    RemoveHandler Me._x.TestEvent, New EventHandler(AddressOf Me.TestEventHandler)

    End If

    Me._x = WithEventsValue

    If (Not Me._x Is Nothing) Then

    AddHandler Me._x.TestEvent, New EventHandler(AddressOf Me.TestEventHandler)

    End If

End Set

End Property

End Class

As we can see from this code, VB.NET is doing a lot of the heavy lifting around adding and removing eventhandlers.  This means that we can easily reassign an object to variable x without having to worry about adding and removing eventhandlers.  This also clears up, for those that were wondering, where eventhandlers are added/removed in VB.NET.

.NET CF Type Load Exception

I received confirmation this morning that an exception I was getting in the application we are building was not a result of our achitecture, but rather a bug in the .NET CF type loader.  Get this though - in order to recreate the exception you have to write some pretty obscure:

Assembly A:

class Foo {}

class Bar<T> {

    T field;


Assembly B:

struct MyValueType{} //has to be user-defined valuetype i.e. struct, enum...

class Child : Foo {}

class MyClass {

    Child c;

    Bar<MyValueType> b;


".NetCF will fail to load MyClass if MyValueType hasn't been preloaded. The workaround is to pre-load the valuetype  (i..e. use it somewhere in the code before MyClass is first referenced).

The problem exists in the .NetCF v2 SP1. We fixed it for the next version of the .NetCF, the fix may also be rolled into next service release of .NetCF v2."  [taken from an email from Roman Batourkov]

ASP.NET Services

This evening I decided that I would venture outside and go and see a movie. Having not judged the distance to the cinema very well I arrived a good twenty minutes early, which meant that I could watch the first part of an video podcast. The show was talking about reusing the services via atlas. It shows how you can wrap the services in a webservice that can be called asychronously by an atlas enabled page. Interestingly, this is the same process you go through if you want to reuse these services in an occasionally connect application.

So I guess the question is why these services aren't exposed by default? The short answer is probably that there wasnt demand for it. That said, it would be an interesting project for someone in the community to do - build a set of services that can be dropped onto a site in order to expose the services for that site. This of course would have to be accompanied with a client side class library that can be configured to reference the services by url. It should also be configured to cache information locally and make update calls asynchronously using the disconnected webservice agent.

The other question is why the services are relevant to a windows application:

Authentication/Roles - Absolutely, after all we need to know what functionality a user can access, assuming they are able to login. Of course, like a domain computer the app would need to be connected when a user first signs into the app. There after their credentials/roles can be cached.

Profile - Especially in light of WPF, where we can use styles to change the appearance of an application the users profile becomes important. Simple things, like where windows are docked and which toolbars are visible, can be included in the profile. Unlike settings which, unless you code your own settings provider, are saved locally, profiles can be centrally managed.

.NET Micro Framework Whitepaper

A couple of people have started talking about the .NET Micro Framework which is, as the name suggests, an extremely cut down version of the .NET Framework.  Unlike the .NET Compact Framework which was designed to run on top of an existing OS, the .NET Micro Framework can operate without an underlying OS.  As such it has provisions for a HAL that is specific to the device onto which it is to be run.  The best news is that this is all going to have rich developer support through Visual Studio.  Check out the new whitepaper that provides early information about this framework.

SP1 Beta for the .NET Compact Framework V2.0

I guess this is pretty old news already, but since this is an area of interest to me I thought that I should at least add to the clutter on the Internet by blogging the fact that a Beta for SP1 for the .NET Compact Framework has been announced and that more information on the added functionality and bug fixes is available on the team's blog