project-system: Building project with CefSharp fails to build until I restart visual studio

Issue

In 15.7.6 the reproduction project I linked bellow builds every single time even when restoring nuget packages. As of 15.8.6 the first build will fail with the following error The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. After I perform another rebuild it will build fine.

For our main solution it does not matter how many times we rebuild it will not build until we follow the steps in issue #3930. When we were on 15.8.5 we got a different set of errors, but on 15.8.6 we get the same error as my reproduction project.

Solution Details

Our solution uses the legacy project system
We use package.config to restore our nuget packages

Error Details

This issue is happening during MarkupCompilePass1. This output is from a reproduction project I put here.

Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the NuGet Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
NuGet package restore finished.
1>------ Rebuild All started: Project: ReproductionApplication, Configuration: Debug x86 ------
1>Build started 10/23/2018 3:14:42 PM.
1>GenerateBindingRedirects:
1>  No suggested binding redirects from ResolveAssemblyReferences.
1>C:\Perforce\ReproductionApplication\15.8.6\ReproductionApplication\MainWindow.xaml(11,10): error MC3074: The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. Line 11 Position 10.
1>
1>Build FAILED.
1>
1>"C:\Perforce\ReproductionApplication\15.8.6\ReproductionApplication\ReproductionApplication.csproj" (Rebuild;BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;DebugSymbolsProjectOutputGroup;DebugSymbolsProjectOutputGroupDependencies;DocumentationProjectOutputGroup;DocumentationProjectOutputGroupDependencies;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies;SGenFilesOutputGroup;SGenFilesOutputGroupDependencies target) (1) ->
1>(MarkupCompilePass1 target) -> 
1>  C:\Perforce\ReproductionApplication\15.8.6\ReproductionApplication\MainWindow.xaml(11,10): error MC3074: The tag 'ChromiumWebBrowser' does not exist in XML namespace 'clr-namespace:CefSharp.Wpf;assembly=CefSharp.Wpf'. Line 11 Position 10.
1>
1>    0 Warning(s)
1>    1 Error(s)
1>
1>Time Elapsed 00:00:00.65
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 17 (6 by maintainers)

Commits related to this issue

Nuget - Manually copy files after initial Nuget restore One final attempt to workaround https://github.com/dotnet/project-system/issues/4158 The None/Content entries aren't picked up as the .targets... — committed to cefsharp/CefSharp by amaitland 3 years ago
Nuget - Manually copy files after initial Nuget restore One final attempt to workaround https://github.com/dotnet/project-system/issues/4158 The None/Content entries aren't picked up as the .targets... — committed to cefsharp/CefSharp by amaitland 3 years ago

Most upvoted comments

Tom’s triage notes: Given that the scenario works when using PackageReference-style NuGet I recommend we just close the issue.

tmeschter on May 31, 2019

I see what’s going on with this.

The fundamental issue is that the <Reference> items for CefSharp.Wpf.dll and the other assemblies are not present in the .csproj file itself, but rather brought in through the imports of various .props and .targets files at the beginning and end of the .csproj. These imported .props and .targets are found in the NuGet packages themselves, and before the first NuGet restore they do not exist on disk. In addition, the <Import> items are conditioned on the files existing, so during the first solution load we don’t see them–it’s as if the <Import>s don’t even exist.

When the restore occurs the files will be written to disk. If we were to re-evaluate the project at that point we would pick them up and the <Reference> items they contain. However, since we don’t even know the <Import> exists we don’t know we need to re-evaluate. If we re-evaluate the project for some other reason (e.g., it is unloaded and reloaded, or a .cs file or reference is added) we will then see the imported files.

Fundamentally this is a known limitation of packages.config-style NuGet packages, and the solution is to move to PackageReference items. It may have accidentally worked in the past, but only because of unrelated parts of VS forcing the project to be re-evaluated.

I am closing this bug and marking it “Resolution-By-Design” as everything is working as well as expected.

tmeschter on Jun 17, 2020

@tmeschter Is there a reason you won’t fix this? It quite clearly is a regression in VS2017, and an example that reproduces the problem has been provided. It’s great there is a workaround, that doesn’t help those who are currently unable to migrate their projects. If it was a new feature then I’d understand.

amaitland on May 31, 2019

You can use https://github.com/cefsharp/CefSharp.MinimalExample for testing purposes, it provides both an old packages.config example that targets .Net 4.5.2 and a PackageReference example that targets .Net Core 3

packages.config (Non-SDK-style project)

Open CefSharp.MinimalExample.sln in VS2017 (Tested with 15.9.16)
Build -> Build Solution
Build fails on initial attempt
After the nuget packages have restored you’ll have to close and reopen the solution

Subsequent builds will work as expected.

VS2013 and VS2015 were working last time I checked (it has admittedly been a little while since I tried).

VS2019 (16.4.3) behaves slightly different, it won’t attempt a Nuget Restore until the second build attempt, then you can close the solution and reopen.

PackageReference (SDK-style project)

Open https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.netcore.sln in VS2019 (Tested with 16.4.3)
Build -> Build Solution
Build successful.

Building with .Net Core 3 so have to use VS2019 for testing here. Comment confirms the PackageReference style is also working in a Non-SDK-style project.

If you switch between the solutions you’ll have to manually delete the obj folder in each project. I haven’t managed to wrangle VS into behaving nicely when switching.

Please let me know if you require any additional information.

amaitland on Feb 5, 2020