Virtual-environments: C++/CLI build started to fail with LINK : fatal error LNK1104: cannot open file 'MSCOREE.lib'

[dimiboi]

Describe the bug
A C++/CLI library build fails with the following error:

LINK : fatal error LNK1104: cannot open file 'MSCOREE.lib'

Last time the very same code was successfully built with the very same pipeline on Jan 12. Now the pipeline fails every time.

Area for Triage: C/C++

Question, Bug, or Feature?: Bug

Virtual environments affected

• [ ] macOS 10.15
• [ ] Ubuntu 16.04 LTS
• [ ] Ubuntu 18.04 LTS
• [ ] Windows Server 2016 R2
• [x] Windows Server 2019

Expected behavior
Build to succeed.

Actual behavior
Build fails with LINK : fatal error LNK1104: cannot open file 'MSCOREE.lib' error.

[jiria]

We are seeing the same issue, I have triaged the breaking change to 20200102.1 image. 20191209.1 was ok.

Successfull run:

Agent name: 'Hosted Agent' 
Agent machine name: 'fv-az776' 
Current agent version: '2.163.1' 
Current image version: '20191209.1' 
Agent running as: 'VssAdministrator' 
Prepare build directory. 
Set build variables. 
Download all required tasks. 
Downloading task: NuGetToolInstaller (1.161.0) 
Downloading task: NuGetCommand (2.161.1) 
Downloading task: VSBuild (1.161.2) 
Downloading task: AzureKeyVault (1.155.8) 
Downloading task: CmdLine (2.151.2) 
Downloading task: VSTest (2.162.7) 
Downloading task: ComponentGovernanceComponentDetection (0.21217.1) 
Start tracking orphan processes. 

Failure run:

Agent name: 'Hosted Agent' 
Agent machine name: 'fv-az677' 
Current agent version: '2.163.1' 
Current image version: '20200102.1' 
Agent running as: 'VssAdministrator' 
Prepare build directory. 
Set build variables. 
Download all required tasks. 
Downloading task: NuGetToolInstaller (1.161.0) 
Downloading task: NuGetCommand (2.161.1) 
Downloading task: VSBuild (1.161.2) 
Downloading task: AzureKeyVault (1.155.8) 
Downloading task: CmdLine (2.151.2) 
Downloading task: VSTest (2.162.7) 
Downloading task: ComponentGovernanceComponentDetection (0.21217.1) 
Start tracking orphan processes. 

[dimiboi]

@jiria, I have observed the same.

[jiria]

Hello,

This is blocking our CI pipeline. Can you please provide ETA for resolution?

Regards,
Jiri

[miketimofeev]

@dimiboi @jiria thanks for reporting this issue. Could you please provide sample code to reproduce the problem?

[dimiboi]

@miketimofeev, here's a sample project: https://github.com/dimiboi/cmake-cppcli-poc and a failing pipeline, which used to pass. I am using a similar setup in the actual project: CMake + native library + C++/CLI wrapper.

[wireznak]

So far, we know the following from an investigation of a similar report:

There appears to be an issue with the Windows 10 SDK version 10.0.17763.0 installed on the build agents. This may be an issue with 10.0.17763.0 generally, 10.0.17763.0 in combination with another version installed simultaneously, or only with the specific installation on the build agents; either way, attempting to use Windows 10 SDK 10.0.17763.0 produces failed builds on the agents when C++/CLI is involved.

When we changed a test project that was producing similar build failures (failing to find MSCOREE.lib in the linking phase) to use the latest version of the Windows 10 SDK on agent version 20200116.1, it detected version 10.0.18362.0 instead and the build succeeded. Therefore, if you are able to control which version of the Windows 10 SDK your code links against, please choose "Use Latest" or at least avoid version 10.0.17763.0 for now.

We'll work on finding a better explanation and solution in the meantime.

[dsame]

The libraries have been moved from C:\Program Files (x86)\WindowsSDKs to C:\Program Files (x86)\Windows Kits\NETFXSDK

namely in 20200102.1 image they are:

C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\Lib\um\arm\mscoree.lib
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\Lib\um\x64\mscoree.lib
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\Lib\um\x86\mscoree.lib

Is it possible to make modifications in the makefiles accordingly ?

[dimiboi]

Explicitly setting the SDK version to 10.0.18362.0 by passing -DCMAKE_SYSTEM_VERSION="10.0.18362.0" argument did work and the pipeline passed. The previous Windows 10 SDK installation is indeed broken.

[jiria]

For us, switching to 10.0.18362.0 got us unblocked. Thank you for the turn around.

[AlenaSviridenko]

Hi @dimiboi !
I am closing this issue but if this error is still actual for you, please, feel free to open new ticket.
Thanks!