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
  • 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"

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:

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 = 
        if requestedAssembly.Name <> shortName 
            printfn "redirect firing for %s" requestedAssembly.Name; Unchecked.defaultof<Assembly>
                "Redirecting assembly load of %s ,\tloaded by %s" 
                (if evArgs.RequestingAssembly = null then 
            requestedAssembly.Version <- targetVersion
            requestedAssembly.SetPublicKeyToken (AssemblyName(sprintf "x, PublicKeyToken=%s" publicKeyToken).GetPublicKeyToken())
            requestedAssembly.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
            Assembly.Load (requestedAssembly)
// sample usage
RedirectAssembly "FSharp.Core" (Version("")) "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!

Monday, June 30, 2014

Why am I so enthusiastic about F#?

I'm suddenly really passionate about F#. This is new as of ~3 weeks ago.