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

[maxinfet]

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 ==========

[davkean]

This issue was moved to dotnet/msbuild#3875

[davkean]

Sorry, reopening this, it looks like a project-system issue. @tmeschter this is legacy project system, can you take a look?

[tmeschter]

Eventually, yes. I'm pretty backed up at the moment, though. :-(

[amaitland]

This output is from a reproduction project I put here.

@maxinfet Migrating to the newer Nuget restore method will likely solve your problem, see https://www.xavierdecoster.com/post/2014/03/06/migrate-away-from-msbuild-based-nuget-package-restore.html
(Basically remote the EnsureNuGetPackageBuildImports target from your .csproj file)

[maxinfet]

@amaitland Unfortunately we can not make that change very quickly for our main project. It is on our radar to make the move to the PackageReference instead of package.config. I will try that in my reproduction project just to see what affect it has though.

[amaitland]

@maxinfet You still use packages.config, overall the changes are trivial and take a few minutes to make, there are even powershell scripts that people have written. This change relates to how the packages are restored, not how they're included/managed. Read the article if you haven't already.

[amaitland]

It is the preferred approach when using CefSharp, it's listed in the Nuget Readme

[maxinfet]

@amaitland I can remove the EnsureNuGetPackageBuildImports target, and it will certainly stop the error, but unfortunately many packages add that as they are installed.

[maxinfet]

@amaitland After removing the EnsureNuGetPackageBuildImports I get the same error the first time I build.

[maxinfet]

I changed the ReproductionApplication to use PackageReference then deleted my CefSharp packages from the global cache and it built correctly on the first build. @davkean I am not sure if that information is helpful to you but figured I should report those results back. Here is a link to the same project changed to use PackageReference.

[tmeschter]

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

[amaitland]

@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.

[davkean]

@melytc: Please figure out this if this a regression from previous versions and send back to triage

[amaitland]

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.

[maxinfet]

@amaitland We are using PackageReference with the legacy project system and it is working in VS2017. So the difference between my report that it works with PackageReference and your finding could be the SDK project system vs legacy project system.

[amaitland]

So the difference between my report that it works with PackageReference and your finding could be the SDK project system vs legacy project system.

@maxinfet I've updated my comment to hopefully make it clearer. Using the terminology outlined in https://docs.microsoft.com/en-us/nuget/resources/check-project-format to hopefully eliminate any confusion.

[tmeschter]

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.