Allen Conway's .NET Weblog

Exploring all things .NET and beyond...

Resolve Multiple Interface Bindings With Ninject

The old adage "program to an abstraction, not a concretion" reigns true and used in most modern application design via the use of Interfaces and concepts like IoC and DI. The polymorphic behavior of Interfaces and their ability to have multiple implementations allows us to do some really cool things as well as be staged for highly testable code with mocking frameworks like Moq.

However I'd say 99% of the time we typically have 1 Interface bound to a single concrete class using our DI framework. There will be cases where you will want to take advantage of having more than 1 implementation of an Interface and need to configure this.

Ninject is a great DI framework and you can achieve this through the use of named bindings. In this case if we have an Interface named ICalculate you could have 2 (or more) implementations. However upon injecting the class into a constructor, how would you dictate which instantiation/binding to use? The named bindings accomplish this as follows.

1. Provide a name for the bindings using the same Interface to allow them to be unique:

2. Specify the named binding as an attribute applied on the argument of the Interface being injected:
readonly ICalculate _calculate;
public MathCalculations([Named("Calculation1")] ICalculate calculate){
    _calculate = calculate;

It's that easy! For more information, see the Ninject documentation here.

I'm Speaking at Modern Apps LIVE! (LIVE! 360) Las Vegas

I'm excited to be speaking at the upcoming Modern Apps LIVE! conference co-located at the Visual Studio LIVE!, LIVE! 360 Las Vegas conference March 16-20. This conference track has a fantastic lineup of speakers including Jason Bock, Brent Edwards, Anthony Handley, Rocky Lhotka, and Kevin Ford with a variety of topics surrounding Modern Application Development. 
There is still time to save $500 using my speaker registration code: LVSPK30 Click on the banner below to go straight to the registration page.


Here are the Modern Apps LIVE! sessions I'll be speaking at during the conference:

I hope to see you there and don't miss out on the registration savings above!!

Upgrading to Angular 1.3: Global Controllers Not Supported by Default

If you recently upgraded to Angular 1.3.x, you my get the following JavaScript error when trying to run your application:

Error: [ng:areq] Argument 'MyController' is not a function, got undefined

This issue is a result of some breaking changes where AngularJS no longer supports global controllers set on the window object as of version 1.3. In reality if you have a production application using global controllers, it is not advised and would be a prime target of refactoring regardless. However you might of had a small test app or the like that upon upgrading Angular to v1.3.x it stops working unexpectedly. The intention behind this change was to prevent poor coding practices.

The actual breaking change is highlighted on GitHub here:

I like how the use of global controllers according to the change was for, "examples, demos, and toy apps." I agree with the statements, so I'm OK with this change. It really is code smell to use controller functions in the global scope.

Let's look at code that would have worked in Angular versions prior with a trivial sample:

<body ng-app>
    <div ng-controller="MyController">
        <input ng-model='dataEntered' type='text' />
        <div>You entered: {{dataEntered}}</div>
    <script src='/Scripts/angular.js'></script>
    <script type='text/javascript'>
        function MyController($scope) {
            $scope.dataEntered = null;

The breaking change requires one to register the Controller with a Module to provide scope and pull it off the global window object. The changes required are shown below:

<body ng-app="SimpleAngularApp">
    <div ng-controller="MyController">
        <input ng-model='dataEntered' type='text' />
        <div>You entered: {{dataEntered}}</div>
    <script src='/Scripts/angular.js'></script>
    <script type='text/javascript'>
        (function () {
            function MyController($scope) {
                $scope.dataEntered = null;
            angular.module("SimpleAngularApp", []).controller("MyController", ["$scope", MyController]);

You might find this will have the biggest impact going forward when you are throwing together quick demos or examples using Plunker or a small test harness. Just remember to register the controller with a Module to prevent running into this error. 

There technically is a workaround if you must make a fix quickly, but not advised long term. You can choose to set $controllerProvider.allowGlobals(); which will allow the old code to run. You can read about it here:$controllerProvider

If your apps have previously been constructed using best practices, this should not impact you at all. For additional changes between Angular 1.2 and 1.3, see the following link:

I'm Speaking at Modern Apps LIVE! (LIVE! 360) Orlando

I'm excited to be speaking at the upcoming Modern Apps LIVE! conference co-located at the Visual Studio LIVE!, LIVE! 360 Orlando conference November 17-21. There are still a few days left to save $600 using my speaker registration code: LSPK17 Click on the banner below to go straight to the registration page.

Here are the Modern Apps LIVE! session I'll be speaking at during the conference:

MAH05: Building a Responsive Single Page App
MAF01 Workshop: Modern App Development In-Depth: iOS, Android, Windows, and Web

I hope to see you there and don't miss out on the registration savings that end 10/24!

Fixing the "Authentication failed" Message When Accessing a TFS-Git Repository

Recently I've been working with a TFS Project using Git as the source control provider and something locally has gone wrong and I just couldn't remedy in VS.NET directly. The buzz and consensus already seems to be that managing your Git repository with one of the following tools is easier and more powerful than VS.NET IDE integration:
  • Git Bash
  • Git for Windows
  • TortoiseGit
  • SourceTree
  • Git Gui
I have used Subversion in the past so TortoiseGit was familiar already to me, but the others were not too hard to test out as well. The main goal of what I needed to do was a simple Git Pull to update my local repository to the most current version. I'm using a Windows LiveID to authenticate to the TFS Online Project just fine in VS2013 and made the original clone successfully.

VS2013 initially had no issue doing a Pull, but once things got messed up I decided to use an external tool to fix the problem. The issue is all the tools kept failing authentication with the following error in some flavor below. It didn't make sense because the credentials I was providing worked previously.

"Authentication failed"

Note - it's know that the VS IDE integration with Git does not expose all the functionality available, so if you get into a mess with your repo its probably not going to be easy to fix from VS.NET's tooling. 

It turns out the solution is to modify a setting on your Windows LiveID account to 'Enable alternate credentials'. You can reach this setting by clicking on your user name in the top left-hand corner once logged into your Live account, selecting 'My Profile', and then selecting the 'Credentials' heading.

Here you will need to click the link to 'Enable alternate credentials' and fill in a password, and secondary username if desired or if the application you use can't use an email address for a username:

This allows the use of basic authentication credentials and fixes the authentication issue with the tools I listed above to manage a Git repository. Make sure to use these credentials when authenticating and you should now be able to manage your TFS-Git repository without authentication issues.

How To: Export a SQL Server Database to Windows Azure

If you are beginning to work with Windows Azure and are ready to deploy an application or service, you may begin to wonder how to export that existing backend SQL Server database as well. 

The good news is it's quite trivial to do by using SQL Server Management Studio and the Windows Azure Management Portal. For this example I'm going to use local my 'BowlingStats' SQL Database that is used with my BowlingSPA application to export to Azure.

  • Obtain a Windows Azure Account

1. Create a Storage Account

Once logged onto the Azure Management Portal, select 'Storage' from the options on the left, and then from 'Data Services' -> 'Storage,' select the 'Quick Create' option. Enter a URL for the name of your storage account as well as a location and replication strategy. Normally Azure will pre-populate with the best default options but you can change them if desired.

You will see a message once the account has been successfully created:

Upon creating the account you will be presented with a screen containing a 'Primary' and 'Secondary' set of access keys for the Storage Account you just created. Store these keys as they will be needed to connect to Azure Storage later from SQL Server.

Don't worry if you quickly dismissed the dialog with the keys. You can always get back to them by selecting 'Manage Access Keys' at the bottom of the 'Storage' Azure option. You can also regenerate the keys if they have been compromised.

2. Export your SQL Database as a .bacpac file directly to Azure

Now that we have a storage account, we need to hop over to SQL Server Management Studio 2012 and export our database as a .bacpac file to Azure.

Right-click the database and select, 'Tasks' -> 'Export Data-tier Application...'

After selecting 'Next' from the Introduction screen, select the 'Save to Windows Azure' option and then press 'Connect'. Here you can enter the name of your Azure Storage Account created in step 1, as well as the 'Primary' key value provided when the Storage Account was created. Press the 'Connect' button once the information has been entered.

After the connect dialog has been dismissed add a 'Container' name that will contain the .bacpac file on Azure. Once the information is all correct, press the 'Next' button and being the export of data from your SQL Server database directly to Windows Azure! 

Once successfully exported, the bacpac file will be available for import back on the Azure Management Portal in storage.

3. Import your uploaded bacpac to a SQL Database on Azure

Finally, let's go back to the Windows Azure Management Portal and import the SQL Database bacpac file. Select 'SQL Databases' from the options on the left, and then from 'Data Services' -> 'SQL Database,' select the 'Import' option.

The next dialog will allow you to choose the database settings. To select the bacpac we already uploaded, press the folder icon to browse to the available data files in storage.

Expand your storage account and you should see the container name set when the .bacpac file was exported from SQL Server. Select the file and press 'Open' to automatically populate the bacpac URL.

Enter a name for the database, select your subscription, service tier, (do not select 'Web' or 'Business' from the screenshot as they will eventually be retired), performance, max size, and server. If you have previously created a SQL Server instance, you can choose it and provide the login information. If this is the 1st time, select  'New SQL database server' and press the next button. 

You will now need to create the SQL Server instance login information. Note that while sometimes Azure appears to be smart and pre-populate options (i.e. Region') with the one closest to you, I did not find this to be the case with this dialog. I believe 'East Asia' was pre-selected and provided me a warning that the storage account and database were not in the same region. Make sure to switch it to the same value as your storage account and the warning will be dismissed. Once you enter your login credentials, press the accept button to complete the process.

That's it! Your new SQL Database and instance once provisioned will display under 'SQL Databases' in Windows Azure for all of your cloud application and service needs.

To take thy code personally - Yes or No? That is the question...

One area of conversation that tends to come about in software engineering is the degree to which one takes their code personally. Litmus test: that shiny gem you wrote was code reviewed and recommendations are made to make some changes. Do you:
  1. turn red, tell the reviewer how idiotic they are, storm away, and start looking secretly for a new job?
  2. listen to what the other party has to say and make sense of it as a learning experience?
Now this is only one of many examples of taking code 'personally,' and realistically is a bit of an extreme in option 'a.' This behavior though takes shape and evolves in different ways, but I believe if this is an attribute you posses it's one to shake and shed fast for the betterment of your career,

I have for years stated it wasn't the physical lines of code I laid down, but the byproduct of what I learned that is the real personal reward. I've written apps over the years that for one reason or another didn't make it to prod or where short lived. However the experienced gained from what I did was what kept moving me forward.

For example - "Hey Allen, you aren't upset that app you worked on got scrapped because the business did a 180?" Me: "Nope. Because now I know a ton about x, y, and z and am a better developer for it."

I actually had a (technical) debate/argument about this topic with an industry peer within the last few years. I stated I don't take my code too personally and the experience gained was paramount (after all that continued experience helps me move on and do bigger and better things). Sure I absolutely want what I create to succeed, but if it gets thrown out, rewritten, refactored, or the like I will not loose any sleep at night. I will however if it presents itself take note and learn from it to grow. This person couldn't understand why I wouldn't take great pride in what I did and die by the sword if need be for the lines of code I write and that those that took their code personally were more along the lines of what they thought were 'great programmers'. Problem with this is you so much as critique the architecture/design of ones code with this so called 'passion' and get ready... it's like you just told them they have a 3rd eye or something.

Do not confuse taking your code personally with instilling quality in an application. These are separate and one does not depend on the other. If the code you are responsible for is used on an aircraft and in charge of avionics - sure you absolutely care about that code and it's quality. However, the aircraft dev guru that told you your C++ methodologies were outdated and we are programming for Boeing not Pan Am in the 70's - you need not again take this personally. If you care about your craft you will truly try to grow from others suggestions and wisdom, learn from your experiences, and continue to move forward.

Next and also important, do not confuse taking your code personally and having passion for your craft as a software engineer. Again these are not intersecting lines. I have a major passion for my career and craft as a software engineer. It's what keeps me on the computer late at night learning new technologies, preparing for presentations, and blogging. This has nothing to do with taking personally the code I write. Taken from "the grumpy programmer" and said best by someone with uber experience, "Don't fall in love with your code."

Before posting this I read over what I wrote a few times because I don't want it coming across as I don't care - because I absolutely do; ask those I work with and they should concur. However, I don't let that VB6 app I wrote 12 years ago and put my blood, sweat, and tears into and the fact that it's no longer used bother me one bit. However, the knowledge I gained at that time helped get me to where I am today.

So the answer to the title - 'no', do not take your code personally. Odds are the lines of code you write today will not be around in 10 years. Instead try to find great joy in the experience you gain from what you do because you can take that with you from project to project and it will certainly be around for many, many years to come.