techbash-2016The content for TechBash is really looking good. Ok, I am biased a bit because I am helping to run the event Smile.

But seriously, we’ve got great speakers coming in from around the country to share their knowledge with you. I’m excited about a lot of it but some areas really stand out. For us ASP.NET developers, so much is changing and there is a lot to learn. Now is the time to get up to speed. Here are a just a few of the talks that are sure to help:

Title: A Deep Dive on ASP.NET Core

Presenter: Jeffrey Fritz

Are you considering ASP.NET Core for your next project? In this session, join one of the Microsoft program managers responsible for this new development platform as we take an in-depth look at the new ASP.NET Core platform. We will cover how the new .NET command-line interface enables you to build applications inside and outside of Visual Studio. We’ll look at how to use ASP.NET Core with docker and how you can build re-usable components with NuGet integration. Attendees of this session will have a deeper understanding of the topics they need to deliver more effective and faster applications with ASP.NET Core.

If you don’t know Jeff, you should. For us Philly locals, Jeff is well known as he is one of us. He’s been speaking in our area for years (I’m pretty sure was at his first talk ever) and now he is a Senior Program Manager at Microsoft! Not only that, he’s a great presenter and writer! Yes, this is a great opportunity to get the info from someone who really knows his stuff. We are really lucky to have Jeff with us at TechBash. You can see Jeff’s full bio and view all of the sessions (although the list is still growing) on the TechBash website.

Title: Getting started with Entity Framework Core

Presenter: Jim Wooley

With the cross-platform version of .Net, Microsoft has had to rewrite many of the core components that we have come to depend on. If you include data in your applications, chances are you have used Entity Framework in the past. In this session, you’ll learn how to get started using EF Core and how to handle the changes in this version.

Lucky for us, Jim Wooley is traveling to us from Atlanta. He’s the author of the popular “LINQ in Action” which is an awesome book. He’s also a great, popular presenter at conferences around the country. You can see Jim’s full bio and view all of the sessions (although the list is still growing) on the TechBash website.

Title: A Lap around ASP.NET Core 1.0!

Presenter: Sam Basu

Man, naming products is hard! But change is in the air for ASP.NET developers, as vNext ushers in a new era. Let’s talk – .NET Core | ASP.NET Core 1.0 | Open Source | .NET Frameworks Changes| ASP.NET Runtimes | WebForms | MVC 6 | Cross-Platform Tooling | Omnisharp.NET | Homebrew | Yeoman | CLI with VS Code or Sublime Text | Docker. Join me as we explore all that’s new & shiny. This is one of the best times to be an ASP.NET developer – let me show you why!


Did you read the summary above? Can you see how much there is for us to learn to be ready for ASP.NET Core? Sam Basu is coming in to help us out. Sam Basu is a Developer Advocate at Telerik (now Progress). He’s also a popular speaker and you are sure to learn a lot. You can see Sam’s full bio and view all of the sessions (although the list is still growing) on the TechBash website.

So, is that all?

NOPE! There will be lots of other great sessions at TechBash 2016. Please check out the current list on our website. I’ll try to highlight more soon.

TechBash: Sept. 28-30, 2016

Kalahari Resort, Mt Pocono, PA

Purchase your tickets and book your room now! We have a limited number of tickets and hotel rooms.

I look forward to seeing you there!

ASP.Net Developers, it is time to change your attitude towards JavaScript. I know you hate it. I used to hate it too. But I’ve come to terms with JavaScript and now actually quite like it! It isn’t my favorite language but I’ve been working hard to understand this important client side technology.

Please don’t be offended by this post. I know I have lumped all ASP.Net developers into one category here. I know many of you are in the same place as I am, moving quickly towards understanding Javascript. I am, however, speaking to a large group of .Net web developers who have not yet started their journey. You know who you are.

I’m a C# MVP and, prior to this past summer, I spent 3 years doing Silverlight development. I truly believe that Microsoft was on to something with the concept of Silverlight. Like many developers, with regard to client side web development, I knew there had to be a better way to do things than JavaScript. Silverlight was a great attempt. It wasn’t perfect but the concept was good. Heck, I thought that anything that saved me from JavaScript was a good thing. I don’t care what anyone says, JavaScript is not the best solution to client side programing. I think we could have had better. Silverlight was a good try but people didn’t embrace it for various reasons (I won’t get into that in this post). Well here we are now and Silverlight is pretty much toast. It seems like Microsoft has thrown in the towel and isn’t trying to replace JavaScript and I doubt anyone else will pick up that fight.

