Develop Reference

Xamarin Build Error Compilation can't be completed because some library classes are missing

When I try to build my Xamarin.Droid project I get following Build error:
2>R8 : warning : Missing class: java.lang.ClassValue
2>R8 : error : Compilation can't be completed because some library classes are missing.
I got this error from one day to another... Is there a way to find out where java.lang.ClassValue is needed, or add it manual?
Edit:
I did some research and got new informations: When I build the solution on another maschine (I this case Microsofts AppCenter) it builds without any problems. So I thought that my solution is fine, maybe there are problems with the android sdk or the jdk.
So I created a new Xamarin.Forms project and build the android part, that worked without any problems. So the android sdk or jdk seems to be fine.

Not that this is a solution exactly, but it may point you in the right direction. I'm currently getting this message as a result of a bound Android-library under our own maintenance. When I remove the NuGet from our project, the message disappears and the code compiles. Obviously I can't make use of the program features using this library then either, but at least it looks like the library is causing the issue... May be it could be the same in your case?
What fixed the issue for me
After I knew which library was causing issues, I decided to dive it a bit more with a demo-app I had written specifically to test that library. From here I found out that enabling d8-dexing or r8-code-shrinking together with multi-dexing is what caused the issue. You can use either or, so:
Turn of code-shrinker options such as ProGuard or r8, and use d8-dexing.
Turn of multi-dexing, use d8-dexing and optionally a code-shrinker.
My suggestion is to use the latter, as with d8-dexing, your dexed reference-table should be much more efficient and smaller anyway, meaning you might not even need multi-dexing any more.
In addition, it seems the above resolution doesn't play to nicely with linking, so set linking options to "None".
Problems on a Mac CI
After I fixed all of the above I ran into a further issue when trying to compile our app on a Mac CI, which told me Mono.Android.dll could not be AOT-compiled. This, apparently, is an issue with the file being too big for LLVM on a Mac, though, as described here, for which the solution is to simply turn off LLVM.
A better way of fixing it
Today I was pointed to another set of potential fixes highlighted here. This page actually mentions three fixes, of which option B is the preferred one as this is in-line with "the upstream recommendation from the Google Guava library" (cited from this thread).
For me option A - reverting to dx-dexing - didn't quite work, as, though I was able to remove the warning pertaining to java.lang.ClassValue, I got a whole bunch of other warnings back. Option B, using ProGuard-rules used in combination with R8, was a better choice in that respect, since this allowed me to get rid of all the other warnings as well. In fact, though, this removed the difference between options B & C, as their outcome thereby became the same. Yet, just following the suggestions in this document, my app started crashing on launch. To resolve this, I had to check for errors in Logcat, which showed me a class that was needed was being linked away. Adding another rule to explicitly keep that class then finally resolved the remainder of the problem, giving me the below ProGuard-configuration:
-dontwarn java.lang.ClassValue
-dontwarn kotlin.jvm.internal.Lambda
-dontwarn kotlin.jvm.functions.Function1
-dontwarn kotlin.jvm.internal.markers.KMappedMarker
-dontwarn kotlin.jvm.functions.Function0
-dontwarn kotlin.coroutines.jvm.internal.SuspendLambda
-dontwarn kotlin.jvm.functions.Function2
-keep class com.google.android.material.internal.BaselineLayout
With this configuration, I'm now once again able to use both AOT and LLVM.

Unity: InvalidProgramException: Invalid IL code XXX(): IL_0011

