As the title says..
Is there a plan to also add ARM and ARM64 libraries?

@dfields-msft

We should do a more robust search to try and locate dlls in a unity package folder. Right now it appears we only look for dlls in the Unity project's assets folder.

This causes dlls to fail to load when they are available to the project. This change will be needed if VCRTFowarders is distributed through a unity package.

As these DLLs have no code on their own, I think the standard CRT initialization and termination routines aren't needed. The gains on performance and file size will be negligible but I believe this project configuration change may keep things tidier. For example, the api-ms-win-crt-*.dll libraries from the Universal CRT (for Windows versions before Windows 10) are pure forwarders to Ucrtbase.dll and they haven't an entry point.

There is a dllmain.cpp file at 140_release\vcrt_fwd_x64_release\msvcp140_app, but it isn't even referenced by any project file.

The call here fails for me in a Mac Unity Editor (2019.2.*):

It seems that these initializer c# scripts should only run in UNITY_EDITOR_WIN environments. Wrapping the InitVCRTForwarders.cs file content in UNITY_EDITOR_WIN ifdefs unblocked iOS builds for me. Note: this affects all other projects that follow this model of calling LoadLibraryExW in the Unity editor, such as Microsoft.MixedReality.QR

When this error occurs, it may not necessarily result in a formal Unity build failure. In my case, it does prevent other prebuild/postbuild scripts from running. This causes things like Azure Spatial Anchors that copies Podfiles into generate iOS project folders to fail, causing the iOS build to fail in xcode.

I'm using this package to supplement a native binary built for UWP so it can be used in non-UWP projects as well. This works fine if the non-UWP project is also native, but when I consume this package (directly or indirectly) from a managed project, the binaries do not get copied to the output directory; I have to add manual build steps to do this. Then everything works great! Can this package be updated to make this happen auto-magically?

Our team's product is an unpackaged Win32 desktop application that already includes the necessary VCRT DLLs in the EXE's local installation directory, so that we do not have to rely on users already having the corresponding VC++ Redistributable Package installed on their machine.

We are introducing a dependency that requires the use of VCRT forwarders, and we are wondering: Is it guaranteed that these forwarders will try pointing to the VCRT DLLs already included in our application's working directory first before searching for other locations? We are concerned about cases where these forwarders might throw an error if they cannot find the DLLs from a Redistributable package despite the fact that we already include them with our own application's installation.

In our working prototype, it seems that the forwarders always point to our own DLLs (based on the DLL list provided by Process Explorer), which is the desired behavior for our use case. But I wanted to ask here to get an expert opinion on whether or not this behavior 100% reliable.

Any clarification or insight you all can offer would be greatly appreciated. Cheers!

What the title says, really. This repo doesn't help much with true app-local (portable xcopy-deploy) deployment of the CRT, as this repo contains no actual code, only export forwarders. When I need to do true portable CRT deployment, I copy the applicable DLLs out of the VC\Redist folder in my VS install.

Besides, IIRC the *_app.dll files contain only UWP-compatible APIs. This would make the stubs in this repository and the real implementations being forwarded to incompatible, potentially causing Store submission failure if used. Some clarification on how this code is useful would be appreciated. Thanks!

Some deployment technologies use file version checks to determine whether they need to update files on disk. Since these are in fact DLLs that get shipped alongside applications that may be deploying outside of MSIX, they should have version resources.

Proposal

Each DLL produced via this project's build system contains a VERSIONINFO resource that mirrors the VERSIONINFO resource of the specific version of the specific DLL it is pretending to be.

Prior to v1.0.6, a project with a VCRT forwarders reference could be built in isolation. Now, that fails because ProjectReferenceWithConfiguration is not defined.

Repro
Clone cswinrt repo
Run build.cmd
Attempt to build sample project alone:
c:\git\cswinrt\WinUIDesktopSample>msbuild /bl /p:platform=x64;configuration=release;solutiondir=c:\git\cswinrt\ WinUIDesktopSample.csproj

Expected
build succeeds

Actual
build fails:
C:\Users\scott.nuget\packages\microsoft.vcrtforwarders.140\1.0.6\build\netcoreapp2.0\Microsoft.VCRTForwarders.140.targets(61,5): error MSB4044
: The "UseDebugCRT" task was not given a value for the required parameter "Configuration". [C:\git\cswinrt2\WinUIDesktopSample\WinUIDesktopSample
.csproj]

When adding a reference to the VCRT forwarders in a WAP project, the Release build will fail with this error:

\packages\microsoft.vcrtforwarders.140\1.0.6\build\netcoreapp2.0\Microsoft.VCRTForwarders.140.targets(61,5): error MSB4044: The "UseDebugCRT" task was not given a value for the required parameter "Configuration". [MyApp.csproj]

This is a workaround for this problem:

    <Target Name="_FixUpProjectConfigurations"
        BeforeTargets="ResolveVCRTForwarderReferences"
        Condition="'@(ProjectReferenceWithConfiguration)' != '' And '$(VCRTForwarders-IncludeDebugCRT)' == ''">

        <ItemGroup>
            <_SavedProjectReferenceWithConfiguration Include="@(ProjectReferenceWithConfiguration)">
                <Configuration>$(Configuration)</Configuration>
                <Platform>$(Platform)</Platform>
            </_SavedProjectReferenceWithConfiguration>
            <ProjectReferenceWithConfiguration Remove="@(ProjectReferenceWithConfiguration)" />
            <ProjectReferenceWithConfiguration Include="@(_SavedProjectReferenceWithConfiguration)" />
        </ItemGroup>
    </Target>

Attached msbuild log.
wap.Release.binlog.zip

.NET CLI (or NuGet) doesn't care about the "debug"/"release" folder names and always copies libraries in both configurations.

Background: I'm building an non-packaged app which hosts a UWP control.

Steps to reproduce

dotnet new console
dotnet add package Microsoft.VCRTForwarders.140 --version 1.0.6
dotnet publish -c Release -r win10-x64 -p:Platform=x64

Expected behaviors

Only release libraries are copied to the output directory.

Actual behaviors

Both debug and release libraries are copied to the output directory.

This makes it impossible to run binskim over them, which is a requirement to use nugets in various Microsoft corp repos. I think if instead /noentry was used (to remove all the code from them) that might be sufficient instead of publishing the PDBs. The PDBs are also not on either Microsoft symbol server.

vcxproj files should invoke the cmd script used to generate the linker forwarding records so that anyone can fork this repo and build.

In the targets file for VCRT Forwarders, it checks for $(Configuration) == Release or Debug, explicitly by name. This means that if i want to add a custom Configuration to my solution (like Debug-WithExtraStuff), I don't get the right files binplaced with the ReferenceLocalCopyPaths.

Please add some other property that can allow me to opt-in to the Debug/Release steps of the VCRT forwarder targets. As an example, this line in the targets:

<ItemGroup Condition="'$(Configuration)' == 'Debug' And ('$(Platform)' == 'Win32' Or '$(Platform)' == 'x86')">

Could change to this:

<ItemGroup Condition="'($(Configuration)' == 'Debug' Or $(VCRTForwarders-Configuration) == 'Debug') And ('$(Platform)' == 'Win32' Or '$(Platform)' == 'x86')">

Then I could set that property in my custom configuration to get the same behavior as Debug or Release.

I've been hunting down a crash for several days which happened due to including the VCRTForwarders in a WinUI3 app.

Repro here: https://github.com/softworkz/MauiTest

and discussion here: ffmpeginteropx/FFmpegInteropX#379 (comment)

A big warnings and/or programmatic checks to prevent others from running into the same painful experience would be very welcome.

Thanks

The nuget package lacks an ARM32 build. Is there a reason for this omission?

Any particular reason why the debug targets have both the versions of the dll?

We have a project A, .NET framework net5.0-windows10.0.19041.0
Platform x64
We are referencing a nuget package of Project B wihich has a reference to VCRTForwarders.
if we add any project reference to project A. We are getting the following error in build pipeline
..........nuget\packages\microsoft.vcrtforwarders.140\1.0.7\build\netcoreapp2.0\Microsoft.VCRTForwarders.140.targets(61,5): error MSB4801: The task factory "CodeTaskFactory" is not supported on .NET core version of MSBuild....................

..........nuget\packages\microsoft.vcrtforwarders.140\1.0.7\build\netcoreapp2.0\Microsoft.VCRTForwarders.140.targets(61,5): error
MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assenbly...........................

We will be very grateful if this issue is fixed, it will solve a couple of issues for us.

Thank you!

I have a .net core 3.1 application using XAML islands. The reference to this package is automatically added when referencing the xaml host nuget package from the windows toolkit. Building the project from Visual Studio works fine (the dlls are copied into the output folder), but using the publish functionality does not copy the dlls to the target folder.

Note that TFMs are in flux, and netcoreapp5.0 will soon give way to net5 (and possibly the new combined format, net5-windows10)