For the past 8 months or so, I’ve been back doing “traditional” web development. I’m quite happy to be in the world of MVC with HTML, JavaScript, and CSS. In the past few years, a lot has changed. Three and a half years go, when I last did this sort of work as the main part of my job, jQuery was gaining a lot of traction and was becoming widely accepted. But not like it is today. Today, many developers incorrectly use the words JavaScript and jQuery interchangeably (which is actually quite annoying). And as great as jQuery is, there are a ton of other great JavaScript libraries to help us developers. Patterns like MVVM and SPA have gotten quite popular. And I’ve learned that there are some other great patterns that can be applied to JavaScript development that can make the experience much better, especially for a pattern-happy OO developer like me. So I have been reading up on and practicing using closures, the revealing module pattern, prototypes, MVVM, dependency injection, and more. And I haven’t even started with TypeScript which looks very interesting, to say the least. And I should also mention that products like Visual Studio (and many plugins too) have come a long way to finally embrace JavaScript and have started to treat it like a first class citizen.

In addition to the fact that doing client side development is much better these days thanks to frameworks and tooling, our users have come to expect a richer experience from web sites and applications. Users want web pages to be useable and responsive and, dare I say, “nice to use”. And so, fellow ASP.Net developers, the time for faking our way through JavaScript is over. I have put a lot of effort into learning more about JavaScript. I’ve started treating that part of my job as seriously as I do C#. I don’t expect that I’ll become some kind of JavaScript Ninja anytime soon, but I’ve realized that JavaScript enhanced UIs are an important part of my work. I’m giving JavaScript respect and I’ll expect other developers to do the same. No longer will I accept a job candidate’s dismissive answers about their knowledge of JavaScript. “Yeah, I can do a little JavaScript but I don’t like it” is no longer a valid answer to an interview question. JavaScript is an important aspect of our jobs as web developers and it isn’t going anywhere, at least not for a while.

I talk about this story a lot… few years ago in a team meeting the developers were complaining about their struggles in writing JavaScript which was becoming an important aspect of our web solution. Our manager, who is a really smart guy and still a friend of mine, asked a few questions that made a big impact on me. First he asked, “How many books have you guys read about C#?” The response varied across the team but we had all read a bunch of them. He followed that up with the knockout punch… “how many JavaScript books have you read?” The room was pretty quiet. Most of the group had read none. At least I had read one, but I was wasn’t much different than the group. JavaScript programming was part of our job but yet we didn’t take the time to learn it. And through my career I have found that most ASP.Net developer’s (myself included) experience with and towards JavaScript was pretty similar.

The age of treating JavaScript with disrespect is over. It’s a necessary part of our web solutions. And as I said earlier, the frameworks and tooling have gotten much better. So now is the time to learn it, embrace it, use it, and succeed with it.

When developing web sites, we should all be thinking “touch friendly”.

Now that I have a Surface RT tablet, I realize how bad so many websites are for touch devices like a tablet. Lucky for me my Surface has a keyboard with a track pad built into the cover. Because on numerous occasions I find myself stuck on a website and I need to switch to “keyboard” mode and use the track pad/pointer to be able to use some drop down menu type of input.  Obviously this didn’t matter for many years an there are a lot of old sites living across the internet. Over the years, I was just I was just as guilty of this bad programming technique as the next developer, we just didn’t need to worry about touch. But those days are over and I’m ready to make a change.

By the way, I’m not going to get into a rant about how bad most websites are to use on smaller mobile devices like phones! This is a similar issue but there is a difference.

As more and more people are using tablets as their primary device for the web, we developers need to get with the program and ensure that we give our guests a first class experience.

Here are a few simple tips to follow:

  • Don’t rely on hovering. Touch users don’t have a mouse pointer so they’ll be stuck.
  • Make targets large. If you expect a user to click something, think about the size of the average user’s finger.
  • Keep pages simple. It’s much easier for touch users to use your site if you keep things simple and uncluttered.

So fellow developers, please join with me in this New Year’s resolution by taking this pledge:

I, state your name, promise to start making websites and applications that don’t suck for touch devices. I promise to care about my users and build sites and applications that they can use easily.

Happy New Year! Good luck with this and all your other resolutions.

I’ve said this so many times, writing unit tests is easy if the code was written well in the first place.  And when I say “written well”, what I really mean is “written to be testable”.

So here is the situation:  I have a simple service that does some logging, most of the details are not important.  But in the LogDebug() method, the code checks the web.config file to see if the debug logging is enabled.  That too in itself is pretty simple stuff.  Typically it would look like this:

