Build fails for a MFCActiveX project

[cando]

Description
Build fails in a MFC ActiveX project due to copy step in "Microsoft.Web.WebView2.targets" for .NET framework.

Errors:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4651,5): error MSB3030: Could not copy the file "C:\Users[USERNAME]\Source\Repos\ImaWebView2\packages\Microsoft.Web.WebView2.0.9.628-prerelease\build\runtimes\win-x86\native\WebView2Loader.dll" because it was not found.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4651,5): error MSB3030: Could not copy the file "C:\Users[USERNAME]\Source\Repos\ImaWebView2\packages\Microsoft.Web.WebView2.0.9.628-prerelease\build\runtimes\win-x64\native\WebView2Loader.dll" because it was not found.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4651,5): error MSB3030: Could not copy the file "C:\Users[USERNAME]\Source\Repos\ImaWebView2\packages\Microsoft.Web.WebView2.0.9.628-prerelease\build\runtimes\win-arm\native\WebView2Loader.dll" because it was not found.

Version
SDK: 0.9.628-prerelease
Runtime: 87.0.661.0 (Official build) canary (64-bit)
Framework: MFC ActiveX
OS: Win7

Repro Steps

Screenshots

Additional context

Resolution
The problem is due to this ItemGroup condition:
ItemGroup Condition="'$(TargetFramework.TrimEnd(0123456789))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(0123456789.))' == 'v')"

since Keyword for my project is 'MFCActiveXProj'. Changing the line to:

ItemGroup Condition="'$(TargetFramework.TrimEnd(0123456789))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(Keyword)' != 'MFCActiveXProj' And '$(TargetFrameworkVersion.TrimEnd(0123456789.))' == 'v')"

fixes the problem.
Does it make sense to you?

AB#29743156

[champnic]

Thanks for finding this! I've opened a bug internally and we'll get this fixed.

[fobrs]

I've this problem too with a C++ MFC x64 app. WebView2 SDK 0.9.622 worked ok.

(Where is $(Keyword) defined?)

[dudasl]

I must report the same issue on version 1.0.664.37. Looks like the NuGet package Microsoft.Web.WebView2 1.0.664.37 is configured badly. Version 1.0.622.22 is working fine.

[jhandley]

Seeing same issue with 1.0.664.37. Earlier versions with the same project were fine. I also tried creating a simple test project and adding the nuget package and I get the same error:

1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4846,5): error MSB3030: Could not copy the file "C:\Users\josh\source\repos\WebViewModalDialog\packages\Microsoft.Web.WebView2.1.0.664.37\build\runtimes\win-arm\native\WebView2Loader.dll" because it was not found.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4846,5): error MSB3030: Could not copy the file "C:\Users\josh\source\repos\WebViewModalDialog\packages\Microsoft.Web.WebView2.1.0.664.37\build\runtimes\win-x86\native\WebView2Loader.dll" because it was not found.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4846,5): error MSB3030: Could not copy the file "C:\Users\josh\source\repos\WebViewModalDialog\packages\Microsoft.Web.WebView2.1.0.664.37\build\runtimes\win-x64\native\WebView2Loader.dll" because it was not found.

Just created new MFC dialog based project, added the nuget project and hit build.

[champnic]

Thanks for the added info all. I'm upping the priority of this bug. Thanks!

[champnic]

Can you try this with the latest prerelease SDK, 1.0.721-prerelease?

[dudasl]

I tried my example with version 1.0.721-prerelease and looks fine.

[jhandley]

The build error is gone with 1.0.721-prerelease however now I get an error at runtime that WebView2Loader.dll was not found.

[jhandley]

Looks like WebView2Loader.dll is copied into Debug\x86\ and Debug\x64\ but the exe file is just in Debug. In earlier versions WebView2Loader was copied into the output directory (Debug) without the platform.

[champnic]

WebView2Loader.dll is platform specific, so requires multiple flavors which are in the x86\ and x64\ folders by default. I'm going to close this specific issue as it seems to be fixed, but @jhandley feel free to open a separate GitHub issue with more specific details about the issue you are seeing. Thanks!

[champnic]

Reopening this, as we are still get reports of this (see mentions above).

[AmitRungta]

Hi,

I am using VS 2019 and trying to integrate WebView2 in it. For this created a dialog based MFC application and added the latest nuget packages for Microsoft.Windows.ImplementationLibrary (1.0.210204.1) and Microsoft.Web.WebView2(1.0.705.50).

