Development with a Dot

Note: this is an update of an old post that is no longer available from my old blog . Introduction Dependency Resolution (RS), Dependency Injection/Dependency Inversion (DI) and Inversion of Control (IoC) are hot topics for a long time. Basically all frameworks are aware of it, or offer some mechanisms to help implement it. It all started a long time ago, however, and things are slightly confusing at the moment – but will get better! In this post, I won’t go through all of the details of all dependency resolution libraries in existence, instead I will only focus on Microsoft libraries. Also, I will only talk about generic dependency resolution, leaving out more specialized usages, such as WCF , WF and SharePoint , which also use similar concepts. Origins It all started with the venerable IServiceProvider interface. It basically provided a single method, GetService , that gave answer to “get me an implementation for this type”. That was it, the single parameter was a Type , and the r...

Update: see my other post on distributed Isolator and on refereces scanning . Introduction Code isolation, also known as sandboxes, are an important topic in any enterprise-level programming language: the means the ability to run code in a secure way that does not affect the main program. This used to be relatively easy to achieve with the .NET Framework, but it is no longer so, since .NET Core was introduced. I will talk a bit about it and how we can implement something similar. Code Isolation in .NET Custom app domains are gone from .NET since .NET Core. Officially they were removed because they were heavy and hard to maintain. There is still the AppDomain  class and we always have a current app domain, which can be accessed from AppDomain.CurrentDomain , but the AppDomain.CreateDomain method now returns an exception on all platforms. App domains were great, from a programatic point of view, because they allowed us to create new ones with custom permissions, which could then b...

Introduction This post talks about a few options for restricting access to a given action method - or to all of them - on an ASP.NET Core MVC controller. It won’t be a general article about security in ASP.NET Core, just this aspect of it. Prerequisites We must always add authentication  (who we are) and authorisation (what can we do) support to the ASP.NET Core pipeline. Authorisation requires authentication, but authentication can exist on its own, as long as some authentication scheme is provided: builder.Services.AddAuthentication() .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme); builder.Services.AddAuthorization(); //can take options as we will see later on Using Filters ASP.NET Core filters are well known and popular, they are probably the easiest way to restrict access to an endpoint. Filters can be applied: Through an attribute, to an action method or a controller Globally for all controllers and actions Custom Filters IAuthorizationFilter  or IAsyn...

Introduction Dispite recent announcements  by Jimmy Bogard , I'm still using AutoMapper . Maybe it's because I'm used to it and I think it has great features - like mapping LINQ expressions - anyway, I'm sticking to it, for the time being! A couple things, though, I feel are missing: The ability to automatically map types Dependency injection (DI) of services into  Profile classes So I set out to make these both work! Fortunately,  AutoMapper  provides many extension points that we can hook to in order to do what we want. So, I'm going to talk a bit about these topics. In a nutshell, the problem I am to solve is: automatically map types from one assembly into the types in another one, of course, using only conventions. My approach was, use a custom mapper profile ( Profile ) to go through all types in the source assembly, find out the corresponding types in the target assembly, and add them to the maps. AutoMapper and Dependency Injection First things first.  ...

Introduction This post is an update to an old one on my  old blog  and it was inspired by my latest posts on C# versus Java . You may not have realized that some of the patterns that you’ve been using for ages in your C# programs are based on conventions, rather than on a specific API. What I mean by this is, some constructs in C# are based on some magical methods with well-defined names which are not defined in any base class or interface, but yet just work. Let’s see what they are. Enumerating Collections You are probably used to iterating through collections using the foreach statement. If you are, you may know that foreach actually wraps a call to a method called GetEnumerator , like the one that is defined by the IEnumerable and IEnumerable<T> interfaces. Thus, you might think, the magic occurs because the collection implements one or the two, but you would be wrong: it turns out that in order to iterate through a class using foreach all it takes is that the c...