Experimental Technologies

Before I lose track of all the things I've been touching in the last 6 months, I wanted to say something on the matter of each and keep track of where I've been and where I might want to go.

Mef - twice (both plug-in UI projects)

Vs2010 Add-ins -

1.  checks all project reference to ensure none are absolute paths, one that d
2.  ExtensionsProject for my team
1. parses all project files 
2. locates .config files
3. checks for config values to be in compliance with team standards
4. checks your projects' FileCodeModel to confirm the code meets other team standards
5. will remove some project file customizations temporarily, confirm it builds in release mode, then brings up the svn commit dialog
6. allows you to store compliance information on your modules/projects on the team for easy access.
3. used a pluggable UI by importing an Action or using the default built-in messagebox if no extension is found.

FxCop/Code-check-in-policies

1. Team policy reminder/enforcers
1. warn on calls to forbidden methods
1.  GC.Collect
2. GC.AddMemoryPressure
3. Messagebox.Show
2. warn if inheriting directly from Windows.Forms or Windows.Control
3. warn if a control or form subclass constructor does not call InitializeComponent()
4. warn if a control property is not set per team standards
1. DialogBorderStyle must be fixed
5. error if you do not override certain virtual properties (legacy need from vs2005 designer bug)
6. error if you have code that raises a NotImplementedException
7. warn if you don't have hungarian notation to name controls
8. warn if fields are not private
2. Policy to ensure a project does not call a Config value or index that does not exist.

Wpf

• Mef extension  UI
• Web data scraper/exporter
• datagrid context menu

Mvc

• Mvc 2
• Lots of projects 2 at work, many more at home
• Mvc 3
• Got 2/3 through a project and had to go back to MVC2 due to changing requirements, transfer went very well.

Dependency Injection

• Unity - Nice DI framework from Microsoft.
• Ninject - Very nice lightweight DI framework
• Poor Man's - Did manual DI for the longest time, so happy to have finally switched to learning Ninject and Unity

MSBuild Custom tasks

• Wrote a task that walks all found project files under a path and determines safe build DirectedAcylicGraphs
• Detects Circular dependencies/references
• walks project files in parallel
• Wrote a task on the ordering task that will generate a properly parallelizing and multi-threading MsBuild project file.

Parallelization/threading/async

• Rx - wrote a producer consumer where a consumer can produce additional items to be consumed
• PLinq - used in Rx producer consumer to parallelize the Rx search
• Async CTP - have not used it quite yet, but did attend the 2010 PDC broadcast

ORMs -

• Linq-2-Sql - lots of personal projects
• EF4 - now that I've used it, I actually like it much better than linq to sql

Javascript cross site script without Preflight / Cross Origin Resource Sharing - also Http Access Control

• Wrote javascript that uses jQuery in a bookmarklet to allow users to save data from a page on one site cross-domain into a private secured store in a db, with group sharing options, aka Cross Origin Sharing requests

Unit Testing - 

• TypeMock - excellent for brownfield applications and no design for testability compromises

I'm sure I've forgotten some and did not get to looking at the future of where I want to go, but it's quite a nice start.

Vs2010 Code Analysis Custom Rules

I've written my first custom rules for visual studio to help me on my team with the written and unwritten rules. It was a long journey but I have the hang of it. These rules are set to run on every debug build I do and take about 8 seconds to run all.

 As I understand it custom rules ( Inherited from Microsoft.FxCop.Sdk) can also be used as code check in policies on TFS or in the build process to produce a nice xml report.

Here's the base class (.net 4.0 class library project type)

using Microsoft.FxCop.Sdk;
 
public abstract class BaseRule:BaseIntrospectionRule
{
 protected BaseRule(string ruleName)
  : base(
   ruleName,
   //typeof(BaseRule).Assembly.GetName().Name+".Rules"
   "ProjectNamespace.RuleMetadata",
   typeof(BaseRule).Assembly
   ) { }
}

This class was defined without a namespace, I believe it did not work while it was in one. It's also quite important to note that the string literal Must match your project namespace+xml filename without the .xml on it. The commented method may work as well if your xml file is called Rules.xml. This file must be set to Embedded Resource.

Rules can be set as Messages, Warnings, or Errors and show up in the standard Error List control if code analysis is turned on in your project.

The general classes of rules I have written so far include:

• Do not use method - Things like GC.AddMemoryPressure, MessageBox.Show (we use a custom dialog with styling)
• Do not inherit - We don't want anyone inheriting from Windows.Forms.Form
• Do not raise- We don't want code that has NotImplementedExceptions still present.
• UseHungarian for controls
• uses a dictionary to determine if the control has a preferred name we use on the team.
• Fields should be private
• Control Property must be set to x
• For example, in most cases we want all dialog border styles to be fixed - I check the Initialize Component method of anything that inherits from Form for the property to be set there.
• MustOverride - For legacy reasons (old Visual Studio bug they tell me) we have methods/properties that are virtual instead of abstract, and if they aren't overridden will throw a runtime exception.