If you are an MSDN subscriber you could be missing out on $100-200 a month Azure credits. Head over to your MSDN subscriber account to sign up in MS Azure section or Azure Activate. Azure now supports Azure Spending Limit. The feature protects from accidentally incurring charges for usage beyond the included offer amount. Use Azure with peace of mind.
Chocolatey brings apt-get like features to Windows platform. Wrote about my joyous discovery of Chocolatey back in 2012, Super Double Warmup Chocolatey To Go. Installing applications becomes simple and painless. After graduating from Chocolatey goodness head over to Boxstarter to automate creation of Windows environments as local VM or in the cloud on Azure! Chocolatey and Boxstarter support Chef too! Boxstarter can be used to automate testing of Chocolatey packages in a CI process too. Sky is the limit!
Boxstarter delivers repeatable, reboot resilient windows environment installations made easy using Chocolatey packages. When its time to repave either bare metal or virtualized instances, locally or on a remote machine, Boxstarter can automate both trivial and highly complex installations. Compatible with all Windows versions from Windows 7/2008 R2 forward.
Please pledge a donation to help improve Chocolatey and become the defacto Windows Package Manager by checking out kickstarter Chocolatey page.
We’re ready to move forward from the Chocolatey experiment to the Chocolatey experience!
New Chocolatey Features Video
Check out the following video which shows some of the soon to be released new features in the C# rewrite of Chocolatey:
Get in quick!
Donated last week when there was about 40 poeple and today there are 197 people already signed up to the Kickstarter, so be sure to get in quick so you don’t miss out of the exciting oppurtunity to help Chocolatey grow into the application package manager for Windows.
Stand-up desks. A fade contrived by creative business to generate new business and shareholder value? Or valid science and research linking sitting all day with real life threatening dangers? At first glance, my inclination is just another fade to come and go .. plan to skip this one.
STOP! Press rewind. Hit play.
The question is not, is the latest stand-up desk fade really worth the effort and money? Instead, do the health costs, dangers, i.e. mental health, cancer, death out weight the monetary setback?
We mortals are all but shadows and dust. Shadows and dust.
Ultimately, the health warnings and dangers of sitting for 10-15 hours a day finally rang true after
Read on →
Frist, absolutely a fan of AutoMapper. The other day added AutoMapper 3.2.0 to my ASP.NET MVC project to handle mapping between my EF 6.0 entities and ViewModels. Initially all was fine, created a simple straight mapping from Entity to ViewModel, meaning no ForMember or ForSourceMember. Directed a fellow developer to create Mapper Profiles for remaining Entities and ViewModels using the ForMember and ForSourceMember to handle mappings not following naming conventions. The next day he lets me know the ForMember is not working and won’t compile. My initial response, must be using wrong types. A quick code review, a few cringes and chastings for not using ReSharper I quickly realized that was not the case.
A couple hours before I committed a large refactoring of how EF was leveraged in the application. I was pretty sure my refactoring was not the issue but with any large refactoring there is a possibility. I started playing with the code, ReSharper was yelling at me no matter what I tried until I leveraged the type as a string name.
ReSharper could not poke the expression until I passed the type as a string without using an expression. This allowed me to rule out my refactoring as an issue and pointed to an issue with AutoMapper. I was flabbergasted! I found AutoMapper Issue 381 upon initial read pointed to R# and Automapper. However, I knew from my scenario this was not the case, in fact seemed to be an AutoMapper issue. After reading AutoMapper Issue 381 in it’s entirety the conclusion was AutoMapper was indeed the source of the issue and a patch release was made to resolve the behavior.
Entity Framework 6 Ninja Edition as Julie Lerman terms it boasts several improvements from it’s predecessors but one improvement that gets little press is schema support. The ability to specify default schema for database mapping instead of always defaulting to dbo is an overlooked feature. Entity Framework 5 supports non-default schema but to do so requires more code than I’d prefer. The new default schema feature in Entity Framework 6 is nice, it supports more advanced database schemas for larger applications BUT more importantly reduces code and potential for coding errors. The idea of having to remap each table to the non-default schema and then ensuring all the relationship mappings are also pointing to the proper schema name is cumbersome to say the least. All this effort in EF 5/4 was thankfully reduced to a single line of code in Entity Framework 6.
Found myself looking to wire up TinyIoC container with ASP.NET MVC today. I’d been meaning to have a look see at Tony Sneed’s Trackable Entities. After reviewing an ASP.NET MVC application attempting to leverage theses patterns I knew there was a cleaner approach. I began refactoring the implementation, then realized after reading Tony Sneed’s Trackable Entities now with Repository and Unit of Work patterns that I was rebuilding a similar implementation. Having a personal disdain for not reinventing the wheel, I decided to take a closer look at Tony’s implementation. I like his structure but feel it is lacking a service layer, and state management could be abstracted a bit more but overall liked what I was seeing. In his simple contrived example he already supported ASP.NET WebAPI but my current requirement is to support ASP.NET MVC. Tweaking the implementation was simple enough using the built in MCV scaffolding and tweaking the TinyIoC configuration. In my simple prototype I extended the TinyIoC configuration to support ASP.NET MVC too.
Today during a code review I came across an interesting compilation bug, one not expected nor anticipated. Compilation of ASP.NET MVC 4 application worked without issue, then kaboom compiler starts throwing issues Error 1818 The type or namespace name 'HttpConfiguration' could not be found on the WebApiConfig class. All references appear in good form, correct version and the WebApi Core is good. After searching for a bit, no real resolution was not worthy. For instance, just restart VS, perform clean solution and new build all works. No goods. The search continues.
Last year I stumbled accross an exciting new ASP.NET MVC Route Testing library that is still relevant. I played with it for a while as I built out my xUnit Template extensions for VS IDE. I quickly found writing route unit tests could be elegant and simple using the fluent api available. The ability to write and read a unit test like english is extremely natural and can be very benefitial for less experience programmers who may have difficulty writing unit tests. The other day I found myself introducing this library into yet another ASP.NET MVC project to provide developers a quick, simple method to unit test their routes. If you test nothing else, test your routes! You will find it very easy to introduce breaking changes as routes are added. Help yourself, prevent route pain, find the route issues prior to testing release by leveraging MVCRouteTester. MVCRouteTester supports ASP.NET MVC 4, 5 and 5.1. Do you prefer elegant, simple unit tests like this – testRoutes.ShouldMap("/").To<HomeController>(c => c.Index());?