Why did I ever switch to MSTEST?

Ran into a wicked problem with MSTEST today, resurrected an old project went to run the tests - and boom - nothing appeared to run - very similar to the "cylon" symptom I talked about in 2010. Eventually ran into this wonderment which gave me at least an indication of what was happening (and only 2 days after latest VS2012 update too...hmmm)

So I waded through the following links to try and discover what was happening...

Came across a number of Open, Closed and Unreproducable issues from Microsoft Connect. Then finally a Resharper related post seemed like it was worth trying out (super shoutout to JetBrains forums). 

So I ended up switching from MSTEST to NUNIT and all tests ran. (Big Surprise)
I am reminded of an old song going back to NUNIT...

So how to switch in between NUNIT/MSTEST quickly - use a build directive - NUNIT.
Add the following code to the the head of your test files (or possibly a partial class, or just a plain base-class that all test files inherit from). Then you are basically remapping the MSTEST attributes to the appropriate NUNIT ones. You are rocking with NUNIT - thank you Resharper & StackOverflow. 
(Note: There is no TestContext available in NUNIT so if you rely heavily on that you will have to do something else)


#if NUNIT
using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using ClassCleanup = NUnit.Framework.TestFixtureTearDownAttribute;
using ClassInitialize = NUnit.Framework.TestFixtureSetUpAttribute;
#else
using Microsoft.VisualStudio.TestTools.UnitTesting;
#endif

StackOverflow

http://osherove.com/blog/2010/3/5/nunit-vs-mstest-nunit-wins-for-unit-testing.html

OpenStack

Entice Me
Opening my eyes and looking around to see what is available. Willing to relocate for the right opportunity or area (I like the coast). I bring a great deal to the table and I'm kinda fun to work with...let's see what we can do for each other.

Curriculum Vitae/Resume
Zerply-Profile 

Ninject + MVC 4

Nothing earth shattering here - but was wrestling with current WCF services and trying to leverage the delicious newness of the WebApi with Ninject 3.0. A bit of pain and a few tears later...

   1:  public class MvcApplication : NinjectHttpApplication

   2:      {

   3:          /// <summary>

   4:          /// Called when [application started].

   5:          /// </summary>

   6:          protected override void OnApplicationStarted()

   7:          {

   8:              base.OnApplicationStarted();

   9:   

  10:              AreaRegistration.RegisterAllAreas();

  11:              FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);

  12:              RouteConfig.RegisterRoutes(RouteTable.Routes);

  13:              BundleConfig.RegisterBundles(BundleTable.Bundles);

  14:          }

  15:   

  16:          /// <summary>

  17:          /// Creates the kernel.

  18:          /// </summary>

  19:          /// <returns>IoC container object</returns>

  20:          protected override IKernel CreateKernel()

  21:          {

  22:              IKernel kernel = new StandardKernel(new NinjectSettings { LoadExtensions = true });

  23:   

  24:              // add AutoMapper to the core -> needs to be first; as services will use this.

  25:              kernel.Bind<ITypeMapFactory>().To<TypeMapFactory>();

  26:              kernel.Bind<ConfigurationStore>().ToConstant(new ConfigurationStore(kernel.Get<ITypeMapFactory>(), MapperRegistry.AllMappers())).InSingletonScope();

  27:              kernel.Bind<IConfiguration>().ToMethod(c => c.Kernel.Get<ConfigurationStore>());

  28:              kernel.Bind<IConfigurationProvider>().ToMethod(c => c.Kernel.Get<ConfigurationStore>());

  29:              kernel.Bind<IMappingEngine>().To<MappingEngine>();

  30:   

  31:              kernel.Bind(

  32:                  x =>

  33:                  x.FromAssembliesMatching(new[]

  34:                      {

  35:                          "*.Service.dll", "*.Service.Mvc.dll", "*.Service.Data.dll"

  36:                      }).SelectAllClasses().BindAllInterfaces());

  37:              kernel.Bind<ServiceHost>().To<NinjectServiceHost>();

  38:                          

  39:              // not intended to be used when deriving from NinjectHttpApplication <sigh>

  40:              ////kernel.Bind<IHttpModule>().To<HttpApplicationInitializationHttpModule>();

  41:              ServiceLocator.SetLocatorProvider(() => new NinjectServiceLocator(kernel));

  42:              var locator = new NinjectServiceLocator(kernel);

  43:              ServiceLocator.SetLocatorProvider(() => locator);

  44:              return kernel;

  45:          }

  46:      }

Well - its been awhile. I've been mostly tweeting and/or G+ Anyway, new look. New trends. Job Trends 2012

SheepAOP::SheepAspect

Another aspect orientated framework -SheepAOP now SheepAspect by Hendry Luk.

I'm glad to see someone else in this space. I'm also happy to see that it is derived with an IoC container in mind. Seems straightforward enough - could have some real promise. I will keep this framework in mind for any future projects.

http://sheepaspect.codeplex.com/

http://hendryluk.wordpress.com/2011/05/08/sheepaop-part-1-getting-started/

Building Silverlight Toolkit (again)

Paths I find most useful - especially when compiling SL Toolkit 4.0 from source (on an x64 machine). For whatever collection of reasons (IDE resolving assemblies, poor source-code structure - whatever) I usually end up wasting x hours of my life (usually on the weekend) trying to resolve these things. The Design solutions seem to be the worst offenders. 

The saddest comment I saw posted on the message boards (from a moderator no-less) was along the lines of - "Well, just don't build those projects." 


The sound you just heard was me throwing up, just a little bit...

Anyway - some of magical GAC paths....


(Useful for the little things - like System.Windows and System.Windows.Controls)
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\

(For the Blendability aspects - notice the 10.0 - instead of the 9.0; which is generally how the IDE(?) resolves it)
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\

(For the all the references that look to C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Libraries)
C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\

I love what SL has done to the CLR - I really do! In general, the IDE is a pleasure to work with but that said....

• My best advice is stop using the GAC! Use the shared binary folder (only if source is unavailable or overly prohibitive) for the shared dependencies consistently and across the board.
• Where's the automated batch build? If Code-Plex = MS <3 OS  at least follow some basic principals... 
• The few tests that there are suffer the same path dependency problems as the rest of the project. (No automated build - or automated tests?) 
• Developers are your audience - and we are relentless when we don't have a sense of assurance with the project we are working with. It needs to be clear, well-organized and predictable. I've personally abandoned Open Source projects for less than this.
• Source-tree restructuring - make-over is well overdue. What a bloody-mess! (Take a look at the majority of projects at github if you want to see how its done.)
• All this being said - I want SL to succeed; but MS needs to want their developer base to succeed. We're paying attention...are you?

Every minute (wasted) compiling/resolving references is a minute NOT spent writing those oodles of apps required to catch up to Apple, oh - no wait - it Android now.
 
Assimilated the new Android SDK yesterday -> was out for about 15 minutes as the emulator changed paths and Eclipse required an update. Just saying...