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?
Related
I just randomly got that warning. That file exists on my hard drive, but VS refuses to understand it. I have no idea how to fix it, there are no solutions available online.
In the worst case scenario I will create project from scratch, but that will require moving a lot of code.
Edit
I have cloned older repository, now all references are missing. I thought that only Java has so many issues, but it appears C# is not better.
Edit 2
Rebuilding fixed all errors beside System.Runtime.
As a part of the Visual Studio 2017 UWP build process, an app called MakePri.exe is run. It is throwing an error in my project but I have no idea why. The command line call is:
C:\Program Files (x86)\Windows
Kits\10\bin\10.0.16299.0\x64\MakePri.exe New -ProjectRoot
C:\AdaptSource\src\Xivic\Adapt.Presentation.XamarinForms\Adapt.Presentation.Xivic.UWP\
-ConfigXml obj\x86\Debug\priconfig.xml -OutputFile C:\AdaptSource\src\Xivic\Adapt.Presentation.XamarinForms\Adapt.Presentation.Xivic.UWP\bin\x86\Debug\resources.pri
-IndexName AdaptSolutionsPty.Ltd.Xivic-Helpdesk -Verbose -Overwrite
The error that it returns is:
error PRI175 : 0x80073b0f - Processing Resources failed with error :
Duplicate Entry.
GENERATEPROJECTPRIFILE : error PRI277: 0xdef00532 - Conflicting values
for resource ''
I have no idea what it is talking about. There is no useful information in the error message. After sifting through a lot of google results, I see that the problem seems to come up when there are references to certain or duplicate DLLs in referenced .NET Standard / PCL projects.
For example:
https://forums.xamarin.com/discussion/103956/strange-build-error-xamarin-uwp
UWP unit test compile errors
But in other threads, at least people are getting a resource name to work with. I've removed as many references as I can. I've used resharper to help. I really need to get a useful error message out of MakePri. Does anyone know anything about this? Is there a way to see what it is stumbling on?
Edit: The issue was that my solution was using two versions of Xamarin.Forms. Once I consolidated the NuGet packages, the problem went away. But, I feel like this is a bug because the error message should be more descriptive. It wastes a lot of time. So, I've logged the issue here:
https://github.com/dotnet/buildtools/issues/1912
I'll leave this open until there is some kind of response at Microsoft.
Consolidate both Xamarin.Forms and Microsoft.NETCore.UniversalWindowsPlatform version for all the dependency projects will resolve the issue. It is mainly due to the Xamarin.Forms latest stable version requires higher version of Microsoft.NETCore.UnivesalWindowsPlatform nuget i.e.,(6.0.1).
The message is missing a piece, may caused by 16299 sdk
please try use 15063 and you may get the right key
I had the same problem, with the exact same error message. My fix was different than yours.
By deleting resources one at a time, until the build succeeded, i found the cause to be in one of my language .resw files I had forgotten to append .Text to the name.
Language A:
"Message.Text", "Hello world"
Language B:
"Message", "Hello world"
This oversight gave me the error you mention in the heading.
The fix for me was to append .Text so the names are identical.
I want to start off by saying I've been really hesitant to ask this question because it seems like it should be such a simple thing, however, I've scoured the internet and all I can find is the basic solution to something similar to my issue.
I have a nuget package that is v 1.30 and I'm trying to update it to 1.41. I've used the NuGet UI and I've also used the Package Manager Console to do this multiple times with small variations and I continue to get the same result. After I do something like "Update-Package PackageName" my package updates correctly. NuGet deletes the old reference and the old files and the 1.41 version is referenced by all the projects in the solution using that package. When I look at the Code, there are no syntax errors, Visual Studio seems to think the reference is just fine and I can even ctrl+B (re#er) to 'go to declaration.' However, when I build, every place I have 'using PackageName' in code throws an error that says
"The type or namespace name 'Common' does not exist in the namespace 'PackageName' (are you missing an assembly reference?)"
I have tried cleaning my solution. Then building. I've tried resetting through Git, cleaning the solution, updating then building. I've tried updating, cleaning, deleting the reference, building (will get the errors obviously), then adding the reference back in manually and building. Every time I try I get the same error. It's only happening for my Core project, but all my other projects depend on the Core, so they won't build anyway. I'm assuming this issue would still present itself if they were able to build. I've looked at the properties of the reference, it is referencing the v 1.41 file and it is set to Copy Local = True (I read somewhere someone suggested looking at that).
I'm open to suggetions for things to try. I don't have any code changes that I'll lose of I do a Git Reset, so I can try whatever.
Thanks Internet.
After trying several different things, we figured out it was a version mismatch with ASP.NET. Someone had pulled in a newer package that required updating to ASP.NET 4.5 and the solution I was working in was still ASP.NET 4.0. After updating to 4.5 the problem with the references was resolved. But we ran into some new Automapper issues. One thing after another. However, if you're banging your head against your desk in frustration because of this problem, check the framework version of your projects and the package you're updating.
Last year an ex-employee pushed a Visual Studio project to our GitBlit repository, but once I checked it out and tried to compile it, it says
Error 51 Metadata file 'D:\GIT\epimst\MSTDAO\bin\Debug\MSTDAO.dll' could not be found D:\GIT\epimst\EPIMST\CSC EPIMST
Error 47 Metadata file 'D:\GIT\epimst\EPIDAO\bin\Debug\EPIDAO.dll' could not be found D:\GIT\epimst\epiapputils\CSC epiapputils
Error 48 Metadata file 'D:\GIT\epimst\EPIDAO\bin\Debug\EPIDAO.dll' could not be found D:\GIT\epimst\MSTDAO\CSC MSTDAO
Error 50 Metadata file 'D:\GIT\epimst\EPIDAO\bin\Debug\EPIDAO.dll' could not be found D:\GIT\epimst\EPIMST\CSC EPIMST
So my solution was to copy these DLLs from our deployed software and simply copy them back into their various directories. This fixed the 'count not be found' errors, but then a host of undefined code errors came up.
Seeing as how this code did work at some point and the live packages still function, I cant figure out what went wrong between the code being checked in and eventually checked out by me.
Unfortunately we cant get in touch with that one employee that pushed up the code, and I've spent a few days reading about changing target frameworks, output options, build settings, etc, but none of them fix the dependencies problems or missing DLLs.
We are almost positive the DLLs are from the same version as we only released one version of the software, but somehow the source code no longer works.
I notice that you are listing the errors out of sequence. This suggests that you have made a common mistake which is especially critical when bringing up a solution in a new environment:
You are reading the tabular "Error List" window rather than the compiler output.
This is bad for two reasons:
The compiler output contains additional information related to the compile and often related to the errors. But all non-error messages get stripped by the IDE and don't appear in the "Error List" window.
The first messages are the most important, because later errors are often side effects of the first few.
Switch to the "Output" window, make sure the setting is "Show output from: Build", scroll to the top, and start addressing errors in the order of occurrence.
The most likely possibility is that the coder forgot to check in one file, resulting in errors in that project where other files used that class. Then since that project didn't build, all the dependent projects can't find anything that's contained in that or any other dependent project, resulting in hundreds of errors. Which is really hard to sort out in the Error List, but perfectly clear when you switch to the actual Build Output log.
I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.
Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.
When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help
I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.