Featured Post

Visual Studio 2010 cosmetics

Thanks to the new WPF based GUI of Visual Studio 2010 there are some noticeable cosmetic improvements. Most of you might already know this, but the text editor supports arbitrary zooming now. Simply hold down your CTRL key and use the mouse wheel to zoom in and out. Thanks to the much improved...

Read More

Why a “ForEach” extension method for LINQ is a bad idea

Posted by BernhardGlueck | Posted in .net development, c# | Posted on 06-02-2011

0

I often wondered why LINQ to Objects does not contain a “ForEach” extension method like the generic List<T> class does.
After being hit by stupid bugs of my own twice in the last week, I think I have the answer why L2O was designed in that way
and why List<T> contains one.

So consider this:
What is the fundamental difference between all other L2O operators and ForEach ?

All normal LINQ operators model a computation of a sequence, either standalone or as a combination of multiple computations.  
This computation is stateless,the sequence is only materialized when we actually evaluate the tree of computations we
have combined so far.
This means if the LINQ query creates objects along the way, we will get different ones for each evaluation of the query.

So what is the difference with ForEach then ? Simply ForEach implies evaluation of the computation!
This falls outside of the normal LINQ model, because now we are not dealing with computations anymore but with the results of such a computation.
We effectively now have a mixture of both stateless and stateful ( by allowing us to change the invidual data contained in sequence we’re computing ) 
operations, and it is much to easy to forget that in our ForEach operator we have to deal with the implications of that, e.g that two different ForEach calls
can receive different data, and we must not impose side effects on that data, because in the next evaluation those side effects will be gone again.

That’s why it’s not ok to have a ForEach Linq operator, but it’s perfectly alright for List<T> because List<T> is not a stateless sequence in the LINQ sense, but an already
evaluated one, that will not return different data between iterations !

So delete those nasty ForEach extensions methods again, because believe me tracing this kind of bug over a few hundred methods is not a fun thing to do…

  • Share/Bookmark

LightMoon

Posted by BernhardGlueck | Posted in .net development, c# | Posted on 10-01-2011

0

The last year I tried to develop Web Push Technology for .NET ( Comet Style Http Push + Web Sockets for more modern browsers ). While the actual communication technology was relatively easy to implement, I ended up in a world where my precious web application had to suddenly keep state around about virtual connections or queues in order to deliver the correct data to the correct clients. This ended in a world of hurt because there was no ready made solution for this kind of problem. While certainly one could develop such a specific solution, I started to think further.

In the modern world of application development be it in the web space or in backend development, we are taught to make our applications stateless.
However in reality most of them are stateful and we only push the state as far back as possible ( usually the Database ) and use mostly stateless parts elsewhere.
This essentially is a trick to get parts of our infrastructure to scale easier ( or cheaper ) while the costs for databases skyrocket ( albeit only if you hit a certain amount of data ) in terms of hardware/software and personnel .
It also makes the lives of developers a lot harder since we constantly have to use tricks and workarounds to hide the fact that in fact we have state that we would like to access. Be it clever data access strategies, http cookies or Session State wrappers.

Wouldn’t it be easier to just not have to think about it, and follow one simple programming model that comes natural to the average OOP developer ( POCOs ) ?

Enter LightMoon, an application middleware I have started developing that essentially provides these features, and while doing so does not sacrifice scalability.
This technology could be used in a lot of domains, not the least the development of MMO style games ( where my inspiration originally came from ).

I plan to release a technology preview sometime in May 2011 ( I know still some time off ) and later on make it a commercial product that is dual licensed under the GPL and a commercial one.

