Tips for the Week in .NET

WeekIn.NET.20151208.md

Please comment below...

• http://blogs.msdn.com/b/eva/archive/2015/12/11/2015-12-1.aspx by Euni Kim

• http://engineering.gopangea.com/2015/12/10/why-dot-net.html

• http://blogs.msdn.com/b/visualstudio/archive/2015/12/10/the-net-journey-recapping-the-last-year.aspx

• http://mattwarren.org/2015/12/08/open-source-net-1-year-later/

• http://blog.davidebbo.com/2015/12/calling-arm-using-plain-rest.html

• http://ericlippert.com/2015/12/03/the-dedoublifier-part-two/ and http://ericlippert.com/2015/12/07/the-dedoublifier-part-three/

ASP.NET

• http://www.aspnetweekly.com/
• http://dotnetliberty.com/index.php/2015/12/07/asp-net-5-web-api-faking-it-while-making-it/
• http://www.dotnetcurry.com/aspnet-mvc/1215/building-aspnet-mvc-6-entity-framework-7-app-using-aspnet-5

F#

• http://trelford.com/blog/post/Disinherited.aspx and http://trelford.com/blog/post/MSDNify.aspx
• https://medium.com/@jamiedixon/progressive-f-tutorials-london-2015-795d76c027da#.67vl10l5w

Packages

• https://www.nuget.org/packages/MBrace.Core

Hello @bleroy,

Packages I want more people to know:

BenchmarkDotNet

Performance optimization is hard but micro-optimizations are harder. So we need a reliable benchmarks to see the difference, not for 1 000 000 times loop. Especially when we target different platforms and architectures, and jitters.

BenchmarkDotNet is initially developed by @AndreyAkinshin, then with help of @mattwarren.

The project allows you to focus on What to benchmark, instead of How. And provides results in a way you can put on presentation slides for your management (who is on the tech side though ;).

DryIoc

disclosure: I am an Owner.

Top performer in IoC for .NET at the moment.

The version 2.0 was in a preview for almost a year and released in November. V2.0 adds to performance the full spec of features that you'd expect from modern IoC.

It was initially designed to be on par with Autofac, StructureMap, Unity. But provide faster resolutions (even for the first time) and faster bootstrap/registrations as well. So you do not hesitate to use it.

Plus:

• The support for MEF Attributed Model was here from the start.
• DryIoc was designed to be unobtrusive for easy integration with existing solutions and libraries.
• The last but not least the goal was to minimize noise associated with container usage.

An elaborated example (full code):

    [Test]
    public void Test()
    {
        var container = new Container().WithMefAttributedModel();
        container.RegisterExports(typeof(Foo<,>), typeof(FooDecorator), typeof(X), typeof(Y));
        var foo = container.Resolve<IFoo<X, Y>>();
        StringAssert.Contains("decorated", foo.Message);
    }

    // The SUT
    public interface IFoo<A, B>
    {
        string Message { get; set; }
    }

    [Export]
    public class X { }

    [Export]
    public class Y { }

    [Export(typeof(IFoo<,>))]
    class Foo<A, B> : IFoo<A, B>
    {
        public Foo(A a, B b) {}

        public string Message { get; set; }
    }

    // AsFactory says that class has factory method(s) to Export 
    [Export, AsFactory]
    public class FooDecorator
    {
        // Decorator or kind of instantiation middleware implemented as normal method
        // Method parameters are injected by container. Lazy, Func, etc are supported
        // AsDecorator instructs to use result of this method for IFoo<> service, decoratee foo is injected by container. 
        [Export, AsDecorator]
        public IFoo<A, B> AddMessage<A, B>(IFoo<A, B> foo, Func<A> a, Lazy<B> b)
        {
            foo.Message = $"decorated with {a()} and {b.Value}";
            return foo;
        }
    }

Note: That the same setup may be done without attributes or MEF model. It illustrates how easy it is to work with generics, decorators, wrappers.