microsoft
/
WindowsAppSDK
зеркало из https://github.com/microsoft/WindowsAppSDK.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
WindowsAppSDK/HybridCRT.props

35 строки
2.3 KiB
Plaintext
Исходник Обычный вид История

Commonize Hybrid CRT support (#1026) * Move Hybrid CRT support out of individual project files up to the project level as a whole * Remove unnecesasry Store-app-ness that fails the Hybrid CRT support * Stop enabling DebugLibraries to avoid bringing in debug VC CRT DLL dependencies (violating the Hybrid CRT rules) * Add DesktopCompatible to MrtCoreManagedTest for future reference - it doesn't hurt, but it doesn't help (at least, not this issue). Also added Win32Proj keyword to M.AM.Resources project. We now have 1 root issue * Removed MrtCoreManagedTest from the build due to a fundamental incompatibility (ut's a Universal Windows project referencing Microsoft.ApplicationModel.Resources (the WinRT dll) which isn't, and VS doesn't like crossing streams. Even worse, VS and msbuild produce different results!). * Revert "Removed MrtCoreManagedTest from the build due to a fundamental incompatibility (ut's a Universal Windows project referencing Microsoft.ApplicationModel.Resources (the WinRT dll) which isn't, and VS doesn't like crossing streams. Even worse, VS and msbuild produce different results!)." This reverts commit 6f4b23dd1057ee2d0c2c0684aedcd3797adfbaa3. * Doing things to workaround MrtCoreManagedTest is a Univesal Windows project. Epic Failure. Because it's a Universal Windows project MSTest is creating $(OutDir)AppX subdir and copying files ***it knows about*** to the subdir. This brutal hack fails because File.Exists() for files in the parent directory fails, and that's because the last var pc = ... tries to access the AppX directory's parent ***and fails because Access Denied***. Previously doing the copy in the .csproj fails because the AppX directory doesn't necesarily exist before the test runs, and MD $(OutDir)AppX before copying files is pointless because MSTest is deleting all the files (if any) in the AppX directory when the test starts. So dead end upon dead end. Only way is to find a way to bench the Universal Windows .props logic to understand the files it doesn't want to allow through the ...Transitive... copy rules. Or just rewrite the project as a non-Universal Windows project. Or rewrite the test using TAEF instead of MSTest. Or... drink heavily. Hunting up Scott tomorrow hoping he has an idea * Hah! Thank you ScottJ! ReferenceCopyLocalPaths does the right thing, copying the needed DLLs into $(OutDir) *and* $(OutDir)AppX and the tests now find the dll and pass * Remove debugging hackery
2021-08-17 23:17:35 +03:00
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See LICENSE in the project root for license information. -->
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup Condition="'$(Configuration)'=='Debug'">
<ClCompile>
<!-- We use MultiThreadedDebug, rather than MultiThreadedDebugDLL, to avoid DLL dependencies on VCRUNTIME140d.dll and MSVCP140d.dll. -->
<RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
</ClCompile>
<Link>
<!-- Link statically against the runtime and STL, but link dynamically against the CRT by ignoring the static CRT
lib and instead linking against the Universal CRT DLL import library. This "hybrid" linking mechanism is
supported according to the CRT maintainer. Dynamic linking against the CRT makes the binaries a bit smaller
than they would otherwise be if the CRT, runtime, and STL were all statically linked in. -->
<IgnoreSpecificDefaultLibraries>%(IgnoreSpecificDefaultLibraries);libucrtd.lib</IgnoreSpecificDefaultLibraries>
<AdditionalOptions>%(AdditionalOptions) /defaultlib:ucrtd.lib</AdditionalOptions>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)'=='Release'">
<ClCompile>
<!-- We use MultiThreaded, rather than MultiThreadedDLL, to avoid DLL dependencies on VCRUNTIME140.dll and MSVCP140.dll. -->
<RuntimeLibrary>MultiThreaded</RuntimeLibrary>
</ClCompile>
<Link>
<!-- Link statically against the runtime and STL, but link dynamically against the CRT by ignoring the static CRT
lib and instead linking against the Universal CRT DLL import library. This "hybrid" linking mechanism is
supported according to the CRT maintainer. Dynamic linking against the CRT makes the binaries a bit smaller
than they would otherwise be if the CRT, runtime, and STL were all statically linked in. -->
<IgnoreSpecificDefaultLibraries>%(IgnoreSpecificDefaultLibraries);libucrt.lib</IgnoreSpecificDefaultLibraries>
<AdditionalOptions>%(AdditionalOptions) /defaultlib:ucrt.lib</AdditionalOptions>
</Link>
</ItemDefinitionGroup>
</Project>