50

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?

gwin003
  • 6,905
  • 5
  • 34
  • 55
  • So presumably you have a [.licx file in one of your projects and some licensed components](http://stackoverflow.com/questions/5628969/how-licenses-licx-file-is-used)? – Nanhydrin Sep 04 '15 at 08:38
  • @Nanhydrin Yes I found that to be the culprit. I still have an issue where Visual Studio 2015 will not build the .licenses file. I was planning on posting my solution whenever I get it figured out. – gwin003 Sep 04 '15 at 12:38
  • 2
    Edit: I meant MSBuild v14 doesn't create the .licenses file. – gwin003 Sep 04 '15 at 13:26
  • Have you turned on detailed build output and had a look at the full build output for the project with the .licx file? – Nanhydrin Sep 04 '15 at 13:40
  • 1
    @Nanhydrin Yes I just did, and the output is different on the server than what it is on my machine. On the server, it is just outputting the information as if you invoked `lc.exe` with no `.licx` file present. This is also present: `Task attempted to find "LC.exe" using the SdkToolsPath value "". Make sure the SdkToolsPath is set to the correct value and the tool exists in the correct processor specific location below it.` – gwin003 Sep 04 '15 at 13:58
  • Have you got any versions of the Windows SDK installed on either? What version of .NET is your MVC app? – Nanhydrin Sep 04 '15 at 14:08
  • The .NET version is 4.5. It looks like in `C:\Program Files (x86)\Microsoft SDKs\Windows` I have `v6.0A`, `v7.0A` and `v8.0A`. – gwin003 Sep 04 '15 at 14:13
  • OK, so looking at my own machine I have `Windows\v8.1A\bin\NETFX 4.5.1 Tools` presumably this is the one you'd need to run lc.exe for a 4.5 project. Is this the machine with Visual Studio 2015 on it, or have you manually installed MSBuild 14 on it? Can you set up an SdkToolsPath to point to one of these NETFX folders and see if that changes things? – Nanhydrin Sep 04 '15 at 14:27
  • This machine does not have VS2015, just MSBuild 14 tools. I'm not sure how to set the SdkToolsPath, if its in the csproj file or whatnot? – gwin003 Sep 04 '15 at 15:23
  • System environment variable I think. – Nanhydrin Sep 04 '15 at 15:24
  • Hmmm doesn't look to be in there in either machine. – gwin003 Sep 04 '15 at 19:56
  • Did the sole answer work for you? If so, could you accept it? – Jerther Jan 05 '16 at 16:17
  • I've seen reference to setting the SdkToolsPath or Sdk40ToolsPath as an environment variable...I did but it had no effect. I did _not_ want to install Visual Studio on my build server! What worked for me? http://stackoverflow.com/a/40896530/12919 – Timothy Lee Russell Nov 30 '16 at 19:37

8 Answers8

38

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 :)

Njål Nordmark
  • 586
  • 4
  • 6
  • 2
    This helped me a lot. We moved to MsBuild 2015 and our licenses.licx file was no longer compiled to a *.licences file in the /obj/ folder. Installing the Win 10 SDK fixed it as you suggested – Lodewijk Sep 24 '15 at 14:14
  • 6
    Thank you!! Solved my problem. Come on, MS. Get your crap together!! I shouldn't have to install multiple packages and copy folders from my dev system to get CSC to work. – Scottie Oct 09 '15 at 17:35
  • I had to Install MS Build Tools 2015 cause MSBuild is now a Stand-Alone Install package. – JudgeProphet Feb 15 '16 at 15:45
  • 6
    I have found that you actually don't have to install the entire Windows10 SDK (2.5Gb), to get this error to go away it is enough to only choose the .Net Framework 4.6 Software Development Kit (~50Mb) when you run the Win10 SDK installer. – July.Tech Apr 29 '16 at 21:24
  • 1
    For some reason, MSBuild refused to create the *.dll.licenses file in my case, even after installing the Windows 10 SDK. I ended up having to call lc.exe myself and generate the license file as one of my build steps. – Timothy Lee Russell Nov 30 '16 at 19:26
10

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.

  • All three were needed to build to .Net 4.5? – IronSean Feb 25 '17 at 21:24
  • 2
    Here is the link to the archives pages for the Windows 10 SDK's mentioned above. Find those versions and when you install them unselect everything except the .NET Framework 4.6.xxx SDK. https://developer.microsoft.com/en-us/windows/downloads/sdk-archive – Colin Pear Feb 28 '17 at 16:18
  • 1
    When changing my TeamCity to use the 2015 instead of the 2013 version of MSBuild, I needed the July 2015 / 4.6 SDK; the Aug 2016 / 4.6.2 SDK did NOT resolve the missing .licenses file issue for me. (Thanks for this, Alois!) – Jon Schneider Aug 16 '17 at 18:05
9

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

afuzzyllama
  • 6,275
  • 5
  • 42
  • 61
Orlando
  • 91
  • 1
  • 1
  • 3
    Similar solution helped me. /p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" – Der_Meister Oct 19 '17 at 07:19
7

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

Tom
  • 549
  • 1
  • 4
  • 13
  • 2
    This solved the problem for me as well, although the path was slightly different:C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe – Mike W. May 30 '17 at 14:40
  • I had a path similar to @MichaelWires above, but this also solved my issue. – Brandon Barkley Nov 27 '17 at 20:36
  • 1
    They changed the installation paths of msbuild with v15. Tom most likely used the stand-alone Visual Studio 2017 build tools, which puts msbuild into a sku agnostic directory. – TheBuildGuy Feb 14 '18 at 23:31
1

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.

user1613512
  • 3,280
  • 6
  • 22
  • 31
1

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

  • Thanks for this @Josef -- it sent me down the right path. I had to manually create the *.dll.licenses myself as a build step. (Although I was able to use the most recent version of the lc.exe utility.) – Timothy Lee Russell Nov 30 '16 at 19:30
0

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

  1. 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"

Community
  • 1
  • 1
Timothy Lee Russell
  • 3,673
  • 1
  • 34
  • 42
0

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.

Thrasher
  • 43
  • 7