14

I noticed in VS2012 that when you make a new EF Model (.edmx) that the DbContext is the default code generation and the .tt (T4 template) files are now nested underneath the .edmx file in the Solution Explorer.

Question: Is there a way to move these .tt files to another folder or project? When I try to drag and drop in Solution Explorer, it won't allow me to move the nested .tt file.

Problem details: Previously (in VS2010) I used to move the one .tt file for my POCOs into a class library called DataDefinitions and I left the other .tt file for my context in a class library called DataAccess. Now it seems like I won't be able to move these files... and separate out my assets into different layers.

In this MSDN article, if you scroll to the bottom, you can see a picture of how the .tt files are now nested... http://msdn.microsoft.com/en-us/data/jj613116

Jason Parker
  • 4,960
  • 4
  • 41
  • 52

3 Answers3

24

It is some strange new feature where templates are added as dependency to EDMX file. You can fix it by editing .csproj file for your project (you can do it in notepad or unload project in VS and edit it). You will find something like this:

<None Include="Model.tt">
  <Generator>TextTemplatingFileGenerator</Generator>
  <DependentUpon>Model.edmx</DependentUpon>
  <LastGenOutput>Model.cs</LastGenOutput>
</None>

You just need to remove DependentUpon element and the template item will become independent part of the project.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • This answer worked for me, thanks! BTW, I decided I'll just go along with what the MS Developers have in mind, and keep all my EF code in one layer. I feel it is a little messy to have data objects and data access code in the same class library, but I don't want to have to fight Visual Studio to "correct" the generated files all the time either. – Jason Parker Sep 04 '12 at 14:01
  • 2
    I hate that you are going to change your proper architecture to accomodate microsofts crappy setup. I have no idea why Microsoft is putting the entities and data access layer (contexts) in the same project. If this cannot be easily fixed yoru user interface code would have to reference your DAL direct instead of going through the BLL and this really violates proper N tier architecture in my opinion. The UI should not have direct access to the DAL without going through the BLL to ensure proper business rules are processed. – Matt Feb 19 '13 at 16:54
  • I agree with Matt. We have a distinct model layer where we move the tt files to for our POCO classes as that is a shared layer. I would keep it they way you had it and make the change. That is what I am doing. – KeyOfJ May 26 '15 at 15:59
2

I'm using EF5.x a DBContext in a separate project to the EF data model. Despite removing the DependentUpon entry in the project file as stated by Ladislav and here the classes were still appearing under my Model1.tt file.

To get round this, I had to also remove part of the entries from the project file for each of the tables:

<Compile Include="MyTableName.cs">
  <DependentUpon>Model1.tt</DependentUpon>
</Compile>

Only lines with the <DependentUpon> tags should be removed whilst the <Compile Include="..."> tags should be kept. Removing the whole entry will cause the file to disappear from the project list. The entries can be shortened to <Compile Include="MyTableName.cs"\> for brevity.

GrandMasterFlush
  • 6,269
  • 19
  • 81
  • 104
0

Instead of editing project files, I add a EF model of the same name to the project, close the solution, copied the model files from the other project, and reopen the solution. I change the namespace in the edmx properties and then recompile the model.

TonyB
  • 1