bool configDebugMode = bool.Parse(WebConfigurationManager.AppSettings["Logging.Debug"]);

EDIT: I should point out what I mean when I say below that testing this code isn’t very easy. Sure, testing it is easy if I only want to test one value from the web.config file, such as ‘true’. But in this situation, I want to test when the config file value is ‘true’, and also when it is ‘false’.

But testing that isn’t very easy at all.  You’d have to do some crazy stuff with multiple config files or something.  But if the code was written differently, it’s very easy to test.  The key is to wrap the call to WebConfigurationManager in another class that implements and interface, then use dependency injection.  And with the class designed like that, you can use a simple mock to make the testing simpler.  It’s really easy, here is how I’m doing it.

First I define an interface, I’m calling it IConfigurationManager: 

public interface IConfigurationManager
    string GetAppSetting(string key);
    ConnectionStringSettings GetConnectionString(string key);

The interface has two simple methods so I can use it to get AppSettings and ConnectionStrings.  Could be I’ll need to add some more methods later but I don’t need them yet.  Next I implement the interface in a concrete class that can get the values from the web.config.  This too is really simple.  I’m calling this class WebConfigConfigurationManager.  That may sound weird and redundant but it tells me that it is a ConfigurationManager that gets values from WebConfig.  If I need an implementation that pulls values from a db I could make another one called DbConfigurationManager.  Here is the code:

public class WebConfigConfigurationManager : IConfigurationManager
    public string GetAppSetting(string key)
        return WebConfigurationManager.AppSettings[key];

    public ConnectionStringSettings GetConnectionString(string key)
        return WebConfigurationManager.ConnectionStrings[key];

So far this is was pretty easy to write and you can see it isn’t too complicated so it should work pretty well.  But this doesn’t make it any more testable.  The key to making it testable is Dependency Injection.  My LoggingService will “depend on” this WebConfigConfigurationManager class.  But instead of just instantiating WebConfigConfigurationManager within LoggingService, I’ll inject it in.  By doing that, I’ll also be able to inject something different during unit tests.  Hang in there, I’ll show you how.  First, here is the injection part, it is much simpler than it sounds. I inject the dependency via the constructor, you’ll note I am injecting a few other dependencies too:

public LoggingService(IEnterpriseLoggingRepository loggingRepository,
                        ILoggingInformationAdapter loggingAdapter,
                        IConfigurationManager configurationManager)
    if (loggingRepository == null) { throw new ArgumentNullException("loggingRepository"); }
    _loggingRepository = loggingRepository;

    if (loggingAdapter == null) { throw new ArgumentNullException("loggingAdapter"); }
    _loggingAdapter = loggingAdapter;

    if (configurationManager == null) { throw new ArgumentNullException("configurationManager"); }
    _configurationManager = configurationManager;

If you were expecting something fancy, sorry to disappoint you. The Dependency Injection part is pretty simple too.  Here is the LogDebug() method too.  Please don’t worry about the details of _loggingAdapter.ToDomainModel().  That is something I need to turn the “message” into something that the LoggingRepository can work with. 

public void LogDebug(string message)
        //are we in debug mode?
        bool configDebugMode = bool.Parse(_configurationManager.GetAppSetting("Logging.Debug"));

        if (!configDebugMode)

        //convert the message into something the logging repo can use.
        LoggingData data = _loggingAdapter.ToDomainModel(message);

        //log it!
        _loggingRepository.LogDebug(UiSystem, data);
    catch (Exception loggingException)
        // if an exception occurred during logging, capture the message that was being logged in the first place
        throw new LoggingException(loggingException) { OriginalMessage = message };