So the project is an online MMO. It uses the uMMORPG2D asset (which in turn uses UNET).
The code in question has been working fine for the last week without incident, and hasn't been modified in any way in that time at all. However now it suddenly is throwing this error. I'm at a loss.
To complicate matters further, on my own build/version of the project it all runs fine. I do not get this error. However a friend who runs the exact same build/version does get this error.
The line that is claiming to be broken is extremely simple (couldn't be simpler). All it does is it sets one integer equal to another....the only potential problem is the integer being set is a [SyncVar] (but again, this has been the case for the last week+)
Below is the relevant code;
[SyncVar]
internal int mainID = 0;
public void SetIndices(int bodyIndex, [...])
{
mainID = bodyIndex;
[...]
}
SetIndices gets called from
int bodyID = Convert.ToInt32((long)mainrow[5]);
[...]
charCreator.SetIndices(bodyID, [...]);
There is no cast exception or anything of the sort (as far as I know) so I see no reason why this would cause an error?
The actual error is
InvalidProgramException: Invalid IL code in
CharacterCreator:set_NetworkmainID (int): IL_0011: call
0x2b00000a

Whilst I'm not exactly certain as to the actual cause of the problem,
the solution was to reinstall Unity.
I was advised by team members to implement HLAPI Pro plugin for Unity (which involved replacing Unity.dll files in the installation directory). I was told that an incorrect installation would result in many errors (which no one had) so assumed it worked fine.
After significant testing, the only difference between when it was working, and when the error started to show was the HLAPI Pro installation. So I uninstalled it and it was working fine.
Don't know why it broke, perhaps I installed it incorrectly, but reinstalling Unity resolved the issue.

Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible

Here is the error
Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.
I am writing a simple console app and the first line of code is this:
List<MyObjectModel> list = MyObjectModel.GetNonCompletedReturns();
and the code for the function is:
public static List<MyObjectModel> GetNonCompletedReturns()
{
MyObject service = new MyObject();
List<MyObject> entities =
(from recs in service.Retrieve() where select recs).ToList();
List<MyObjectModel> models = new List<MyObjectModel>();
foreach (MyObject entity in entities)
{
models.Add(BindModel(entity));
}
return models;
}
and if I try to step through the code, as soon as I get back to the main of my app and hover over the list, I get the error message that I showed.
Can anyone help?

If your project is compiled in release (with optimizations turned on), you may see this. Have you tried the DEBUG configuration?

This error fires only when you are trying to use Watch dialog during debug.
Try to use some other technique to output the variables, like Debug.WriteLine, Console.WriteLine and so on.

None of the answers solved my problem so I'm posting the solution that helped me.
"If there is to much data in the parameters then this error can occure,
a simple solution is to make an object, not a struct because that's a dataobject.
Put this object in your parameters instead of all the different variables,
normally the problem will no longer take place."

Here's a little trick just in case you want to examine some objects and you are not able to change the parameters:
I've created a call to a new temporary function, inside the function from where I was unable to watch my object. Then, inside that new function I was able to watch my object. After the job is done, just delete the function.

While it's true that the "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized" error appears when in release mode, most developers just ensure that their projects are configured to compile as a debug build. BUT to be sure that you have no release-DLL issues, you also must check the references to DLLs that are in your solution and make sure that you don't have a reference to a release-build DLL. If you find that this is the case, delete the DLL reference and then add a project reference rather than a DLL reference. The project reference will ensure that your solution references debug or release versions of the DLL as specified in your build configuration.
Note that the above advice applies, of course, to only those DLLs to which you have source code and which are built from a project in your solution.

I got this too, when I hit a NullReferenceException from a 3rd party control.
In this one case, I found that if I set a breakpoint before I hit the exception, I could then single step through the rest of the code without seeing the problem.
No idea why, but this worked for me - in this case at least.

For what it's worth, this error can also be caused by an infinite loop in a property getter (simplified version below). When the debugger attempts to evaluate the property (e.g. in the watch window) the UI will hang for a few seconds and the "Cannot evaluate expression..." error will appear for many of the other properties in the same class.
public int MyProperty
{
get
{
while (true) { }
return 0;
}
}

First make sure that you're running your code in DEBUG mode and with code optimization turned off. you can turn that off from the properties of your project.
If you made all of the above and the problem persists, then it's probably a problem with the stack having Debug.Break() on top of it. The solution for this is very easy, just press F10 to move to the next line and you should be able to evaluate the expression.
You can check this SO question for more information about this issue.

I was experiencing the same error message in the Visual Studio debugger when evaluating a linq expression.
Disabling the VS debugger config setting 'Enable Just My Code' resolved the issue for me:
To enable or disable Just My Code, choose the Tools > Options menu in
Visual Studio. In the Debugging > General node, choose or clear Enable
Just My Code.
https://learn.microsoft.com/en-us/visualstudio/debugger/just-my-code

I was having same issue in Visual Studio 2017. Going to Debug> Options> Debugging> General and checking "Suppress JIT optimization on module load(Managed only)" fixed my issue

XMLSerializer failing save/load when called from an assembly dynamically loaded from parent application?

I am writing a plugin dll for an application. The application loads plugin assemblies via:
assembly = Assembly.Load(System.IO.File.ReadAllBytes(filename));
The problem manifests itself when I attempt to serialize/deserialize a plublic class. I narrowed it down to the serialization of:
public BindingList<MyClass> MyClasses
{ get; set; }
If I comment this out, no problems. If I attempt to serialize with:
public static void SaveSettingsFile()
{
try
{
XmlSerializer ser = new XmlSerializer(typeof(GameTimeSettings));
TextWriter writer = new StreamWriter(SettingPath);
ser.Serialize(writer, Settings.Instance);
writer.Close();
}
catch (Exception e)
{
Logger.ReportException("SaveSettingsFile", e);
Logger.ReportException("SaveSettingsFile->InnerException", e.InnerException);
}
}
An exception is thrown on ser.Serialize(writer, Settings.Instance) :
System.InvalidOperationException Msg=There is an error in XML document (0,, 0). ->
InnerException: Object reference not set to an instance of an object.
My class has a default, empty constructor. I have tried using sgen. In a simple testbed application I wrote, serialization works fine... it's only when the Assembly is dynamically loaded does it fault.
Furthermore, from these two threads,
http://forums.gbpvr.com/showthread.php?30384-XMLSerializer-Problems-with-Plugins , http://forums.gbpvr.com/showthread.php?32197-System.XML-Deserialization
I know I can change the type from BindingList to ArrayList and have it work; however, I would like to keep databinding working as there are quite a bit of settings to manage.
Any input would be appreciated.

John Saunders' comment appears correct for this so far, you likely are not initializing MyClasses.
Since you say it works fine with SGen, you might also want to check if it has something to do with the compile flags, like maybe try setting it to release and see if that changes things.

Sorry to pull this up from the grave, but I ran into a similar issue again today and this was the first google result, so I thought I'd share.
This appears to be a generic case of an issue I had ran into awhile back when attempting to write an MSBuild Custom task (basically a plugin). I posted about it on the MSDN Forums.
Here is the most relevant part of the comment, simply substitute MSBuild for any application that has a plugin architecture, and the CruiseControl.NET library for any library that uses the XmlSerializer:
The Library in question is the Remoting Library for ThoughtWork's CruiseControl.NET, this library uses .NET Remoting with some Client Activated Objects. When you go to attempt to activate the object, .NET's Binary Serializer goes to work trying to figure out where to load the ThoughtWorks.CruiseControl assembly from so it can read the object (ThoughtWorks.CruiseControl.Remote.dll in 1.4.4SP1 which we're using) the problem is the Binary Serializer's GetAssembly Logic doesn't realize that MSBuild has performed some voodoo to load the custom assembly from an arbitrary location.
Therefore it defaults to attempting to look in the same directory that the program is located in as per http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx which means if it didn't find it in the GAC its going to start probing from where the program was launched, and because MSBuild was launched from the %FrameworkDir%/%FrameworkVersion% folder it is unlikely to find the assembly it's looking for.
This explains why you wouldn't see this issue in a console application (the assembly most likely sat right next to the console app)
The solution offered in the MSDN Forum post is also applicable here, basically they added an additional event handler to attempt to probe from a known location, again I have quoted the relevant portions:
For anyone who cares, the workaround is to register a handler for the AppDomain.AssemblyResolve event, and to the Assembly.LoadFrom() there.
Personally this scares me, but it is the only solution I have found that works, a bit more googling hasn't shown me a Microsoft Connect issue for this, but it is most likely not going to be fixed or is by design.

Did the Unity Team fix that "generics handling" bug back in 2008?

At my level of experience with Unity it might be faster to ask whether the "generics handling" bug acknowledged by ctavares back in 2008 was fixed in a public release.
Here was the problem (which might be my problem today):
Hi,
I get an exception when using ....
container.RegisterType(typeof(IDictionary<,>),
typeof(Dictionary<,>));
The exception is...
"Resolution of the dependency failed,
type = \"IDictionary2\", name = \"\".
Exception message is: The current
build operation (build key Build
Key[System.Collections.Generic.Dictionary2[System.String,System.String],
null]) failed: The current build
operation (build key Build
Key[System.Collections.Generic.Dictionary2[System.String,System.String],
null]) failed: The type Dictionary2
has multiple constructors of length
2. Unable to disambiguate.
When I attempt...
IDictionary
myExampleDictionary =
container.Resolve>();
Here was the moderated response:
There are no books that'll help, Unity is a little too new for publishers to have caught up yet.
Unfortunately, you've run into a bug in our generics handling. This is currently fixed in our internal version, but it'll be a little while before we can get the bits out. In the meantime, as a workaround you could do something like this instead:
public class WorkaroundDictionary : Dictionary
{
public WorkaroundDictionary() { }
}
container.RegisterType(typeof(IDictionary<,>),typeof(WorkaroundDictionary<,>));
The WorkaroundDictionary only has the default constructor so it'll inject no problem. Since the rest of your app is written in terms of IDictionary, when we get the fixed version done you can just replace the registration with the real Dictionary class, throw out the workaround, and everything will still just work.
Sorry about the bug, it'll be fixed soon!

According to the Unity Team:
Just wanted to let folks know we've
released the bits that have the
generics fixes in them. Take a look
and let us know what you think. It's
checked into codeplex source control.
You may need to get the latest source and build yourself (2.x) as the bug fix may not have been packaged yet.