为什么使用ttinclude而不是编译程序集？

我一直在编写一个程序集来简化我的大部分POCO类型代。我有一个核心程序集，其中包含多个tt文件并用于生成代码。为什么使用ttinclude而不是编译程序集？

我之所以这样做是因为无论我尝试使用哪种扩展（Devart T4，Tangible-T4或Visual T4），都不如Visual Studio C＃编辑器提供的智能感知和支持，所以编写代码生成在纯粹的C＃中改进了很多经验。

我面临的最大问题是实体框架助手类（例如Accessibility,CodeGenerationTools,MetadataTools等）在ttinclude文件中定义而不是程序集;目前我不得不重写很多这些类提供的功能，以便它可以在程序集中使用。

我的问题是，为什么实体框架团队决定使用ttinclude文件而不是一些编译程序集？使用组件方法似乎在更多情况下会更加可用，并且仍然不会影响T4代码生成（而不是使用<#@ include #>它将是<#@ assembly #>）。

我想知道什么是最好的方法来解决这个问题，我已经打算运行EF.Utility.CS.ttinclude到TextTransform.exe，然后采取生成的C＃和编译这，这将是明智的？

感谢，卢克

更新

目前我所做的就是添加EF.Utility.CS.ttinclude到我的项目，对文件设置自定义工具TextTemplatingFilePreprocessor。这将生成包含类的代码。然后我复制了这个cs文件，删除了负责写入输出的类（它有方法TransformText()）并编译成一个程序集。我现在可以在我的程序集中使用实体框架实用程序类。

来源

2012-01-25 Lukazoid

使用ttinclude而不是程序集的原因与使用T4代替自定义工具来生成类（这是您实际正在做的事以及以前使用的大多数设计器）相同。 T4和ttinclude可以更改。您可以复制ttinclude并创建小的更改，并将其包含在每个项目基本的主要T4中。

Btw。你知道有成千上万的程序员可以在没有任何智能感知的情况下编写代码;）对智能感知的更大支持并不是放弃使用T4模板的理由。

来源

2012-01-25 10:14:28

我从来没有说过我不能在没有智能感知的情况下编写代码，但我确实了解intellisense（以及代码重构，参考等）所提供的好处。我仍然部分使用T4模板，我的程序集定义了从TextTransformation派生的类。不得不根据情况更改ttinclude文件表明，如果我们开始复制和更改每种情况下的代码，就像说多态不存在一样，那么包含的类没有设计或实现得不够好。 – Lukazoid

在一个ttinclude文件中有很多类似乎违背了.NET每个文件一个类的哲学，如果我们将每个类拆分成它自己的ttinclude文件，那么我们有很多'<＃@ include＃>'在最佳。如果试图重新使用代码（即必须使用相对路径可能会变得太长，或者不得不编辑注册表才能使其运行），这尤其糟糕。另一个问题是与包含的整个钻石问题，FileA包括FileB和FileC，FileB和FileC都包含FileD，现在文本转换失败，因为相同的类（来自FileD）被声明两次。 – Lukazoid

我认为使用包含共享类的程序集更加可取。（我很抱歉，如果我似乎在咆哮，只是试图解释我的推理） – Lukazoid

为什么使用ttinclude而不是编译程序集？

回答

相关问题