*.dll.licenses file in obj directory not created with msbuild in TeamCity

I am working on upgrading our TeamCity projects from VS2012 to VS2015 and I am running into an issue compiling our MVC application.

Old MSBuild (v4.0.30319.34209) generates a file in the obj directory called MyApplication.Web.Mvc.dll.licenses which apparently is required for building, but we have no idea what the file is actually used for.

New MSBuild (v14.0.23107.0) does not create this MyApplication.Web.Mvc.dll.licenses file, so the build fails with the following error:

CSC error CS1566: Error reading resource 'MyApplication.Web.Mvc.dll.licenses' 
-- 'Could not find file 'C:\BuildAgent\work\58ddf5f1234d8c8a\application\MyApplication\MyApplication.Web.Mvc\obj\Release\MyApplication.Web.Mvc.dll.licenses'.' 

I have been running the builds manually via cmd on the machine, and the dll.licenses file gets created whenever running the build using the old msbuild, just not the new one.

The file gets created on the development machines running VS2015, but not on the Teamcity build server. So it seems to me that something else is out of date?

After a bit more googling, I stumbled upon this thread on MSDN.

The solution suggested here is to install the Windows 10 SDK. We did this on our TeamCity build server running Windows Server 2012 R2 using the default installation options, and after a reboot, our build was working again.

Hope this helps :)

The answer "Install the Windows 10 SDK" is correct - basically. But there is an additional pitfall: There is more then one version existing of this SDKs: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

By the writing of this comment:

• July 2015 (Version 10.0.26624.0) contains .NET Framework 4.6 SDK
• Nov. 2015 (Version 10.0.10586.212) contains .NET Framework 4.6.1 SDK
• Aug. 2016 (Version 10.0.14393.0) contains .NET Framework 4.6.2 SDK

Check your VS 2015 output and what version of LC.exe is called. Then install the appropriate SDK on the build server. Don't forget to install Microsoft Build Tools 2015 too.

Note: My build is targeting .net 4.5, but above is needed to build on TeamCity with 2015 tools.

In my case TFS was using the license compiler lc.exe from the older SDK folder

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\lc.exe

instead of

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\LC.exe

This issue was solved by adding the following msbuild argument to the build definition:

/p:FrameworkOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2"

You can also get rid of these issues and make your life easier by installing visual studio on the build server and adding a visual studio build step to replace your 2015 msbuild step

I'm using Atlassian Bamboo as our build server but otherwise had exactly the same problem described here. I tried every solution in this thread but couldn't get anything to work. In the end, I used the new version of MSBuild that comes with Visual Studio 2017 and suddenly my licence dll was created correctly. In my case, the MSBuild.exe can be found at:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe

Could be helpful for someone:

After installing the Windows 10 SDK and rebooting my server, I've added /p:VisualStudioVersion=14.0 /p:TargetFrameworkVersion=v4.5.2 to my msbuild.exe. That solved it in my case.

We had the same problem when building with VisualBuild. I found a solution without installing the Win10 SDK:

In the projects properties Compile Settings we added a "Pre-build Event Command Line" like this:

pushd "%VS120COMNTOOLS%..\..\VC"
call vcvarsall.bat
popd
pushd $(ProjectDir)\"My Project"
lc /target:$(TargetFileName) /complist:licenses.licx /outdir:"..\obj\$(ConfigurationName)"
popd
popd

This command uses the (older) VS12 Tools and starts the lc compiler tool manually prior to the build of the project and compiles the licenses.licx file into the *.licenses resource file

This is a closely related but slightly different situation in that I am using Jenkins to control the build...

I had to make several changes.

1. Installed Windows 10 SDK on the build server. In my case, installing the SDK "revealed" the underlying error which is that MSBuild was not generating the *.dll.licenses file.
2. Added /tv:14.0 ( /ToolsVersion:14.0 ) to my build parameters.

> /p:Configuration=Release /p:VisualStudioVersion=14.0 /tv:14.0 /verbosity:Normal

3. Created the license file manually as a step prior to executing the MSBuild step. The following command creates the file "myproject.dll.licenses".

> cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools" > >.\lc.exe /target:MyProject.dll /complist:"C:\Program Files (x86)\Jenkins\jobs\MyProject\workspace\MyProject\licenses.licx" /i:"C:\Program Files\nsoftware\E-Payment Integrator V6 .NET Edition\lib\nsoftware.InPayWeb.dll" /outdir:"C:\Program Files (x86)\Jenkins\jobs\MyProject\workspace\MyProject\obj\Release"

In our case we use Atlassian Bamboo as build server with build agents running Windows Server 2012 (not R2). So installing the Windows 10 SDK or Visual Studio Build Tools 2017 or 2019 was not an option because it won't install on Windows Server 2012 because it does not meet system requirements.

I got it working with a pre-build event added to the VS project. (Thanks Joseph Haslinger for the idea)

The pre-build event added to the project properties calls a PowerShell script with the following command: powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -File $(ProjectDir)pre-build.ps1 $(ProjectDir) $(TargetFileName)

The command is based on the one from Jiří Činčura of tabs ↹ over ␣ ␣ ␣ spaces

> I’m setting ExecutionPolicy to Bypass in case somebody would not have it set to Unrestricted.  I’m using NoProfile as I often use plain PowerShell and loading my profile would just slow it a bit. Of course NonInteractive because, well, there is no interaction possible. And finally the File with my script file.

I added $(ProjectDir) both to call the PowerShell script and as an argument to the script, the former to make sure the script will be found on the build agent (probably not needed but for peace of mind...) the latter because LC.exe won't find the licenses.licx file and the output directory otherwise. Another argument $(TargetFileName) adds the projects target filename to use in the /target: argument of the LC.exe command.

The PowerShell script itself...

param(
	[String]$projectDir,
	[String]$targetFileName
)
if(Test-Path 'env:bamboo_agentId') {
	if(-not($projectDir)) { Throw "A value for -projectDir must be supplied!" }
    if(-not($targetFileName)) { Throw "A value for -targetFileName must be supplied!" }
	Write-Host "`r`nOn Bamboo build server, executing pre-build script"
	Write-Host "Supplied -projectDir: $projectDir"
	Import-Module NTFSSecurity

	trap {"Error found: $_"; exit 1;}
	$lcpath = Get-ChildItem2 -Path "C:\Program Files (x86)" -Filter "lc.exe" -Recurse -File | 
    Sort-Object -Property LastWriteTime -Descending | 
    Select-String -inputobject {$_.FullName} -Pattern ".*(x64|amd64).*" | 
    Select-Object -First 1

	$argTarget = "/target:$targetFileName"
	$argCompList = "/complist:$($projectDir)My Project\licenses.licx"
	$argOutdir = "/outdir:$($projectDir)obj\Release"

	Write-Host "`r`nCreating licenses file"
	Write-Host "Executing command: $lcpath $argTarget $argCompList $argOutdir"
	& $lcpath $argTarget $argCompList $argOutdir

} else {
	Write-Host "Not on Bamboo build server, skipping pre-build actions."
}

First we check for existence of the bamboo_agentId environment variable that indicates we're on the Bamboo build agent, on a local development machine it's not necessary to execute the script. When we know we are on a Bamboo build agent we check if both arguments are supplied.Then we'll search C:\Program Files (x86) for the most recent 64-bit copy of LC.exe. Following we'll create the target, complist and outdir arguments for LC.exe. And last we'll execute the LC.execommand with its arguments.