There is a task, UseDeubgCRT, that forces the evaluation of a project file in the wrong context.

That context is missing the SolutionDir global property because it is using ProjectCollection.LoadProject with a hardcoded set of properties.

This causes any projects that <Import> files based on SolutionDir to fail to load.

Using MSBuild programmatically in this way, you must use:

var project = ProjectCollection.GlobalProjectCollection.GetLoadedProjects(projectPath).FirstOrDefault();

I have found an issue in Microsoft.VCRTForwarders.140. It sets up debug binaries in Debug configuration and release ones in Release. But actually Unreal uses release c runtime in Debug and also Unreal can have more configurations then Release and Debug. To cope with that Visual Studio uses special macro _DEBUG. If _DEBUG is defined then MSVS uses debug c runtime and release c runtime if it isn’t. Can you change Microsoft.VCRTForwarders.140.targets to follow that rule?

Hello.
I got error dotnet publish with vcrt-forwarders.
Is this dotnet/core-setup bug?

[environment]
.NET Core 3.0 Preview 8
Microsoft.VCRTForwarders.140 Version=1.0.1-rc
csproj has "PublishSingleFile" element
Console app

[command]
dotnet publish ConsoleApp1.csproj /p:PublishProfile=\PublishProfiles\FolderProfile.pubxml

[error message]

C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018: "GenerateBundle" task failed unexpectedly. [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018:    at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs) [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018:    at Microsoft.NET.Build.Tasks.GenerateBundle.ExecuteCore() in /_/src/Tasks/Microsoft.NET.Build.Tasks/GenerateBundle.cs:line 35 [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() in /_/src/Tasks/Common/TaskBase.cs:line 38 [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [	ConsoleApp1\ConsoleApp1.csproj]
C:\Program Files (x86)\dotnet\sdk\3.0.100-preview8-013656\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(807,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [	ConsoleApp1\ConsoleApp1.csproj]

[Sample csproj]
ConsoleApp1.zip

It would be good if we don't need to explicitly specify <Platform> if it has been implied by <RuntimeIdentifier>/<PlatformTarget>.

dotnet publish -c Release -r win10-x64

-or-

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

It's valid to add a project reference from a Any CPU project to a x64 one.

exe> dotnet add reference ..\lib\
Reference `..\lib\lib.csproj` added to the project.

exe> dotnet build
  Determining projects to restore...
  lib -> lib\bin\x64\Debug\net5.0\lib.dll
  exe -> exe\bin\Debug\net5.0\exe.dll

The MSVCP satellite DLL msvcp140_codecvt_ids_app.dll, first released in Visual Studio 2019 16.2, is not covered by the VCRTForwarders nuget package.

This is not an issue blocking me, I just noticed it was missing.

There are two problems which prevent the VCRTForwarder binaries from being accessible in Unity Standalone projects:

1. The .meta file designates the binaries as AnyCpu rather than denoting the correct architecture, so they are placed into the wrong subdirectory in the application data folder.
2. The application data folder paths are not part of the default library search path, so the initialization scripts need to be updated to call AddDllDirectory in Standalone configurations as they do in Editor configurations.

We have a nuget package (Microsoft.MixedReality.QR) that supports both packaged and non-packaged apps. Our package has a dependency on the Microsoft.VCRTForwarders package to support the non-packaged scenarios, but when including our package in a CppWinrt app, the forwarders are included in the appx output, which causes our binary to fail to load on certain platforms (HoloLens) due to missing dependencies.

int main()
{
#ifdef _CONTROL_FLOW_GUARD
	PROCESS_MITIGATION_CONTROL_FLOW_GUARD_POLICY cfg_policy;
	if (GetProcessMitigationPolicy(GetCurrentProcess(), ProcessControlFlowGuardPolicy, &cfg_policy, sizeof(cfg_policy)))
	{
		cfg_policy.StrictMode = true;
		SetProcessMitigationPolicy(ProcessControlFlowGuardPolicy, &cfg_policy, sizeof(cfg_policy));
	}
#endif

    // do something that requires loading the VCRT forwarders, like initializing WinUI.
}

When building the above code with /cf:guard, the following error occurs when trying to load the forwarder DLLs.

Exception thrown at 0x00007FFC0160467C (KernelBase.dll) in TranslucentTB.exe: WinRT originate error - 0x80070679 : 'The specified image file was blocked from loading because it does not enable a feature required by the process: Control Flow Guard.'.