MSBuild support for T4 templates in Visual Studio 2017 RTM
Asked Answered
I

4

17

In Visual Studio 2015, I'm using the NuGet package Unofficial.Microsoft.VisualStudio.TextTemplating.14.0.0 which allows me to transform T4 templates directly from MSBuild, whenever a project is built.

In Visual Studio 2017 RTM however, this breaks the build with the following messages:

An Exception was thrown while running the transformation code. The process cannot continue. The following Exception was thrown: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=1.3.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. File name: 'Microsoft.CodeAnalysis, Version=1.3.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

This is raised by the file Unofficial.Microsoft.VisualStudio.TextTemplating.targets(396,5) which is in this package.

My guess is that the error comes from trying to use these targets from a VS 2017 build due to mismatched environments, but I don't know how to trace the exact issue. There is no updated package yet for v15 that I can see.

How can I do T4 transforms from MSBuild that will work for VS 2017? Will there be a new package from NuGet to use at some point or is this not going to be supported anymore?

Inwardly answered 8/3, 2017 at 2:42 Comment(0)
I
26

I found the right solution.

Turns out that the T4 SDK is now included as part of Visual Studio 2017 (and not part of the separate Modeling SDK as it has been in the past), BUT you have to install it via the Visual Studio extension development toolset in the VS2017 installer (Text Template Transformation feature).

Once this is installed, you can use MSBuild to transform templates by importing the relevant targets into the MSBuild project:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">15.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    <TransformOnBuild>True</TransformOnBuild>
    <TransformOutOfDateOnly>false</TransformOutOfDateOnly>
</PropertyGroup>

<!-- add AFTER import for $(MSBuildToolsPath)\Microsoft.CSharp.targets -->
<Import Project="$(VSToolsPath)\TextTemplating\Microsoft.TextTemplating.targets" />

This solved my problem and also removes the need for the separate unofficial NuGet package.

Inwardly answered 8/3, 2017 at 3:10 Comment(9)
Glad to know that you have resolved this issue. Please mark your answer which is benefit to other communities who has the same problem.Gyp
This helped me out a lot (thanks!), but I want to point out it only works with .NET Framework projects, not .NET Standard projects, at least, as-is, just FYI.Drowsy
@JorgeYanesDiez, possibly you need to <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" /> <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" /> instead of Microsoft.CSharp.targets. See my comments and OPs reply on webcache.googleusercontent.com/search?q=cache:http://…Castillo
Does anyone know how to get this working with a msbuild on a build server?Merriott
My variable $(VSToolsPath) resolves to: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0. After installing VS and the Text Template Transformation my targets file is located here however: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating Having the exact same setup wondering why my path is not resolving correctly. Any help or thoughts are greatly appreciated.Bigname
I am getting an error when using this with VS2017 15.4.4(Release). When running MSBuild I get "error MSB4018: The "TransformTemplates" task failed unexpectedly." - I have created this SO question and appreciate any help. How to Auto Increment Assembly or Assembly File Version, from MSBuildSaveall
@PeterTaylor at Jun 28 at 11:20 was right for me!!! thanks! In webcache.googleusercontent.com/search?q=cache:http://… i did not see any comment, my only problem is that CustomToolNamespace is ignoredLibel
@Bigname Did you by any chance figure this out? I'm having the same issue.Gate
I also have the same error as @GargantuanTezMaximus. My Textemplating files are located in another folder, other than what VS expects. It does NOT break however, just doesn't build. What's even stranger, generate on save works, but on build does not...Absorb
A
0

I had a similar problem. My T4 wouldn't generate on build, but would on save. This was bizarre as I didn't get an error but upon reading @Sam's answer I figured something is wrong with my VS installation. And I was right. VS 2017 15.9.4 installs in it's own install directory, but doesn't copy Tools to the VSToolsPath folder. Instead it just leaves them where they are. So, for me, the correct solution was to use this <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> <Import Project="$(VsInstallRoot)\MSBuild\Microsoft\VisualStudio\v15.0\TextTemplating\Microsoft.TextTemplating.targets" />

Absorb answered 17/12, 2018 at 12:0 Comment(0)
O
0

T4Executer does this, and you can set which templates to excecute before build or after build, or set which templates should not be run on build. VS2017-19

Orpha answered 16/5, 2019 at 6:29 Comment(0)
F
-2

I've had a similar issue where my Hosted Agent on Visual Studio Team Service did not generate the template output thus breaking my build server since it was missing the generated CS files.

The CS template output is generated just fine when building from Visual Studio 2015 on my development machine.

Looking at various solutions such as the one above it became clear to me that the more expedient fix was simply to commit the generated files to my source control system. That has the added advantage that I can code review any changes in the output and not just the template.

Feme answered 21/6, 2017 at 17:7 Comment(3)
Yes but that can easily cause problems if the generated code isn't up-to-date - for example, a developer forgets to build, or re-run T4 templates manually before committing changes, meaning the generated source is now potentially out-of-date in source control as well. Unless you can ensure that the generated source is always up-to-date with respect to its inputs, just putting it into source control is not enough. That's why being able to run templates on build is so important.Inwardly
One can easily notice that the output are not updated through code reviews. But you are right, it is just a workaround that's only convenient for very small projects I guess. Mine is a one man project with only a couple of generated CS files.Feme
Some of our generated files contains hundreds or thousands of lines - you won't spot errors in them with a human eye, even when you can see the diff!Inwardly

© 2022 - 2024 — McMap. All rights reserved.