Now when i compile the project i am getting the following error

Error MSB3030 Could not copy the file "....\packages\Microsoft.Web.WebView2.1.0.705.50\build\runtimes\win-x86\native\WebView2Loader.dll" because it was not found. HelpViewer C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 4846
Error MSB3030 Could not copy the file "....\packages\Microsoft.Web.WebView2.1.0.705.50\build\runtimes\win-x64\native\WebView2Loader.dll" because it was not found. HelpViewer C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 4846
Error MSB3030 Could not copy the file "....\packages\Microsoft.Web.WebView2.1.0.705.50\build\runtimes\win-arm\native\WebView2Loader.dll" because it was not found. HelpViewer C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 4846

Have checked and the files are now present in this folder but have a different path.

[mariusbancila]

How exactly is this problem fixed? I've tried 1.0.790-prerelease and the build error is gone, but the WebView2Loader.dll is not copied to the output folder. Therefore, when I run the program I get this error:

I can see the DLL is copied to the folder Debug\runtimes\win-x86\native instead of Debug.

The file Common.targets includes this:

<ItemGroup Condition="'$(TargetFramework.TrimEnd(`0123456789`))' == 'net' Or ('$(Keyword)' != 'Win32Proj' And '$(TargetFrameworkVersion.TrimEnd(`0123456789.`))' == 'v')">
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x86\native\WebView2Loader.dll" Condition="'$(EffectivePlatform)' == 'x86' Or '$(EffectivePlatform)' == 'anycpu'">
      <Link>runtimes\win-x86\native\WebView2Loader.dll</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <IncludeInVsix>true</IncludeInVsix>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-x64\native\WebView2Loader.dll" Condition="'$(EffectivePlatform)' == 'x64' Or '$(EffectivePlatform)' == 'anycpu'">
      <Link>runtimes\win-x64\native\WebView2Loader.dll</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <IncludeInVsix>true</IncludeInVsix>
    </Content>
    <Content Include="$(MSBuildThisFileDirectory)\..\runtimes\win-arm64\native\WebView2Loader.dll" Condition="'$(EffectivePlatform)' == 'arm64' Or '$(EffectivePlatform)' == 'anycpu'">
      <Link>runtimes\win-arm64\native\WebView2Loader.dll</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <IncludeInVsix>true</IncludeInVsix>
    </Content>
  </ItemGroup>

So how is this supposed to work?

[horiachr]

The problem is because the DLL isn't copied at all unless $(Keyword) evaluates to Win32Proj.
Check the following section from Common.targets. The solution should be trivial:

<!-- Copy DLL to the output path.
    Only Copy DLL to the output path when project is C++ and WebView2LoaderPreference is set to Dynamic.
    .NET will pick DLL at runtime from runtime folder or processor bit folder base on Core or Framework.
    See Content: https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2019
    See Architecture-specific folders for .NET:
    https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders
  -->
  <ItemGroup Condition="'$(WebView2LoaderPreference)' == 'Dynamic' And '$(Keyword)' == 'Win32Proj'">
    <Content Include="$(MSBuildThisFileDirectory)$(EffectivePlatform)\WebView2Loader.dll">
      <Link>%(Filename)%(Extension)</Link>
      <PublishState>Included</PublishState>
      <Visible>False</Visible>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>

How long would it take to fix this into a new prerelease, allow for MFCProj and MFCActiveXProj in that condition?

[champnic]

We've checked in a fix for this and it should be available in the next pre-release package (likely around early March).

[hunkydoryrepair]

Ok, so where is the file supposed to be? For my WinForms project it is copying it Release\runtimes\win-x86\native in the build folder.

Is it still supposed to be in x86 folder?

[PranilJ]

Hey, I am running into this same issue on WebView2 SDK versions 1.0.664.37, 1.0.705.50, 1.0.774.44 . It works fine on 1.0.622.22 . If it helps, I would be glad to furnish any other details about my environment/project

[mariusbancila]

I suppose 1.0.774(.44) is older than 1.0.790(-prerelease), even if it was released after. So since it didn't work in 790 it can't work in 774. There must be another release. But this is taking way to long. It's an error with such a simple fix going on for almost half an year. 😢

[champnic]

Apologies for the delay - the fix will be available with the next prerelease package, which should be this week or early next. Thanks!

[champnic]

This should be fixed in 1.0.824-prerelease SDK package. Please give it a try and let us know if you run into any further issues. Thanks!