Category: .NET

Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 CTP Released

Posted on by David Arno

AMD quad core chipLast week, Microsoft released a new Community Technology Preview (CTP) of the .NET Task Parallel Library. The new release has a brand new scheduler that repleaces the pretty crude protottype scheduler found in the December 2007 CTP. According to the help file that accompanies the release, the new scheduler “… uses cooperative scheduling and work-stealing to achieve fast, efficient scheduling and maximum CPU utilization”.

In addition to improving the performance of the Task Parallel Library (TPL) and PLINQ, a bunch of new classes that compliment the TPL, and that can be used for general multithreading work, are included too. These include things such as a spinlock class, that includes builtin support for the sleep/ retry loop when the lock isn’t available; and the ConcurrentQueue and ConcurrentStack classes. These latter ones provide builtin support for multiple threads reading and writing to the collections simulataneously, and remove the need to write semaphore-based wrappers around the previous Queue and Stack classes.

.NET is NOT to blame!

Posted on by David Arno

World Wide TelescopeI have been following the World Wide Telescope project with interest ever since Robert Scoble made a bit of an arse of himself over the subject. Since I was really impressed with the ease of install and the beauty of the product, I gushed in near fanboy-style about it when it went into beta release (I didn’t woop; so it wasn’t real fanboy stuff ;)). It was thus a bit of a shock to see that Mike Dillamore was casting the install in a bad light.

Mike was my boss at my last place of work. I have a great deal of respect for him as he is the man that got me into TDD, Scrum, podcasts and of course blogging. An area where he and eye do not see eye to eye though is over .NET. I am a big fan; he has, for reasons I’ve never properly understood, a keen dislike of it.

The instructions for installing the World Wide Telescope are long and complex (and remind me of installing anything on Linux for example), but people seem to be forgetting that this is just a beta release of the product and thus it will be rough and ready. As for the comment that .NET is to blame, what nonsense! The real “blame”, if one must call it that, lies with Microsoft’s business model of supporting what ought to be long-dead products. They could take the Apple route and simply refuse to install the software on any machine that isn’t Vista SP1, but since they are a multi-billion dollar operation that dwarfs Apple, perhaps their business model makes sense. Of course the blame also lies at the feet of the inherent security weaknesses in Microsoft’s desktop operation systems, but that’s a whole different topic.

Far from being a yolk about Micrososft’s neck. .NET is their money-spinning future. ASP.NET single-handedly saved their dying web server business for example. The awesomely powerful shell – PowerShell – that is built into the Server 2008 operating system is .NET based and let’s not forget that SIlverlight is .NET based too. Ten years ago, Borland offered a superb IDE, which people sadly turned their backs on by adopting the awful Visual Studio 6 instead. Those days have long gone though. Now, when one can get Eclipse or the Visual Studio 2008 Express editions for free, the IDEs from Borland (or Code Gear as they now are) make no business sense.

Mono team to Microsoft: build Moonlight desklet support into Silverlight

Posted on by David Arno

As you may be aware, the Mono team and Novell are creating a version of Silverlight for Linux called Moonlight. As part of that process, the Mono team added a “hack” that enables Silverlight apps to run on a Linux desktop, calling them Moonlight desklets. Miguel de Icaza, who heads up the Mono project blogged about them last year. It looks likely though that unless Microsoft adds its backing to desklets, they will remain a Linux-only hack, rather than a major Moonlight feature.

A few days ago, Miguel posted an update on the progress of developing desklets, and added a call to Microsoft to support these desklets in Silverlight. Apparently the Moonlight team do not plan on porting desklets across to the Mac and Windows, as it is a non-trivial task. I suspect that Microsoft will respond in time (though their focus at the moment must be on getting Silverlight 2 ready for an August release.) If they do not respond, then Flash obviously maintains one big advantage over Silverlight, namely AIR.

Ook# makes a monkey out of Obfuscated C

Posted on by David Arno

