Our team has been working on some UWP apps for some time now, recently after updating some nugget packages on any Rebuild of the project we get errors similar to this:
File=MakePri: Processing Resources failed with error: Duplicate Entry.
File=MakePri: Conflicting values for resource 'ExceptionStringTable/NameScopeNameNotFound'
There are similar questions on SO that are caused either by user created/managed resources or that are simply fixed by cleaning the project outputs and/or rebuilding.
This is different to other questions around MakePri and resource duplicate entries on SO because these resources that have conflicts are not provided or managed by any of my application code. Therefor I cannot simply remove the duplicate entry in my code.
The problem is that there are two resource files in the output that have duplicate entries. Mind you it's not a duplicate file, just a small handful of entries exist in both of these files:
\obj\ARM\Debug\System.Xaml\en-US\ExceptionStringTable.resw
\obj\ARM\Debug\WindowsBase\en-US\ExceptionStringTable.resw
My Question, is there a way in VS ALM to smartly either ignore these errors, or fix the duplicate entries before/during compilation? Further, has anyone else noticed this issue and is there a better way to resolve it? I suspect messing around with NuGet package versions might help but I'm keen to see what the rest of the community has to say before I spend much more time on this.
Turns out, you cannot simply delete these files, if you do so the next build will put them back, but what you can do is edit the files to remove the entries. Then the file will remain until the project outputs are cleared.
I'm not going to list the conflicts, we found them through trial and error and then after a while got lazy and removed whole chunks from these resources.
The consequences of this action is that now if an exception is raised and it's message string was one of those resources we carelessly removed, I have to google the exception code if I'm not already familiar with it. That took some getting used to :)
As I said, I suspect versions of NuGet packages could be to blame. But I'm not sure where System.Xaml.dll comes from. Surely the good guys as MS on the WindowsBase and XAML teams must be aware of this conflict and I'm hoping that it gets resolved in the future. Which is why I'm looking for a low effort solution
WindowsBase: \.NETFramework\v4.6.1\WindowsBase.dll
PM> Install-Package Microsoft.NETCore.UniversalWindowsPlatform (v5.3.1)
Our current solution is to replace the XAML version of the ExceptionStringTable.resw file with one that we previously edited and saved back to the solution root. It's an annoying process that I often forget.
Has anyone else experienced this and found a better solution?
