Unity: InvalidProgramException: Invalid IL code XXX(): IL_0011 - c#

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.

Related

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.

Visual Studio 2017 TestMethod No error on run, just after

Hi diddaly hodely neighboronies!
I am currently making a test project to make sure my project is working correctly.
All of the tests work fine except one. It finishes the test with no errors as seen below...
It then updates the Passed Tests list...
However, a few seconds later when it's done it outputs this message:
An exception occurred while invoking executor
'executor://mstestadapter/v2': Object reference not set to an instance
of an object.
And the test is no longer lit up indicating passed.
Me and a friend have been googling this all day and have found the issue on a few pages, with completely different answers, none of which solved our problem.
Has anyone else had this issue and solved it? Please share!
Turned out to be a DLL that was being executed but didn't report back errors. I doubt this will help many people, but check your references and make sure it has what it's looking for. I'm assuming this is because it's using the Test path instead of the project it's tied to. Good luck to those who are haunted by this issue.
UPDATE: Yup it was the reference issue, but it is running on a separate thread. Youch! Check your threads!

Visual Studio displayed lots of errors, but there is only one actual error

I have a custom control library in my solution, where my main WPF project references it. If there is an error in the custom control library, then the error list goes mental and displayed hundreds of errors. Here is an example of one such incident.
Now this is just an error that I forced in order to demonstrate the problem.
In this case, the problem isn't so severe, as there are only 21 errors. However, there have been occasions where I have had to filter though hundreds of errors to find the actual error that's causing everything else to fail.
I believe I understand what the problem actually is. I think the problem is due to the custom control library not being built, therefore my main project can't find the dll for it, and therefore the custom controls cannot be found, which causes the errors.
Now, in truth, the error list isn't lying, I mean, these are real errors. However, that being said, is there a way to prevent this from occurring?
If I understand what you are asking, I think that this extension will help you as it stops the build as soon as an error occurs.
StopOnFirstBuildError

XMLSerializer error on compile

I'll just cut to the chase and give you some background information: Our application has quite massive startup issues, taking up to 20(!!) seconds for our webservice to respond to the first request. Everything runs quite fast after this initial lag, but the initial lag itself is quite a big problem.
At any rate, I've been doing research on the issue for the past two days or so, I have managed to get a proper log of requests sent back and forth and it turned out that the issue lies in creating XMLSerializer, which quite simply takes ages.
Now after even more googling, I have discovered the 'Generate serialization assembly' property and that it doesn't quite work properly. To force the serialization, I have followed this solution over here:
https://stackoverflow.com/a/8798289/2401855
Now that has actually worked, except... Well, it didn't. When I try to compile the webservice, Sgen throws the 'There was an error reflecting type' error and I can't quite proceed. And finally, here come my questions:
How do I get the actual error Sgen.exe has thrown? It might just help me understand what's going on better, but I was trying to look into system log files that codeproject was referring to and didn't quite find anything.
Why does the error get thrown in the first place? It gets thrown for this particular bit of code:
public class Enums
{
public enum TypNakladu
{
Prijmy = 1,
Vydaje = 2
}
public static string GetEnumDescription(Enum value)
{
FieldInfo fi = value.GetType().GetField(value.ToString());
DescriptionAttribute[] attributes =
(DescriptionAttribute[])fi.GetCustomAttributes(
typeof(DescriptionAttribute),
false);
if (attributes != null &&
attributes.Length > 0)
return attributes[0].Description;
else
return value.ToString();
}
}
'TypNakladu' is the enum that sgen doesn't seem to like. Is there any way to make sgen to just ignore this particular class, or enums contained within? (there are more, but when I comment one out, sgen just complains about the next one)
And that's just about it I suppose. I'm sorry if I'm making some incredibly dumb mistake here, I'm not very experienced when it comes to ASP.NET webservices.
Very well, now I actually have some answers, so here we go:
As for error thrown by Sgen.exe, the best way to get was to quite simply not run it via Visual Studio IDE and just navigate to the folder with my server. I didn't do it in the first place because running Sgen.exe directly gave me even more errors - turns out I've had two versions of Sgen installed on my harddrive. They came natively with two installations of Visual Studio.
Now for the error itself, problem was that there were two instances of the same enum name, as simple as that.

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.

Categories

Resources