I've added the necessary using statement. using System.Collections.Generic to the top of my class and the compiler happily accepts my use of Lists, but when I'm debugging I'm getting a very weird debugging problem in that when I expand my lists instead I get:
unknown type 'System.Collections.Generic.CollectionDebuggerView'1 mscorlib.
What possible reasons could there be? Google didn't seem to help me...
The lists do seem to declare their information when declared and empty and they are defined with a class I've created, but I've never seen this issue in any other toolkit such as XNA etc.
I shoudl also mention that this is through MonoDevelop I see this error.
Thanks.
It was a bug in Mono according to these release notes. It's patched in 2.10.2, but Unity isn't using the patched Mono build.
679586: Unknown type System.Collections.Generic.CollectionDebuggerView
error when viewing Parametrized collection in debugger
Unity uses Mono 2.6. Without access to the source for Unity, I'm not sure how you can implement that patch. Even with the source, 2.6 is still the stable build so 2.10.2 so it may cause issues elsewhere.
Used .ToArray() method to convert my List<T> to T[] array. Just don't forget to sweep this code in release!
Quick and dirty workaround which works for me:
private class CellList : List<Cell> {}
Somehow it displays correctly in debugger.
Related
First, this is not a duplicate of this question as I am Linking everything and It keeps not working.
The problem occurs on a Xamarin.Forms App, I am passing a Type that extends a .NetStandard abstract class to be able to invoke a native implementation by the Xamarin.Forms common project.
At this time the project can't find any constructor of the type.
If I use GetConstructor with the right types it will return null.
If I use GetConstructors it will return an empty list.
Is anyone able to tell me how can I make the project able to find the constructor and why It's not working at the moment?
Please take note, "Use the DependencyService" is not an answer since It will not cover the questions I made.
I want to know the reason why It's not working and how to use this functionality, not any other alternative.
By the way. I had a project where It worked but to my eyes, there were no differences except the Native target platform OS version and the Xamarin.Forms version.
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.
Since I pull my project from GitHub and attempt to run my app the problem keep happening when it refers to Json.net when trying to serialize anything. Originally it was at version 11 when the error showed up, then I tried to downgrade to version 8 and it still persists. So, I upgrade to latest on 12.0.1 but the problem still not going away
The code is nothing but Newtonsoft.Json.JsonConvert.SerializeObject(data)
And no matter what type of data it is it always thrown
FieldAccessException: Attempt by method
'Newtonsoft.Json.JsonSerializerSettings..cctor()' to access field
'Newtonsoft.Json.JsonSerializerSettings.DefaultContext' failed.
I even tried to construct the JsonSerializerSettings on my own and that still happens.
Will this answer help you?
Basically, in order to workaround this problem you need to make sure "Enable the Visual Studio hosting process" is unchecked in your project's settings under Debug.
This error may occur if the code is running under partial trust. Following link can help more in providing error description:
https://learn.microsoft.com/en-us/dotnet/api/system.methodaccessexception?redirectedfrom=MSDN&view=netframework-4.7.2
Previously, I have encountered this error if the code has restricted access like private, protected or internal methods. As per MSDN:
This exception is thrown in situations such as the following:
A private, protected, or internal method that would not be accessible from normal compiled code is accessed from partially
trusted code by using reflection.
A security-critical method is accessed from transparent code.
The access level of a method in a class library has changed, and one or more assemblies that reference the library have not been
recompiled.
I have a project - ASP.NET portal coded/built on Mono/Linux. I have recently moved from using a class from the project for a [nearly] identical version of the class from inside a DLL assembly.
Used to get a collection of initialized objects, and now I get nulls. Is this because my class is now inside a DLL? Is there a problem passing List as a return type from a method inside an assembly?
What can it be, and more importantly can should I do?
Thank you
The problem was a someone who refactored my messing this up in a very unconventional way. There is no problem passing arrays.
It is perplexing to see that such an innocent question drew so many haters.
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.