rainersigwald
commented
6 years ago This workaround should force the use of a response file by temporarily overwriting the TargetFrameworkVersion. Looking at
and
that shouldn't cause any other problems; lc.exe itself doesn't seem to need to know the TargetFrameworkVersion.
Workaround
Add this to your project(s):
<Target Name="WorkaroundMSBuild2836" BeforeTargets="CompileLicxFiles">
<!-- Work around https://github.com/Microsoft/msbuild/issues/2836 by
temporarily setting TargetFrameworkVersion to a version high
high enough to cause the LC task to use a response file. -->
<PropertyGroup>
<_OriginalTargetFrameworkVersion>$(TargetFrameworkVersion)</_OriginalTargetFrameworkVersion>
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
</PropertyGroup>
</Target>
<Target Name="UndoWorkaroundMSBuild2836" AfterTargets="CompileLicxFiles">
<PropertyGroup>
<TargetFrameworkVersion>$(_OriginalTargetFrameworkVersion)</TargetFrameworkVersion>
</PropertyGroup>
</Target>
jlchavez
vijayarag
maxinfet
sallysprank
Kryptos-FR
Even when lc.exe 4.6.1 is used it will not use the response file unless the project is targeting framework 4.6.1 as well. In issue #1414: the ability to use the response file for lc.exe was limited to 4.6.1 and higher versions of lc.exe. This is being driven by the TargetFrameworkVersion which may not correlate to the actually SdkToolsPath being used.
Steps to reproduce
1.) Create a class library 2.) Set the .Net framework to 4.5 3.) Add a licensed reference and a licenses.licx 4.) Build
Expected behavior
4.6.1 lc.exe would use a response file since the use of the response file it limited by the lc.exe version and not the target framework version.
Actual behavior
4.6.1 lc.exe is used but lc.exe does not use a response file. The command line parameters then get over 32k characters and lc.exe fails and the build fails.
EDIT: added the full output from our build machine.
Environment data
Windows 10.0.16299 Visual Studio 15.5.2