views:

181

answers:

4

I have a solution that has a few projects in it. I'd like to create some T4 templates in one of my test projects to generate tests based on code in another project. The test project has a Project Reference to the other project. The problem I have is that I don't know how to get a file path to the edmx file I need to generate code from.

Example (pretend this is an ASCII-based Solution Explorer):

MySolution.sln
-> MyTests.csproj (C:\a\b\c\)
----> GeneratedTests.tt (C:\a\b\c\GeneratedTests.tt)
-> MyDAL.csproj (C:\x\y\z\)
----> MyModel.edmx (C:\x\y\z\MyModel.edmx)

How would my GeneratedTests.tt be able to get a file path for MyModel.edmx utilizing its project reference to it?

A: 

This doesn't work that way. You'll have to reference the dll by path (you can find that out with Host.ResolvePath and use the VolatileAssembly tag from the toolbox to be able to recompile it without restarting VS ) and use reflection to work on the Model.

Femaref
Referencing the DLL by path causes the problem I'm trying to avoid. One dev box may have the project in one place while another one has it in another place. If I could assume the location, then I wouldn't have to have the template determine it - I could just hardcode it or inject it with build scripts. Working on the model is no problem - my script runs perfectly if I hardcode the path. I just need a way to dynamically determine that path. Using Host.Resolve is fine if I need the template's path - I just need to figure out the path for the MyDAL assembly's source.
Jaxidian
A: 

You can use the macros for special directories such as $(ProjectDir), $(SolutionDir) from the template, and perhaps read the .sln or .csproj file to extract the directory for the other project.

Mark H
I was hoping to avoid reading the .sln file - I guess mostly because I don't understand it all that well and I'm not sure what assumptions I can make about how reliable the path is in there. Can you give me any links on understanding this better, maybe?
Jaxidian
Actually, I don't think it's suitable. Those macros only appear to work in the T4 directives like `<#@assembly #>` and `<#@include #>`
Mark H
+2  A: 

This answer only works from within Visual Studio.

Set the "hostspecific" property of the T4 template. This gives you access to the Host property. Type cast Host to IServiceProvider to call GetService(typeof(DTE)). This lets you traverse the contents of the solution.

<#@ template language="c#" hostspecific="true"  #>
<#@ assembly name="EnvDTE" #>
<#@ import namespace="EnvDTE" #>
These are the projects in this solution:
<#
var serviceProvider = this.Host as IServiceProvider;
var dte = serviceProvider.GetService(typeof(DTE)) as DTE;
foreach (Project p in dte.Solution.Projects)
{
#>
    <#=p.Name#> at <#=p.FullName#>
<#
}
#>

Also see the example of the ITextTemplatingEngineHost interface on MSDN and T4 Architecture by Oleg Synch.

Michael L Perry
I think this will work nicely for me if it works as it sounds like it will. Could you, however, elaborate on your comment that this only works within Visual Studio? We have plans to automate our template generations since we're starting to put them all over our solution because it's beginning to become painful to manually go through and generate everything. We don't know exactly how we'll automate it, so your answer can help us plan it. Nant, PS/MSBuild, whatever - we're fine doing it however it's necessary to do it.
Jaxidian
When you set hostspecific="true", the template gains access to the Host parameter. But the down side is that the T4 host must provide it. In this case, the T4 host is assumed to be Visual Studio, which implements the DTE interface. The command line build would return null.If you want to use this method, I suggest you transform your templates within Visual Studio, not within the build. The automated build can use the generated code.
Michael L Perry