I'm trying to resolve a large number of warnings that have built up in a Xamarin Forms project I've been tasked with working on. When building the iOS version, I am receiving several warnings that look like the below:
"/Users/redacted/Development/redacted/redacted/Mobile/redacted/MTOUCH: Warning MT0109: The assembly 'System.IO.Compression.dll' was loaded from a different path than the provided path (provided path: /Users/redacted/.nuget/packages/system.io.compression/4.3.0/runtimes/win/lib/netstandard1.3/System.IO.Compression.dll, actual path: /Library/Frameworks/Xamarin.iOS.framework/Versions/12.2.1.16/lib/mono/Xamarin.iOS/System.IO.Compression.dll). (MT0109) (Itx.iOS)"
I've pretty much combed all over the place for a solution to this problem, but I haven't found much of anything for this issue.
How can I get this stubborn warning to go away?
Related
The following warning appears in my UWP project. I have already marked examples of solutions but I am more interested in why this warning does not occur when creating another empty project on the same platform?
APPX4001: Build property AppxBundlePlatforms is not explicitly set and is
calculated based on currently building architecture. Use 'Create App
Package' wizard or edit project file to set it.
Simple workaround for APPX4001 warning see this issue.
But I am more interested in why this warning does not occur when
creating another empty project on the same platform?
I searched the related info about this warning and found this similar issue. See ...\AppxPackage\Microsoft.AppXPackage.Targets(2459,5): warning ..., so it seems that this warning is thrown by the Microsoft.AppXPackage.Targets file. Not sure why the warning sometimes doesn't show where it come from, but I think the targets file is the cause of APPX4001.
I found that file in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage. (for vs2017 enterprise) Let's check its content which throw the warning:
So it's obvious that if the value in Condition is true, it will throw warning APPX4001. It seems that this issue have something to do with the AppxBundle. So I create a new uwp project and build it, all is ok. And then I add this line into its xx.csproj file:
<AppxBundle>Always</AppxBundle>
Then the same warning occurs:
So this warning will occur if you try to build with Appxbundle or set the AppxBundle property in project file while you didn't set the AppxBundlePlatforms property.
This is the reason why new simple project won't display this warning. And simple workaround for this warning is to set the AppxBundlePlatforms property, see the first line in my answer.
Hope all above can help resolve the puzzle why the warning comes and resolve the warning.
Let me know if I misunderstand anything :)
Perhaps this link can help.
As described in the article, I tried to package my App (just used Sideload package without signature).
The packaging process then added the
<AppxBundlePlatforms>x86|x64|arm</AppxBundlePlatforms>
entry in the .csproj file and the warning has disapeard
On Unity, where the C++ project is being generated on-the-fly (editing is pointless),
one can pass /p:AppxBundlePlatforms=x86|x64|arm as an argument to MSBuild.exe.
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'm trying to have Code Analysis going for my .NET Standard 2.0 class library. As described here, I've added a reference to Microsoft.CodeAnalysis.FxCopAnalyzers. At the beginning, everything looked good and I started getting CA* warnings when building the project. However, after a while, these warnings disappeared although I hadn't touched the code.
Only after closing VS 2017, deleting all bin directories, restarting VS 2017, I started getting back the CA* warnings. However, this doesn't seem to be the recipe to get them back: in my CI environment, the same thing happened. I lost the warnings after an unrelated commit and I still didn't manage to bring them back although I've cleaned the checkout directory completely.
I wonder what could be the reason that at moments the Code Analysis stops working. Unfortunately, I haven't figured out a way to reproduce this - thus my question.
As a matter of fact, I'm eager to understand why adding a NuGet to a project can modify the outcome of the compilation process at all. How does that magic work? Any pointers are welcome.
As to how Roslyn Analyzers are loaded from NuGet
The new C# and VB compilers are based on Roslyn. Roslyn is an extensible compiler framework where a number of analyzers can run at different stages of the compilation process.
MsBuild will pass the analyzers references from the project file to the call to the Roslyn compiler, which will load these in turn and will execute them after the sources have been parsed and interpreted.
The NuGet packages have special metadata that ensures that these analyzers are added as a special type of reference to the MsBuild project file so that MsBuild can pass these along to the compiler.
As to why the analyzers sometimes fail
This is hard to say. Some metadata of projects is stored. Setting the options to clear the workspace/working directory and start afresh may fix this. Setting the build.clean variable to all should help with that. Deleting the bin, obj and .vs folder as well as the packages folder and performing a nuget restore + build should bring you back into a usable state.
The new FxCop analyzer project still isn't complete and is still being updated. A bug in the analyzer infrastructure can cause the analysis to fail. Unfortunately, this is generally very hard to debug. Turning off rules one by one may help you find the culprit.
There seems to be an option built into Roslyn to enable ETW Logging, which should give you a lot more details, but this isn't very well documented.
In Visual Studio there is another thing that can break the analyzers, Visual Studio Extensions can load analyzers as well, which Visual Studio will then inject into the build process. These extensions are not part of your project and thus won't show up in source control in any way. Any recently updated extension could thus also be the culprit. Setting the MsBuild verbosity level to Diagnostics should show you which analyzers are passed to csc, which should help you figure out where your problem may be coming from.
I am new to working with the light version of Visual Studio Code and for the life of me I cannot figure out how to resolve this error.
I've tried to pull in any type of file the even closely resembles the terms .eslint but i always get this error. I am sure it is a config error but I do not know how to work with the config just yet.
Any suggestions?
I am taking a Node.js course and they are using this light version and i would like to use it as well because it is somewhat faster for taking classes and so on.
Error
Cannot find module 'eslint-config-defaults/configurations/eslint'
You will have to install eslint-config-defaults and other related modules.
Fire up a Shell and execute:
$ npm install --save eslint-config-defaults
Note: You might also be prompted with other errors after installing the above module. So, you have to install those modules as well.
When building one of my projects, I'm getting the following warnings:
Warning 3 Cannot find wrapper assembly for type library "Microsoft.Office.Core".
Warning 4 The referenced component 'Microsoft.Office.Core' could not be found.
Strangely, the build fails with no errors. The warnings above seem to be the problem. This started happening after I installed some Office 2007 updates from Windows Update. Before that it was building everything fine.
Has anyone experienced the same issue? Any ideas on how to solve this problem without modifying the project?
most likely one of your reference was updated to new version, so the current version can not be found.
Click "project****Properties\reference" and remove the one can not be found is ok.
It appears to be a COM reference? I'd guess the update caused the reference to be considered out of date.
If so i'd consider building the interops manually and checking them in, then adding references to the interops. The downside is that will move the problem from compile time to run time.