OK the code is written, so how does this make the testing easier?  Since the tough to test code is in a dependency, when I write the test, I can inject something different in.  In this case, I want to inject in a class that I can easily control and return either true or false for the Logging.Debug setting.  There are a bunch of ways to do this, I’ll use a mocking framework to help.  In this case I’m using MOQ.  Here’s most of the code from my NUnit TestFixture (I took out a bunch of extra tests for brevity.  An explanation follows.

public class LoggingServiceTests
private Mock<IEnterpriseLoggingRepository> _loggingRepository;
private Mock<ILoggingInformationAdapter> _adapter;
private Mock<IConfigurationManager> _configurationManager;
private LoggingService _loggingService;

public void Setup()
    _loggingRepository = new Mock<IEnterpriseLoggingRepository>();
    _adapter = new Mock<ILoggingInformationAdapter>();
    _configurationManager = new Mock<IConfigurationManager>();
    _loggingService = new LoggingService(_loggingRepository.Object, _adapter.Object, _configurationManager.Object);


public void LoggingDebugIsSkippedIfConfigSettingIsFalse()
    _configurationManager.Setup(cm => cm.GetAppSetting("Logging.Debug")).Returns("false");

    _loggingService.LogDebug("This is a test");

    _adapter.Verify(a => a.ToDomainModel(It.IsAny<string>()), Times.Never());
    _loggingRepository.Verify(lr => lr.LogDebug(It.IsAny<string>(), It.IsAny<LoggingData>()), Times.Never());

public void LoggingDebugIsExecutedIfConfigSettingIsTrue()
    _configurationManager.Setup(cm => cm.GetAppSetting("Logging.Debug")).Returns("true");

    _loggingService.LogDebug("This is a test");

    _adapter.Verify(a => a.ToDomainModel(It.IsAny<string>()), Times.Exactly(1));
    _loggingRepository.Verify(lr => lr.LogDebug(It.IsAny<string>(), It.IsAny<LoggingData>()), Times.Exactly(1));

If you aren’t familiar with Mocking or MOQ, you may want to read up on the topic.  I’ll try to hit the highlights.  Check out the SetUp() method.  You can see that instead of using “real” classes, I instantiate a bunch of Mocks so I can control them easily.  In the last line of the method I “inject” the mocks into the LoggingService.  Next, let’s examine the method LoggingDebugIsSkippedIfConfigSettingIsFalse().  The first line of code pretty much says when the ConfigurationManager’s GetAppSetting() method is called with the argument “Logging.Debug”, just return false.  I really like the MOQ syntax, if you are used to Lambda expressions, the MOQ stuff reads pretty easily, I think.  The mock class won’t actually look at a config file or anything.  Remember, this is a mock so there is no implementation.  With code like this, you can actually step through with the debugger and see the mocks act as you told them too!  If you look back to the actual LogDebug() method you will see that if the Logging.Debug value is false the method simply ends.  So then the last two lines of code in the test verify that the adapter’s ToDomainModel() and the logging repository’s LogDebug() method are never called at all!  That’s all there is to it.  Plus the second unit test shown here does the opposite, it makes sure that all of the code is executed if Logging.Debug is set to true.

I can assure you it took me a lot longer to write this blog post than it did to code the IConfigurationManager, WebConfigConfigurationManager, and LoggingServiceTests.  I hope you find this code helpful.

I love toys an gadgets!  They are so much fun.  Most of us geeks are gadget guys too.  I just got a GPS for my car, it’s so much fun to play with.  Toys that help me get my job done faster and better are really cool.  They help me pay for the other cool toys like GPS’s, HD Camcorders, MP3 players, etc.  One of my favorite toys for work is ReSharper, a super Visual Studio add-on that helps out in many ways.  If you aren’t using ReSharper, you should check it out.  It isn’t really a toy but it makes coding so much more enjoyable and easier, it may as well be a toy.

I’ve been using ReSharper for a pretty long time, I blogged about it over a year ago.  But in Oct 2007 I started my current job and switched to VS 2008 (it was beta at the time) so I couldn’t use ReSharper because it didn’t work with LINQ and Lambdas and all of the other cool stuff in VS 2008.  I had hoped that ReSharper 4.0 would have been ready a little sooner since the VS 2008 was officially released quite some time ago, but unfortunately I had to wait.  But now it’s here and packed full of cool enhancements.

One of the best features of ReSharper is that you don’t need to compile your code to see all of the errors — not that my code has any errors ;-).   But I wrote about that and some other old features already.  Here’s some new features:

  • ReSharper fully supports LINQ and the other language enhancements.
  • ReSharper provides great code completion/intellisense in aspx pages (source view)! 
  • Also, ReSharper will create method stubs from an ASPX page source view – so if I type OnCommand=”foo”, ReSharper can create:

protected void foo(object sender, CommandEventArgs e)
     throw new NotImplementedException();

  • With “CamelHumps”, you can abbreviate class names and method names and let ReSharper complete the word.  So if I have a method named GetAllDuplicates(), I can just Type GAD!

So far, I have only one complaint but it is really no big deal.  ReSharper wants to convert a lot of my local variables to the new variant type – var.  I use the var type in code where I want it, but I don’t believe it should be over used like this.  If a variable is a string and I know it is a string, it should be typed as such, as a string.  ReSharper offers the suggestion to convert it to a var.  But the cool thing about ReSharper is that I can tell it I’m not interested in this and it won’t bother me any more!

Believe me, there are a ton of other great features.  Just download a trial version or ReSharper 4.0 for yourself and check it out.