C# on Andrew Bancroft

Entity Framework Tip – Specifying Decimal Precision

Wed, 29 Mar 2017 20:57:27 +0000

By default, Entity Framework takes the .Net decimal Type and maps it to SQL Server’s decimal(18,2) data type.

If you’ve got a property on an Entity that is of Type decimal, but down in your database, you’re allowing for greater precision than 2 decimal places (scale is actually the proper term for the number of places after the decimal), you need to tell Entity Framework this information. Otherwise, decimal values that you save to your database will be truncated at the default 2 decimal places.

Updating decimal scale with Entity Framework

To tell Entity Framework that you need different precision than decimal(18,2), you need to open your DbContext implementation.

Then take a look at your OnModelCreating override.

If you haven’t implemented an override yet, go ahead and create one. If you’ve already got some Code First stuff in your OnModelCreating override, add to it by following this example:

1protected override void OnModelCreating(DbModelBuilder modelBuilder)
2{
3    modelBuilder.Entity<NameOfEntity>()
4                .Property(p => p.NameOfProperty)
5                .HasPrecision(9, 4); // or whatever your schema specifies
6}

It’s as simple as that! Once you make this update, your decimal values won’t be truncated at the second decimal place anymore. They’ll be as precise as you’ve specified in your call to HasPrecision().

Solving ‘Spatial types and functions are not available’ with Entity Framework

Mon, 27 Mar 2017 16:38:33 +0000

Using SQL Server’s Geospatial features with Entity Framework is awesome. I was crusing along just fine with using DbGeography for an ASP.Net application I’m working on… Right up until I deployed to the server. Yep. It worked on my machine, but alas, I was hitting a runtime exception on my test server.

This was the exception:

Spatial types and functions are not available for this provider because the assembly ‘Microsoft.SqlServer.Types’ version 10 or higher could not be found.

Luckily, I ran across a Stack Overflow answer that almost helped me get all the way there in solving this exception. It was actually the second-most up-voted answer that helped me the most. You’re welcome to reference these if you want, but since the info is scattered between the question and the two answers, I’m assembling it here for your convenience.

Fixing ‘Spatial types and functions are not available'

1 – Install the Microsoft.SqlServer.Types package from NuGet

You can install it using the NuGet Package Manager UI, or from the command line:

> Install-Package Microsoft.SqlServer.Types

2 – Follow readme.htm instructions

After you install the NuGet package, a readme.htm file is opened and displayed to you. If you don’t see it for some reason, a new SqlServerTypes folder was added to your project. You can expand it and double-click readme.htm to open it.

Follow the instructions within.

Depending on the type of app you’re deploying, you need to perform different steps. I happened to be deploying an ASP.Net MVC app, so I followed the instructions for adding a line of code to Global.asax.cs. Your situation may be different, but the Readme instructions are clear on what to do.

ASP.Net Web Applications

Open Global.asax.cs and add the following to the list of registrations in Application_Start():

1protected void Application_Start()
2{
3    // Enables use of spatial data types
4    SqlServerTypes.Utilities.LoadNativeAssemblies(Server.MapPath("~/bin"));
5
6    // Other registrations...
7}

Asp.Net Websites

Open Default.aspx.cs and add

 1public partial class _Default : System.Web.UI.Page
 2{
 3    static bool _isSqlTypesLoaded = false;
 4
 5    public _Default()
 6    {
 7        if (!_isSqlTypesLoaded)
 8        {
 9            SqlServerTypes.Utilities.LoadNativeAssemblies(Server.MapPath("~"));
10            _isSqlTypesLoaded = true;
11        }
12        
13    }
14}

Desktop Applications

Add the following before any spatial operations are performed.

1SqlServerTypes.Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory);

3 – Tell Entity Framework which version of the assembly to use

Most of the explanations of how to solve the “‘Microsoft.SqlServer.Types’ version 10 or higher” error stopped at step 2.

After performing the steps that readme.htm outlined, I re-deployed the app, and things were still broken. Same exception. What gives??

