Question

I’ve been struggling with

Compiling transformation: An assembly with the same identity ‘xxxx’ has already been imported. Try removing one of the duplicate references.

When using T4 to generate some code at design time – with a couple of different reusable templates saved as .ttinclude files, and shared in a number of different “parent” templates.

I toggle between this, and the alternative when I remove one of the references (in my own ttinclude file) which is :

Compiling transformation: The type or namespace name ‘yyy’ could not be found (are you missing a using directive or an assembly reference?)

Going round in circles, any ideas?

Answer 1

Well, found a dirty workaround.

Would love a better solution / approach, if someone has some advice?

Posting my process as might be helpful to someone else.

---

1. Used the template directive to put my templates and include
   templates into debug mode e.g.

   <#@ template language=”C#” debug=”true” hostspecific=”true”#>

2. Popped open %TEMP% to look at the generated file(s) (most recently
   modified) just after getting the compiling transformation error.

3. Searched for the missing / doubled up assembly / class(es) used.
   Found which “included” templates both had same reference e.g.

   <#@ include file=”MyHelperTemplate.ttinclude” #>

   and :

   <#@ include file=”EF.Utility.CS.ttinclude” #>

4. Opened the include folder for the non custom include that was
   causing the conflict with my own

   ..\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\Templates\Includes

5. Opened this file up, removed its troublesome import

   <#@ import namespace=”EnvDTE” #>

6. Saved it with a new name in same folder and updated references to point to this new version e.g.

   <#@ include file=”EF.Utility.CS.Custom.ttinclude” #>

7. Put required imports into the “parent” templates, and removed from
   the “include” template. In my case this was:

   <#@ import namespace=”EnvDTE” #>

---

Now it runs fine, no problems at all, no duplicated imports, and all required assemblies referenced correctly.

Am sure there is a much more sophisticated way of dealing with T4 code reuse which negates this problem entirely. I initially tried importing my own custom assembly, with helpers for the templates, but had what seems like a classic problem with locked dlls when I then tried to build my custom class library.

Seems T4 Toolbox has a solution to this with the VolatileAssembly Custom Directive, and is popular, but looks a bit overkill for my fairly simple needs. Maybe when I have more time.