Following is a short list of features that will be supported in the initial CTP:

  • Simple programming model of disconnected actors that communicate via message passing similar to what Erlang/Scala provide
  • Lightweight views on actors ( auto generated from the implementation code, initially for JavaScript via HTTP communication and C# via TCP/IP )
  • Support for a huge number of simultaneously connected clients.
  • Transparent persistence
  • Transparent concurrency
  • Easy horizontal scalability

The ideas i follow are not new, there is just no good implementation of them for .NET so far with modern technology backends.

A similar project is the Akka Actor Kernel for Scala

  • Share/Bookmark

IOC ModelBinder

Posted by BernhardGlueck | Posted in .net development, IOC, autofac, c# | Posted on 21-05-2010

Tags: , ,

0

I had an idea a couple of days ago, that I decided to play around with, and maybe collect opinions on. The ASP.NET MVC ModelBinder infrastructure is quite exhaustive, and allows you to perform almost any action when a something the developer wants to get data from the request into the domain/data/business model.

However recently I found myself in a situation where a controller got quite sophisticated and required a lot of dependencies from our Ioc Container of choice ( Autofac ). Since all of those were mandatory dependencies for execution for one or the other action method, our constructor arguments got a little bit out of hand ( I just don’t like constructors with more than, let’s say 4 arguments ). So I decided to build a model binder that injects dependencies into action method calls.

Without further ado, here is the interesting part of the code:

    public class IocBindAttribute : CustomModelBinderAttribute
    {
        public override IModelBinder GetBinder()
        {
            return new IocModelBinder();
        }
    }

    public class IocModelBinder : IModelBinder
    {
        public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
        {
            try
            {
                return GetContainer().Resolve(bindingContext.ModelName, bindingContext.ModelType);
            }
            catch (ComponentNotRegisteredException)
            {
                return GetContainer().Resolve(bindingContext.ModelType);
            }
        }

        private IContainer GetContainer()
        {
            return (HttpContext.Current.ApplicationInstance as IContainerProviderAccessor).ContainerProvider.ApplicationContainer;
        }
    }

    public class EmailController : Controller
    {
        public ActionResult Index()
        {
            return View();
        }

        public ActionResult Send([IocBind]IEmailService emailService,
                                 string from, string to, string subject, string text)
        {
            emailService.Send(from, to, subject, text);

            return RedirectToAction("Index");
        }
    }

As well as the sample project.

Basically you use your container as you like and register the given model binder either globally or via the provided ModelBinder attribute on a more granular level. Note that this code is not meant to be a production implementation, it’s just here to show the idea. The same basic idea can be implemented for virtually any container, or using the common service locator if you choose so.

However I am a bit torn with this idea in the context of architectural design:

Arguments for using it:

  • Reduces a lot of boilerplate code for dependency handling like constructor arguments and storage.
  • If you see each action as a distinct piece of code that is grouped by a container, it better reflects the correspondence between your actions and the dependencies they need, you can see at a glance what dependencies are required by each action, which might not be so obvious when you follow the traditional approach.
  • In the same vein it eases both refactoring as well as unit testing, because you can now treat each action more easily in isolation, move it around to different controllers, or set it up for a test case.

Arguments against using it:

  • If you have a controller whose action methods require such disparate dependencies, then you might have a deeper problem, either your controller is doing to much in terms of the single responsibility principle, or your dependencies are too granular and it might be a good idea to provide some bridge dependency for that case.
  • It mixes the concerns of data flow and the business layer of your application.

So please fire away with the comments to tell me what you think, or what I have done wrong with this.

  • Share/Bookmark

Simple factory for open dynamic delegates

Posted by BernhardGlueck | Posted in .net development, VisualStudio, c# | Posted on 18-04-2010

0

During the course of my development adventures I came to a point where I needed to call instance methods dynamically based only on information that can be obtained through reflection. It is well known that MethodInfo.Invoke is quite slow, and so I decided to create and cache delegates based on the given MethodInfo on first use, and use those to invoke the method.

However it would be prohibitive to generate a delegate for every instance of an object, rather it would be nice to create a delegate per Method prototype and decide the instance to call it on during the final invocation.

A little known feature that allows us to achieve this, is the ability of the CLR to create so called “open” delegates. In the CLR a call to an instance method is quite similar to the call of a static one, except that the first parameter on the stack is the instance on which to call the method. Open Delegates allow us to create delegates that for an instance method take an additional first parameter for the instance to call the method on, thus neatly wrapping the above concept.

The feature is not common knowledge, basically because neither C# or VB offer the syntax to create such open delegates, one has to always use Delegate.CreateDelegate to create it dynamically.

The overload to use is mainly Delegate.CreateDelegate( Type delegateType,MethodInfo method,bool throwOnBindFailure ).
This is quite straightforward to use, a little complication stems from the fact that we need a delegate type to create the delegate instance. I decided to leverage the predefined Action<> and Func<> types for that, and bind the generic arguments to the parameter types of the method.

Here is my simple utility class that wraps the presented ideas.

Note that it does not support open generic methods and that it is limited to methods that have up to 16 parameters ( not that you should have methods that have more ).
To use just call the CreateOpenDelegate method with the MethodInfo that represents your instance method.
The returned delegate can then either be casted to an appropriate Action<> or Func<> or called via DynamicInvoke.
Regardless of the call method used, one has to pass in the instance to call the method on as the first parameter.

Here is the source code:

    public static class DelegateFactory
    {
        private static readonly Type[] actionTypes = new [] {
                                                                typeof(Action),
                                                                typeof(Action<>),
                                                                typeof(Action<,>),
                                                                typeof(Action<,,>),
                                                                typeof(Action<,,,>),
                                                                typeof(Action<,,,,>),
                                                                typeof(Action<,,,,,>),
                                                                typeof(Action<,,,,,,>),
                                                                typeof(Action<,,,,,,,>),
                                                                typeof(Action<,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,,,,,>),
                                                                typeof(Action<,,,,,,,,,,,,,,,>),
                                                            };

        private static readonly Type[] functionTypes = new [] {
                                                                typeof(Func<>),
                                                                typeof(Func<,>),
                                                                typeof(Func<,,>),
                                                                typeof(Func<,,,>),
                                                                typeof(Func<,,,,>),
                                                                typeof(Func<,,,,,>),
                                                                typeof(Func<,,,,,,>),
                                                                typeof(Func<,,,,,,,>),
                                                                typeof(Func<,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,,,,,>),
                                                                typeof(Func<,,,,,,,,,,,,,,,,>),
                                                            };

        public static Delegate CreateOpenDelegate( MethodInfo method )
        {
            Contract.Requires(method != null);

            var closedType = GetClosedDelegateType(method);

            return closedType != null ?
                     Delegate.CreateDelegate(closedType, method, true)
                     : null;
        }

        private static Type GetClosedDelegateType( MethodInfo method )
        {
            Contract.Requires(method != null);

            var openType = GetOpenDelegateType(method);

            if (openType != null)
            {
                var parameterTypes =
                    new[] {method.DeclaringType}.Union(method.GetParameters().Select(p => p.ParameterType));

                if (method.ReturnType != typeof (void))
                {
                    parameterTypes = parameterTypes.Union(new[] {method.ReturnType});
                }

                return openType.MakeGenericType(parameterTypes.ToArray());
            }

            return null;
        }

        private static Type GetOpenDelegateType( MethodInfo method )
        {
            Contract.Requires( method != null );

            var parameterCount = method.GetParameters().Length + 1;

            if (parameterCount < functionTypes.Length && parameterCount < actionTypes.Length)
            {

                return method.ReturnType != typeof (void)
                           ? functionTypes[parameterCount]
                           : actionTypes[parameterCount];
            }

            return null;
        }
    }
  • Share/Bookmark

Enhanced Continuations for .NET

Posted by BernhardGlueck | Posted in .net development, c# | Posted on 11-04-2010

0

Continuations are the base for several useful idioms in programming like coroutines, cooperative multithreading and so on.

In the vanilla .NET framework C# supports a way to emulate them using the yield keyword that was originally intended for custom enumerations, but was soon found out to be much more powerful.

Using yield one can define methods that can be interrupted at well defined points and continued when desired, with only minor syntax inconveniences.

Please note that Mono ( 2.6 or above ) include an even better Continuations implementation that works in conjunction wit the CLR itself, but of course this only works on Mono, and not on the vanilla .NET framework. 

In an project I am doing in my spare time I needed continuations that can also be migrated to different machines ( similar to what the SecondLife servers do ) in order to provide enhanced scalability and load balancing, and it needed to run on the normal Microsoft CLR implementation.

The yield statement in C# generates an implicit state machine in a custom IEnumerator implementation, that executes the parts of your code based on the current state.

These enumerators contain a number of state member fields:

xxx_state is an integer that stores the state of the method,
xxx_current stores the current value the enumerator returns and
xxx_this contains the instance on which the method itself was called.

Additional members contain hoisted out variables of the method code itself ( e.g the control variables for loops and such )
xxx is a compiled generated prefix that seems to be generated by the order in which the compiler generates the members.

When a method that uses yield is called directly an instance of the compiler generated enumerator is created, the instance that was used for the call is stored in it and it is returned to the caller. The actual method code is only executed when MoveNext is called on the enumerator. This means that a call to the method itself has no side effects and can be done an arbitrary number of times without doing any harm ( except some memory allocations of course ).

So in order to migrate the execution state of such a method we need to execute any number of steps from it, ( using MoveNext of the enumerator returned ), persist the state of the enumerator, load it again on some other machine, call the method again, apply the saved state to the enumerator, and call MoveNext again to continue execution.

To achieve this I created a surrogate class for an enumerator that extracts and state members out of an instance and that is serializable, and that allows to apply that state again to a different enumerator of the same type.

I do not serialize the xxx_this member since it gets assigned on the initial method call anyway, and the xxx_current member is also not needed since the current value is only interesting to me after a call to MoveNext ( in my case I always return an implementation of my IWaitCondition interface )

Note that this all works only with the style that the C# compiler implements yield based enumerators, and will probably break in VB or other .NET languages. It is also required that any control variables that get hoisted out of the method code are serializable as well but in most situations that is the case anyway, and otherwise can be worked around easily.

In order to avoid the reflection overhead I create state member accessors using DynamicMethod that get used on any subsequent usage.

Example code

  • Share/Bookmark

Visual Studio 2010 Beta2 Impressions

Posted by BernhardGlueck | Posted in .net development, VisualStudio, c# | Posted on 26-10-2009

Tags: , , ,

0

Beta 2 of Visual Studio 2010 has arrived and is available for download for just about anyone to grab.

I’ve played around with this release for a week now ( Msdn release was a few days prior to public availability )
and so far my feelings are best described in romantic terms: Love at first sight.

There are so many great features/improvements that I just don’t know where to begin, but I’ll try anyway.

For the first time since Visual Studio 6 back in the 90s, online help is fast again. Microsoft rewrote the complete help
system and based it around a small local Web server that serves Javascript enriched help content.
Hovering on some identifier, pressing F1 and waiting for the new context sensitve help to pop up takes about 0.5 seconds
on my local machine.

TFS Basic is great. I stayed clear of TeamFoundation server for the last releases since my initial evaluation turned out that it did
not offer much over other tools, but required insane ammounts of hardware and installation/administration effort that just were
not easily recouped by it’s functionality.

TFS Basic installs easy, fast ( 20 minutes for me without any error whatsoever ) and runs even on client OS editions if you’re into that.

UML Modelling support has finally arrived, of course it’s the first release, and code generation support seems not to be on the agenda, but
for some fast and simple diagramming it’s certainly enough.

The C++ compiler supports a few things from the upcoming revised standard, like the auto keyword, lambda functions and nullptr.
TR1 support has also matured and so we can write even better standard compliant code right now.
Performance of C++ intellisense seems also much better, especially with larger codebases.
Also C++ finally uses Msbuild for it’s build system as well as project files. So codebases that mix C++ with C# are now much easier to handle
in build environments.

For C# we have of course the new dynamic dispatch features, as well as optional and named parameters, and better co/contravariance support for generics.
I still don’t like dynamic dispatch support, simply because I think it will be used for all the wrong reasons, and because it throws out a lot of the investment
in static source code analysis technology, and proofing program correctness.

On the runtime side of things, of course we have additions to WCF/WPF a completly rewritten Workflow Foundation, and many other small things like
a few conveniance methods ( string.IsNullOrWhiteSpace ).

The Task Parallel library is a godsend, but I am still in fear of it’s usage patterns. I see a lot of developers who are not experienced in multithreading
just use things like Parallel.ForEach or PLINQ because it’s so damn easy thereby ignoring the concurrency issues, producing code that will just fail
at unpredictable times.
At least we have some by default threadsafe collections now, but the performance implications of those must not be overlooked, collections are rarely the
right place for some last effort “catch all” synchronization.

Things like native support for Memory Mapped files, the inclusion of Code Contracts which were previously available as an addon, as well as conveniance
data structures like tuples or sets round off the framework itself.

The client GC can now do parallel garbage collections under certain circumstances ( during full collections a certain number
of allocations can be still be done while the collection is running ).

The server GC does not support this apparently because of lack of development time, which is really not nice, since especially there it would have resolved certain issues in long running applications
that have bitten me in the past.

Last but not least ADO.NET Entity Framework is in it’s second release, supports forward engineering finally, and generally seems much more mature now, time to take it for a spin in the next few days.

All in all a great release, and the nice WPF UI of Visual Studio just make working that little extra spicy, so in conclusion: I really like it !

  • Share/Bookmark

Visual Studio Extensions

Posted by BernhardGlueck | Posted in .net development, VisualStudio, c# | Posted on 20-06-2009

Tags: , ,

0

As a friend asked me today, what kind of tools I use for my day to day .NET development work in addition
to Visual Studio, I thought I’ll whip up a list, and include some not so common tools as well.

So here it is:

Resharper: Not much to say, if you still write C# code without it, you can’t be helped.

Regionerate: Code layout/reformatting on steroids. A time saver if you have to reformat a lot of inherited code.

StyleCop: Code style analysis, based on the .NET framework design guidelines by Microsoft. There is also a plugin for Resharper available that executes the analysis in the background while you work. ( http://www.codeplex.com/StyleCopForReSharper )

Sandcastle for Visual Studio: Allows you to create documentation projects in a solution and automatically build
Msdn style documentation based on xml documentation comments, and manually edited content.

FxCop: Static code analysis. This is of course included in Visual Studio, but I am often surprised how little people make use of it, so I thought I’d mention it anyway.

RockScoller: Addin that provides you with an overview of the source file you’re working on. Great for large files.

Pex: Automated white box testing for your code. Allows you to generate unit test code by executing your code and trying to find the weak spots.

Chess: Automated testing of multithreaded code, to detect interleave patterns that cause deadlocks/livelocks or race conditions in your code. This is a godsend, I can’t reiterate enough how great this tool is.

InteliShade: HLSL syntax highlighting and intellisense support. For the graphics developers among us.

Code Contracts: Code contract support, which allows you to add precondition, postcondition and invariant checking code, enforce it at runtime, and find weak spots through static analysis.

Pinvoke.Net: Easy lookup of P/Invoke signatures for those pesky Win32 API imports ( and a lot of others ).

PostBuild.Net: Code obfuscation, compression and virtualization. Allows you to deploy your .NET client applications to systems without them even needing .NET installed.

PostSharp Great tool for post build code modification with included AOP support and msbuild integration. Use it for post processing your assemblies, injecting code, or modifying it.

Visual WebGui: Build AJAX or Silverlight based RIA applications with a development model similar to Windows Forms.

Script#: Write code in C# with a special class library, and have it automatically translated to client side JavaScript code at build time. Great if you don’t like the JavaScript syntax or object model.

VisualSVN: Work with Subversion from Visual Studio, based on the familiar TortoiseSVN base platform. Beats any other integration hands down.

Of course I left out some others, so if you have any ideas of tools to add, leave a comment.

  • Share/Bookmark

Visual Studio 2010 cosmetics

Posted by BernhardGlueck | Posted in .net development, c# | Posted on 13-06-2009

Tags:

0

Thanks to the new WPF based GUI of Visual Studio 2010 there are some noticeable cosmetic improvements.
Most of you might already know this, but the text editor supports arbitrary zooming now. Simply hold down
your CTRL key and use the mouse wheel to zoom in and out. Thanks to the much improved text rendering
support in WPF ( ClearType and sophisticated hardware anti aliasing using shaders ) the results are quite gorgeous in my opinion and make for great presentations on large displays or projector screens:

VisualStudioTextRendering

The theme i am using is Vibrant Ink by the way, a quite natural port of the same theme from TextMate.

  • Share/Bookmark

My DailyWTF

Posted by BernhardGlueck | Posted in .net development, c# | Posted on 08-06-2009

Tags: ,

0

Today during work I made a mistake that I want to share with you because I think this is a corner case of LINQ and maybe not immediately clear to everyone. At least it wasn’t clear to me.
The code:

var rootElement = XElement.Load("SomeFile.xml");
var result = from x in rootElement.Elements("Child") where x.Attribute("Value").Value == "0" select x.Elements("GrandChild");

I thought that result would be a normal IEnumerable of XElement where the elements are all grandchildren in all children of the root element combined.
But guess again, the result will be an IEnumerable of IEnumerables, because the select statement selects the return value and does not iterate over it implicitly.

  • Share/Bookmark