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
Tom’s triage notes: Given that the scenario works when using
PackageReference
-style NuGet I recommend we just close the issue.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 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.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 aPackageReference
example that targets.Net Core 3
packages.config (Non-SDK-style project)
VS2017
(Tested with15.9.16
)nuget
packages have restored you’ll have to close and reopen the solutionSubsequent builds will work as expected.
VS2013
andVS2015
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 aNuget Restore
until the second build attempt, then you can close the solution and reopen.PackageReference (SDK-style project)
VS2019
(Tested with16.4.3
)Building with
.Net Core 3
so have to useVS2019
for testing here. Comment confirms thePackageReference
style is also working in aNon-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.