I was listening to the latest .NET Rocks! podcast this morning. The guest was Ted Neward, and he was discussing modern programming languages. He made the comment that there was even a .NET language written for the Librarian and other orangutans called Ook#. This sent me on a search of Google and a surreal voyage of discovery into languages that make the Obfuscated C Contest seem like a stroll in the park.

The C language is infamous for its support of really nasty unreadable code and the Obfuscated C Contest is a mostly annual competition to see who can come up with the “best” examples. One such is a less than conventional “Hello World” solution:

Some years back though, the language Brainfuck was created by Urban Müller that put such efforts to shame. The Brainfuck “Hello World” solution is:

The line breaks are just for neatness on this blog BTW. They are entirely optional within the language and have no significance. The entire language has just eight operators and cannot be expanded:

These eight commands were then translated into Orangutan to give the following eight commands that make up the Ook! programming language:

A “typical” example is a program that prints “Ook!”, and it looks like this:

Both Brainfuck and Ook! have been converted to .NET languages (Brainfuck.NET and Ook# respectively) by Lawrence Pit. You can download the source code for the compilers, along with some examples, from here.

PASH – Powershell for “the rest of us”

Posted on by David Arno

If you have never used Windows PowerShell, you are missing out on a hugely powerful command-line tool. Not only does it show up the dos window/cmd prompt for the joke it has been for decades, it gives even the most powerful Unix shells a run for their money. (I’ve spent around ten years of my life using just about every last features of, what is in my view, is the most powerful shell out there – ksh. So I like to think I know what I’m talking about here). If you are using Windows and use a cmd window on occasions, then you should be using PowerShell. Grab yourself a copy of the free PowerGUI, join the community at powergui.org and you’ll probably never touch cmd again.

Of course there is a world beyond Windows, and if you use a MAc, Solaris, Linux etc, you are likely thinking “so what?” Well a new Mono-based developement, Pash, is set to change all that. The developers of Pash aim to recreate PowerShell on those other operating systems. If you are a developer, then you may be interested to know that the project is still pre-alpha too, so there is plenty of opportunity to show off your skills by helping out.

The .NET Framework: bloatware or power to the developer?

Posted on by David Arno

.net logoBrad Abrams has published details of the number of classes, members, namespaces and assemblies in the various .NET frameworks. The latest offering, .NET 3.5, has 98 assemblies, containing 309 namespaces. Those namespaces in turn contain 11,417 classes, which define 109657 members. He doesn’t say whether this is total, or whether these are just the public classes and members. Hopefully it is the former.

Brad claims that “in each release [Microsoft] are adding new functionality that make it easier to build .NET applications”. Is this true though? One could argue that as the number of classes goes up, so it becomes more difficult to find the class you need to solve a particular problem. Take XML as a case in point. There are 48 classes in the XML namespace, including confusing sets that appear to have the same, or very similar functionality. For example, XmlWriter, XmlDictionaryWriter and XmlTextWriter.

Perhaps rather than speculating on how much the .NET 4 framework might grow by, Brad and his colleagues could try making heavy use of the System.Obsolete class to reduce the numbers. Now that really would make it easier to build .NET applications.

Assembly stats for different versions of the .NET framework

Namespace stats for different versions of the .NET framework

Types stats for different versions of the .NET framework

Members stats for different versions of the .NET framework

.NET Source Code Released to VS2008 Developers

Posted on by David Arno

visualstudio.gifBack in October, I wrote a blog post about Microsoft’s plans to make the source code of .NET available under a “look; don’t touch” license to VS2008 developers. At the time, some were predicting it was the end of open source, and some were predicting it was the start of Microsoft going open source with .NET. Whether either extreme will come to pass is unknown (though also highly unlikely in my view), but time may well begin to tell. As of this week, Microsoft have begun the roll-out of that source. More details (including how to access the sources) are available over on Scott Guthrie’s blog.

C# and Friend Assemblies Made Easy

Posted on by David Arno

friendassembly_small.pngIf you are familiar with C++, you’ll know about “friend classes” within that language. If you are not familiar with them, they are a neat way of exposing otherwise private methods to trusted classes. Class A has a bunch of private members, that are obviously hidden to other classes, but there is a problem with this model. Class B is a unit test class that tests class A. Because it is doing unit tests, it needs to delve deep inside class A to check what is going on. By making class B a friend of class A, the former is then granted access to the latter’s inner workings.

So what does this have to do with C#? Well C# partially fixed this with the “internal” keyword. Internal members of a class are visible to other classes within the same assembly, but are effectively private as far as classes outside the assembly are concerned. Internal members are very different from protected ones by the way. In the latter case, they are only visible to subclasses (whether in the same assembly or not). However, largely due to a limitation with Visual Studio, internal members used not to be the full answer to the needs of unit testing. The C# compiler supports compiling multiple projects into one assembly, but Visual Studio has a strict one to one project/ assembly mapping. So unit test classes used to have to reside within the same project as the product code (which wasn’t practical if the project’s assembly was a executable, rather than a dll.) The other alternative was to expose all the members that the unit test classes needed to access by making them public.

I talk in the past tense in the previous paragraph as this problem was fixed with the release of C# 2.0. This introduced the idea of Friend Assemblies. To explain, let’s go back to our class A and B. Class A resides in assembly A.dll. Class B resides in assembly B.dll. Normally class B would have no access to the internals of class A. Add the “InternalsVisibleTo” attribute to class A though, specifying B.dll as the trusted assembly and now class B can access those internals. Further, unlike with C++ and friend classes, private members in class A remain private; only internals are exposed via this method.

If both A.dll and B.dll are unsigned, the extra code is just:

which is a pretty neat solution.

Things get really messy though the moment signed assemblies are used. The reason is that one must put the public key (not the nice short token, the full-blown humongous key) in the attribute. So it becomes something like:

(I’ve wrapped the public key across many lines for clarity. In reality, it must be on one line)

The whole horrible nastiness of the matter doesn’t stop there though. To get that public key, one must find the sn.exe tool, plough through its dozens of obscure options, and then run the right one against the required assembly (or run a sequence of two even more obscure commands against the original key file). Then one can cut and paste the output of the command into the attribute in Visual Studio. This is what we in Britain politely term a “complete faff”.

Having banged my head against the wall performing this operation recently, I decided that a simply little utility was required to do all the work. So I wrote an app called FriendAssembly, which I’m sharing here.

Continue reading “C# and Friend Assemblies Made Easy” →

Parallel.For quirk can leave your code running sequentially

Posted on by David Arno

I have been experimenting with the Task Parallel Library December CTP in preparation for a talk at work, and in the process I came across a really weird feature that turns out to have a completely mundane solution. As it will likely catch others out too, I’ve decided to write a blog entry about it.

If you try taking the following C# code:

and convert it to use the new parallel for loop:

and run it on a computer with four cores, you might expect an output such as:

You will however be very disappointed with the result if you do, as the whole loop actually runs on one thread in a sequential fashion. It turns out that the reason for this is simple practicalities of getting this stuff working at a basic level for the CTP. As I discovered on the MSDN parallel forum, the reason is that the Parallel.For method breaks the loop up into groups of eight iterations and assigns each group of eight to the next available thread. So if your loop is of eight or less iterations, then it will run sequentially. You can test this by simply adjusting the for loop to 0 .. 15 say and it will use two threads if you have two cores etc.

Microsoft scrap plans for Silverlight 1.1 (and call it Silverlight 2.0 instead)

Posted on by David Arno

“Big Blue”, the SIlverlight logoIt appears that it has finally dawned on Microsoft that adding major new features to Silverlight (.NET support, “proper” controls that support layout management , sockets, data-binding, templates and networking and support for cross-domain networking) and then just issuing it as a minor release (1.1) wasn’t such a clever idea after all. So look out for a beta of Silverlight 2.0 early in 2008.

Read more about it on Somasegar’s blog