This is where that second-most-popular answer came into play. It gave me the clue I needed.

Back in Global.asax.cs (or wherever you performed the steps for #2 above), add the following”

    SqlProviderServices.SqlServerTypesAssemblyName =
    "Microsoft.SqlServer.Types, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91";

Note: Depending on which version of the NuGet package you installed, you need to adjust the Version number from 14.0.0.0 to the correct version, as appropriate. I installed the latest, which at the time is version 14.x, so that’s what I put in.

??? The SqlServerTypesAssemblyName property doesn’t exist! ???

In my case, I ran into another small hurdle. When I tried to set the SqlServerTypesAssemblyName property, it didn’t exist!

Upon further inspection, I discovered that I only had Entity Framework version 6.1.**** installed. I updated to 6.1.3, and the property lit up. I set it appropriately, redeployed the app, and it magically worked.

Here’s hoping that this helps bring together several pieces of information to get you going with using SQL Server Geospatial data types with Entity Framework!

Analyzing Swift Protocol Extensions and C# Abstract Classes

Fri, 07 Aug 2015 03:52:25 +0000

Being a C# developer by day and a Swift developer by night has me constantly thinking about the similarities and differences between these two languages. I genuinely enjoy programming with each, and I love it when I can take a strategy that works well in one language, and see where that might cross over to the other. One of the areas I’ve been pondering as of late is the idea of how Swift and C# compare in terms of protocol extensions and abstract classes.

Swift doesn’t have the notion of abstract classes like C# does. However, it does now have an amazingly powerful feature called protocol extensions, which were explained and demonstrated in the popular WWDC15 talk on Protocol Oriented Programming. Why am I comparing protocol extensions with C# abstract classes? What are the similarities? What are the differences? Which one do I like best? The analysis of and concluding answers to these questions is the goal of this article.

Why the comparison?

What got me thinking about this? Well, I was re-watching Protocol Oriented Programming the other day and was digesting some of the arguments for why protocols often serve as better abstractions than classes. When classes are used to model a generalized abstraction, the only way they do it is through inheritance. Subclasses of some other, more generalized, base class will automatically be able to behave the same and store the same state as that base class by virtue of inheritance.

Protocols on the other hand, model abstraction through composable template-like descriptions: “Adopters of this protocol will do [x, y, and z] by implementing [function x, function y, and function z] and will have [property a, and property b]”, etc… But they define a template only – no implementations are defined within a protocol.

In C#, we have a similar mechanism to protocols called interfaces. The same paradigm of defining a template with no implementations exists in C# when we use an interface to model some abstraction. C#, of course, also has classes and can pass along behavior and state to subclasses through inheritance.

Understanding C# abstract classes

But C# has one other mechanism for abstraction: abstract classes. These special types of abstractions have the ability to behave like interfaces (or protocols) in that they can strictly define a template with no implementation, requiring all subclasses to supply that implementation. But abstract classes are unique in that they aren’t required to define a template only – they can actually provide a default implementation that may or may not be overridden in a subclass, depending on what the implementer of the subclass wants to do.

We still can’t make instances of an abstract class, just like we can’t make instances of an interface or protocol. But with abstract classes, we can provide some default implementation that can be a customization point for concrete subclasses, should the implementer of the subclass desire to override this default behavior.

Bringing it back to Swift

So… what does this have to do with Swift? Well, it seemed to me that there’s a little overlap between Swift 2.0’s new protocol extensions, and C# abstract classes. How?

With Swift protocol extensions, we can now provide default implementation for a protocol requirement, such that any adopter of the protocol automatically uses that implementation and satisfies that particular requirement of the protocol.

A given Type implementing the extended protocol could choose to provide its own implementation to customize the behavior as it needs. But if it chooses not to, it gets that default behavior for free.

Therein lies the overlap I see between Swift protocol extensions and C# abstractions. But let’s explore a little more in terms of similarities and differences between the two by analyzing an example.

Working example: Modeling athletes

Suppose for a moment that we’re working on an app that models athletic competition (such as marathons, triathlons, and other sporting events). Now, athletic competition implies athletes, does it not?

How then, could we model an Athlete in an abstract way? That is, how can we provide just the blueprint for what an Athlete does, so that such a Type can be entered into one of the athletic competitions and perform in it?

Modeling the Athlete abstraction with C#

In C#, we’ve got two possibilities: Create an interface, or create an abstract class.

Using an interface may look something like this:

1public interface Athlete
2{
3    public void Run();
4    public void Swim();
5    public void Cycle();
6    // Other things that an Athlete may be able to do
7}

Using an abstract class may look very similar. The primary difference is in the declaration of each method, where we mark each of them virtual, so that they can be overridden in a subclass to provide that customization point I talked about earlier:

1public abstract class Athlete
2{
3    public abstract void Run();
4    public abstract void Swim();
5    public abstract void Cycle();
6    // Other things that an Athlete may be able to do
7}

Right off, you might be asking, “Should a marathon runner have to be able to swim and cycle??”. It’s a great question, and I’ll address it further down in the article when I discuss “refactoring for enhanced composability with Swift protocol extensions”.

Modeling the Athlete abstraction with Swift

In Swift, we essentially have one possibility that compares with C# for a pure abstraction, that is, just the blueprint describing an Athlete's capabilities: Create a protocol.

The Athlete protocol might look something like this:

1protocol Athlete {
2    func run()
3    func swim()
4    func cycle()
5    // Other things that an Athlete may be able to do
6}

We still don’t avoid the necessity of a marathon runner being required to be able to swim and cycle. And having read David Owens’ recent recommendations on Protocols, I’m even more uncomfortable with modeling an Athlete this way, because it feels like we’re treating a protocol as a Type here, which he identifies as a less powerful usage of protocols.

I want to refactor this, but for this moment in time, we’ll stick with the code as-is, just to keep it as similar to the C# code as possible. I’ll discuss an option for refactoring this shortly.

Default implementation for athletic abilities

As the example stands right now in both C# and Swift, we’ve got a situation where any Type wishing to be an Athlete, whether it be by implementing the C# interface, subclassing the C# abstract class, or adopting the Swift protocol, must provide implementations of each of those athletic abilities (run, swim, and cycle). The Type can’t not implement one of those requirements and have the code still compile. They’re requirements of what it means to be an Athlete, so the Type must conform.

Suppose that in our scenario, any given Athlete has one primary ability which he/she is amazing at, but when it comes to his/her non-primary abilities, the Athlete is only able to perform at “average” skill.

This sounds like a case where it might be nice to have overridable default implementation provided. Any specific type of Athlete could override that default implementation to perform the ability better or worse, depending on what kind of Athlete he/she is. But if the specific Athlete Type didn’t provide an customized override, the Type would get the “average” behavior for free.

How could we make this happen?

Default implementation with C#

In C#, abstract classes allow us to do just that. Here’s how a default implementation might be written:

 1{
 2    public virtual void Run()
 3    {
 4        // run with average speed and endurance
 5    }
 6
 7    public virtual void Swim()
 8    {
 9        // swim with average speed and endurance
10    }
11
12    public virtual void Cycle()
13    {
14        // cycle with average speed and endurance
15    }
16}

So now, when we want to model a MarathonRunner, we can override his/her ability to run, swim, and cycle as appropriate:

1{
2    public override void Run()
3    {
4        // run with average speed and __insane__ endurance
5    }
6}

It’s not terrible – At least here we can rely on the default implementation if we just want to give a MarathonRunner “average” abilities in all areas but running.

We might prefer that a MarathonRunner not be required to have any ability to swim or cycle, but that’s always the struggle with inheritance-based modeling. You only get to choose one base class to inherit from, and you’re bound to get some behavior that you don’t need, simply because it’s hard to model abstractions using inheritance that avoid giving you more than you need.

Default implementation with Swift

The default implementation story with Swift was non-existent until Swift 2.0 entered the scene. The approach is similar, but as we’ll see shortly, provides far more power in terms of composability. Take a look at the implementation that compares most closely with C# for now:

 1extension Athlete {
 2    func run() { // run with average speed and endurance 
 3    }
 4
 5    func swim() { // swim with average speed and endurance 
 6    }
 7
 8    func cycle() { // cycle with average speed and endurance 
 9    }
10}

Now when we want to model a MarathonRunner in Swift, we can adopt the Athlete protocol, and provide “override” implementations for any of the protocol’s requirements that we’d like. Anything we don’t provide a custom implementation for falls back to the protocol extension’s implementation, just like in C#:

1class MarathonRunner: Athlete
2{
3    func run() {
4        // run with average speed and __insane__ endurance
5    }
6}

Similarities

Here’s a list of the similarities I see between C# abstract classes and Swift protocol extensions:

Both outline a set of requirements that either a subclass or a protocol adopter must implement.
Both provide a means to automatically satisfy some (or all) of the requirements by providing a default implementation. With C#, we simply mark the method virtual to allow overriding in the subclass, and provide then an implementation. With Swift, we define a protocol extension that implements one or more of the protocol’s requirements.
Both ease the burden of subclasses (C#) or protocol adopters (Swift) to implement all of the requirements when reasonable default implementations could suffice.
Both are used to provide customization points in subclasses (C#) or protocol adopters (Swift), when the default implementation is inadequate.

Differences

So there are some similarities that I hope you can see and appreciate between C# abstract classes and Swift protocol extensions. But there are some major differences that should also be recognized:

Fundamentally, C# abstract classes are a “behavior by inheritance” tool, while Swift protocol extension are a “behavior by composition” tool.
Consequently, C# abstract classes impose a significant limitation: subclasses can inherit from one and only one base class. Swift protocols, on the other hand, can be decomposed into fine-grained, specific requirements that can later be re-combined and composed into more robust and dynamic Type specifications. While C# interfaces provide this same composability, they don’t have the ability to provide default implementation, which is a significant difference between the Swift counterpart.
As a consequence of that, subclasses of a C# abstract class get all of the behavior, whether they need (or want) it or not. Swift protocols, being composable, allow a Type to conform to just the pieces it needs. The protocol extension can still exist to provide default behavior when it’s appropriate. But if a certain Type needs no ability to [do some thing], it simply drops conforming to that protocol and no superfluous behavior is imposed upon the Type.

Preferring one over the other

Needless to say, I prefer Swift protocol extensions over C# abstract classes (shocker). I love the composability they offer, while at the same time allowing me to provide default implementations where it’s appropriate. In my opinion, Swift protocol extensions are the perfect blend of interface and abstract class in C#. If only C# had “interface extensions”. :]

Since we can apply multiple protocols to a Type to signify what the Type can do, and essentially compose its behavior, how might we diverge from the constraints we had previously when we tried to stick closely with the C# abstract class paradigm?

Recall that I was uncomfortable with making a MarathonRunner have ability to swim and cycle, however “average” that ability may be. What I really want is to break things out a bit more, but still be able to provide that default implementation when I want it.

How might I refactor this by leveraging even more of the power of Swift protocol extensions?

Refactoring for enhanced composability with Swift protocol extensions

I think I might like to define 3 protocols instead of 1. Rather than modeling things as Athletes, I’d much rather model some athletic behavior, and let the specific kinds of athletes adopt whatever behavior is most appropriate for each athlete type.

So I’ll ditch the Athlete protocol, and define these three instead:

 1protocol Runnable {
 2    func run()
 3}
 4
 5protocol Swimmable {
 6    func swim()
 7}
 8
 9protocol Cycleable {
10    func cycle()
11}

Alright… now… how about some default implementation?

 1extension Runnable {
 2    func run() {
 3        // run with average speed and endurance
 4    }
 5}
 6
 7extension Swimmable {
 8    func swim() {
 9        // swim with average speed and endurance
10    }
11}
12
13extension Cycleable {
14    func cycle() {
15        // cycle with average speed and endurance
16    }
17}

Excellent. Now to cap things off, I’ll define some Types that adopt just the protocols that are needed:

 1struct MarathonRunner: Runnable {
 2    func run() {
 3        // run with average speed and __insane__ endurance
 4    }
 5}
 6
 7struct Triathlete: Runnable, Swimmable, Cycleable {
 8    func swim() {
 9        // swim with lightning speed and crazy endurance
10    }
11
12    // fall back to protocol extension's average run speed & endurance
13    // fall back to protocol extension's average cycle speed and endurance
14}
15
16struct Andrew {
17    // Let's not impose the re-definition of any of the athletic terms, shall we?
18}

Notice how the different types of athletes only pick up the behavior that’s relevant to their ability. Nothing more, and nothing less.

I also enjoy being able to look at a Type declaration like Triathlete and see that he/she is able to run, swim, and cycle. It feels right to compose abilities this way. And it’s even more convenient that some of the Triathlete's behavior is already implemented for me by virtue of the protocol extension.

Wrapping up

I hope this analysis helped you see some of the same things I saw when it comes to how abstractions can be modeled with Swift, and how that compares with others languages like C#.

Up and Running with Unity IOC Container for ASP.Net MVC

Mon, 27 Oct 2014 18:07:21 +0000

The process for creating an ASP.Net MVC web application that relies on the Unity Inversion of Control (IOC) container has gotten quite a bit more streamlined since I first started working with it. However, since I don’t start brand new software projects often, it’s often the case that it takes me a few minutes to figure out which NuGet package to install to get things up and running.

The following is a quick-reference for myself, and for anyone else who’s interested in getting up and running quickly with the Unity IOC container for an ASP.Net MVC project.

Assumptions:

Using Visual Studio 2013
- Using ASP.Net MVC 5
  - Have already created a new, fresh solution (File –> New Project, etc)
Walkthrough

Begin by right-clicking your solution, and choosing to “Manage NuGet Packages for Solution…”:

Next, choose to search for packages found at nuget.org. In the search bar in the upper right, type in “Unity”, and press enter. Choose to install “Unity bootstrapper for ASP.NET MVC”:

Now that the appropriate NuGet package is installed, you’re set to start using the Unity IOC Container.

Using Unity for Dependency Injection and Management

I’ve contrived an example and tried to show side-by-side views of the bare minimums you need to program in order to start taking advantage of Unity for managing your dependencies. I’m going to show how to inject a concrete implementation of a very simple Interface into the HomeController. The steps go something like this:
1. Create an Interface (in this example, I called it IUnityExample) which specifies that an implementer of this interface must define an itWorksMessage method that returns a string.
  - Create a new class called UnityExample. Specify that it implements IUnityExample in the class declaration line. Implement the required itWorksMessage method.
    - In HomeController.cs, declare a private variable to hold an instance of an IUnityExample.
      - In HomeController.cs, declare a new constructor which takes an IUnityExample (to be injected by Unity) and sets the privately declared IUnityExample variable to the instance that’s passed in.
        
        Utilize the itWorksMessage somehow. In my example, I set the return value to a new dynamic property called ViewBag.Message inside the Index method.
        
        In UnityConfig.cs, register IUnityExample and UnityExample with the container inside the RegisterTypes method.
Let’s pause here and show that side-by-side view I referred to a second ago. Perhaps visualizing the files in play will help bring the whole picture into view:

At this point, we’re done with writing C# code, and we’re ready to move into the View layer. This final step will access ViewBag.Message, and display it at the bottom of the page. It’s fairly straight-forward. Inside Views –> Home –> Index.cshtml, simply add a

that contains @ViewBag.Message:

To confirm everything works, run your solution and verify the results!

Summary

In this article, you’ve seen how to use NuGet to install the required components to get up and running with the Unity Inversion of Control container. Additionally, you saw a bare-bones example demonstrating the steps required to start using Unity to manage your dependencies with ASP.Net MVC.