anchor.diff:  <#=codeStringGenerator.EntityClassOpening(entity)#> <#this.Render_Interfaces(entity);#> 
   ----
   
  -The second method in the `.ttinclude` file is the one that adds the `Clone` and `Update` methods.
  +The second method in the `.ttinclude` template is the one that adds the `Clone` and `Update` methods.
   
   [app-clone]
   [source, c#]
  
positive.code: 
  [%hardbreaks]
  I was working on a project recently where we used a common pattern for versioning DB records. Extending the EF generated model classes made it easier for the team to apply the pattern consistently.
  I updated the generated code to render a generic interface if specific properties exist on the model. 2 helper methods to  (`Clone` & `Version`)
  
  [[img-project]]
  .EnttityVersion.ttinclude
  image::t4/project.png[]
  
  I added new templating content as methods exposed in a .ttinclude file.
  
  [[img-t4]]
  .Add reference to .ttinclude file
  image::t4/t4.png[]
  
  Using DB first EF and generating the model from the existing schema uses a t4 template, model1.tt by default.
  
  The .ttinclude file can be added to the top of this template and every model class that is generated will include the new content you define.
  
  [app-l]
  [source,c#]
  
negative.code:     	EmployeePartySeqID = value;
      	}
      }
  ----
  
  Customizing the generated templates is pretty simple once you get the hang of the default template. I definitely prefer a code first approach, unfortunately that wasn't an option on this project. While having to work with the `edmx` isn't my preference, it is useful to know how to fine tune the models if needs be.
  
  