Tuesday, February 9, 2016

Requested Post: Dev machine setup

How do I setup a machine to develop on?

Everywhere I've gone, one of my first steps is to document every single thing I'm told to do to setup the machine for development. Not a single one of the shops where did I this, was it appreciated or possibly even used as far as I can tell. Even in the many that had badly outdated instructions for new developers, I updated them to no avail or interest.

So here's my generic procedure for a machine (mostly independent of target platform/ui)
  1. Ask about getting a 2nd monitor if there isn't one.
  2. evaluate provided keyboard/mouse
  3. evaluate if using a git layer over top of the solution would be helpful
    1. branching in git is cake
    2. branching in TFS is very painful
  4. document and do all solution/job/domain specific setup
    1. ask around about pain points in setup
  5. ensure the work solution actually runs
  6. installs
    1. setup Chrome (or Firefox)
    2. install git or git-extensions (even if the shop doesn't use git)
    3. Linqpad 
      1. download (4 and 5)
      2. register it 
      3. set it to point to the script repository created in 2
    4. SublimeText
    5. Telerik JustDecompile
    6. Windows Grep - I am considering trying out this one
  7. pull down my script repository (this has all my most reusable/interesting scripting code)
  8. write some scripting code 
    1. to help verify and/or do step 3.
    2. to help with any manual work done in switching contexts (ie. Dev/QA/Prod debugging)
  9. Consider (but not necessarily do, creating a git repo over my user profile folder)
    1. this lets me watch changes to those folders for important settings or files that I might want to keep
    2. also allows settings to roam between machines/domains
  10. Run VS code metrics analysis of work solution(s) - 
    1. ask for approval to clean the methods with any of the following criteria:
      1. over 30 cyclomatic complexity
      2. under 30 maintainability
  11. evaluate build/CI process
  12. evaluate deploy process

Additional very wise steps I need to start doing:
  • Install sonar 
    • install the C# plugin
    • test run current/latest code
      • customize violation rules and re-run
      • document metrics (lines of code, number of projects, violations)
    • setup a build process that would iterate from the beginning of solution all check-ins for code trending

VS Extensions to install:
  • VsVim
  • Web Essentials
  • Visual F# Power Tools

Other tools I might install depending on platform/ui type:

Tuesday, November 17, 2015

T4 Generates my business objects for me revisited with F#

A long time ago I wrote an article about the code I was using in T4 Generates my business objects for me. Today I've rewritten the idea with F# as the target. F# projects don't support T4 so I used a C# project to generate F# code into an F# project. The parts of the generated code
  • A readonly interface
  • A read-write interface
  • An F# record type
  • An F# module for mapping code methods (with Statically Resolved Type Parameter support aka Duck Typing or Structural Typing)
  • An F# class with INotifyPropertyChanged for WPF consumption
Benefits
  • Implementing interfaces is not allowed to be implicit so I've automated that headache.
  • INotifyPropertyChanged desires magic strings (exception in the lovely new C# 6 nameof operator) so automation makes sure the strings are correct as of the last time T4 was run
  • If I pass around the read-only interface, I don't care how far down the rabbit hole of that object goes, it's immutable, no one is modifying it
  • If I pass around the read-write interface, all the consuming methods can be ignorant of concrete types
  • I'm generating Metadata from the db into the comments on the properties (tons of untapped potential here)

View the generated code and generator t4

- Generator and generated code from new T4 to F#

Things I want to add:

  • foreign key information to the auto-generated property comments
  • consider having the Read-Write interface implement the Read-Only interface
  • figure out how to update Microsoft's Type Providers to have them implement my interfaces.
  • add an option for generating Sql Sprocs that work against these types

Friday, February 20, 2015

Get Code Coverage from VS without writing automated tests

Create a batch file somewhere in your system as such:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools\vsinstr.exe" -coverage "%1"
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools\VSPerfCmd.exe" /start:coverage /output:run.coverage
start "%1" /wait "%1"
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Performance Tools\VSPerfCmd.exe" /shutdown
notepad "run.coverage"
echo "%1"
echo "%2"

pause
Create an External Tool Entry in your Visual Studio Tools Menu.
  • Title: RunCovered

  • Command: c:\projects\config\batches\RunCovered.bat
  • Arguments
    $(TargetName)$(TargetExt) $(BinDir)
  • Initial Directory:
    $(BinDir)

replace the command with wherever your new shiny batch file lives.

Then in trigger that External Tool on the Tools Menu.

It will launch your app, and you can then click around or do whatever is needed to activate parts of your application, and the results will be saved into the same directory as your executable file as run.coverage. Open this file in your already open Visual Studio instance, or drag and drop the file from explorer into VS.

There you have your App's coverage metrics for that run.

Thursday, November 13, 2014

Binding redirects at runtime

Hopfully the C# audience can read this F#, but this is how you would do it =)
// https://dotnetfiddle.net/UnS2vU
printfn "starting up"
open System
open System.Reflection

let RedirectAssembly shortName (targetVersion : Version) publicKeyToken = 
    let rec onResolveEvent = new ResolveEventHandler( fun sender evArgs ->
        let requestedAssembly = 
            AssemblyName(evArgs.Name)
        if requestedAssembly.Name <> shortName 
        then 
            printfn "redirect firing for %s" requestedAssembly.Name; Unchecked.defaultof<Assembly>
        else 
            printfn 
                "Redirecting assembly load of %s ,\tloaded by %s" 
                evArgs.Name 
                (if evArgs.RequestingAssembly = null then 
                     "(unknown)"
                 else 
                     evArgs.RequestingAssembly.FullName)
            requestedAssembly.Version <- targetVersion
            requestedAssembly.SetPublicKeyToken (AssemblyName(sprintf "x, PublicKeyToken=%s" publicKeyToken).GetPublicKeyToken())
            requestedAssembly.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
            AppDomain.CurrentDomain.remove_AssemblyResolve(onResolveEvent)
            Assembly.Load (requestedAssembly)
            )
    AppDomain.CurrentDomain.add_AssemblyResolve(onResolveEvent)
    
// sample usage
RedirectAssembly "FSharp.Core" (Version("4.3.1.0")) "b03f5f7f11d50a3a"

Thursday, October 9, 2014

Using a Git layer on top of TFS

Not having git bugs me. Working with any other source control system takes away some of my power.

With a git layer over whatever other source control system is required for the team:

  • I can check-in or revert individual lines of code in a file. 
  • I can create a branch for local modifications that should never be checked into the team source control.
  • I can create mini-commits that don't have to be logged as individual commits in the team source (for teams that prefer one large change-set)
    • I can create my own personal historical record of change save-points and notes/comments
  • I can select which lines of a file should go into a check-in without shelving the entire change.

How to:

Create a junction or hardlink to the folder that contains your code. This junction must not be in the tree that your tfs workspace mapping sees. If it is, Visual Studio will then, forcefully and persistently, use git as your source control and refuse to talk to TFS about your changes.

So I have all my code under c:\development\foo

  1.  I change working directory to c:\projects\bar and mklink /h /j foobar c:\development\foo
  2. git init
  3. Always point visual studio at the legacy folder c:\development\foo.
  4. Always point your git tool(s) at c:\projects\bar
  5. profit!