Due to the whole Chrome / NSAPI debacle, we’re trying to build an existing Unity app (using 5.0.1p3) while targeting WebGL. This isn’t a game, this is a Line-of-Business app that we used to target with the Web Player, if that matters. We do have a Pro license, but we thought that we’d try the forum first, and I DON’T think we’re trying to make use of any Pro-only features.
We’re running into some sort of problem or issue with the XmlSerializer; That is, when we run the app in the Editor, we ARE able to call a WebApi service and deserialize the response into a business entity just fine. But when we target WebGL, and view in Chrome (on Windows 8.1 x64), we (apparently, with some extensive Debug.Logging) get an exception when we call Deserialize(XmlReader xr) on the XmlSerializer.
Contributing to the problem is the fact that we can’t get any info on the exception in Chrome, since targeting a development build or trying to export exceptions causes Chrome to consistently show the “Oh, snap!” crash screen.
Is anyone out there successfully deserializing XML via a WebGL build in this fashion? Or, can anybody currently help with this? Many thanks in advance.
(We’re also encountering the “IL2CppTypeCompare” bug 650648, but we are currently circumventing this, as it’s not our primary concern at this time.)
Haven’t encountered anything like that myself, but I do know that XmlSerializer uses some “tricks” such as dynamic emitting of code (Reflection.Emit), so this may be one of those cases where it fails due to that.
WebGL is kind of similar to iOS (AOT compilation) in that sense.
Are you using a generic version of that method (Deserialize) ?
[Had to make a couple edits to the code.]
Hi, thanks for the helpful reply.
You asked about our use of Generics in the serialization logic. I decided I’d try to isolate some of this code and I hope it helps. I believe the answer is no, we’re not specifically using generic overloads of any serialization objects. You’ll a generic floating around below, but we convert it to a System.Type when we give it to the XmlSerializer.
This isn’t really pseudocode but obviously I doubt it will build, I just hope this illustrates what we’re doing for the time being. If necessary, I could create a ‘Hello World’ type project that isolates the problem, but it’ll take a bit more time.
//The Exception source.
…
static void Get (System.Action callback = null)
where T : SomethingDomainSpecific, new()
{
string theXml = “…”; //XML that we’ve deserialized in the editor, but can’t in WebGL
byte[ ] bytes = Encoding.UTF8.GetBytes(theXml);
Stream theStream = new MemoryStream(bytes);
XmlReader theReader = XmlReader.Create(theStream);
XmlSerializer theSerializer = new XmlSerializer(typeof(T));
T data = new T();
theSerializer.UnknownElement += OnUnknownElement; // OnUnknownElement is a method that conforms to the signature but does absolutely nothing.
theSerializer.UnknownNode += OnUnknownNode; // OnUnknownNode is a method that conforms to the signature but does absolutely nothing.
data = (T)theSerializer.Deserialize(theReader); // ← This is where the debug statements stop and where we believe the exception is being thrown.
if (callback != null)
{
callback(data);
}
}
…
//Here’s the ‘Entry point’. We call it from a MonoBehaviour, in the Start() method.
public void ShelfConfig (int anId, System.Action callback = null)
{
Get (callback); //ConfigBE’s our business entity in question here.
}
Did you try to create a “development build” with exception support (Full or “Explicilty thrown”) ?
This should give the correct stacktrace in the case of an exception.
[Edit: forgot words, lol]
Thanks again for tracking my problem, liortal.
That’s one of the first things we tried but unfortunately current version(s) of Chrome crash when you try to view a development build OR a build with exceptions. Consistently, in my experience. We’re focused on Chrome right now so, that’s part of the problem We did however uncover something today…
I made an object with one field (named it StupidBE!), sent the stupid XML to the Deserialize() method… and this worked! So the plot thickens, and I will be spending tomorrow tearing down our business entities (which are by no means stupid, dozens of members nested a few layers deep) trying to figure out which member or feature is causing the problem. If I’m able to determine anything concrete, I’ll report back. Again, many thanks.
Just as I was rounding the corner with a series of workarounds, 5.0.1p4 seems to have addressed enough of these problems that the project is now running. Not 100% but much of the main functionality is usable. So, a lot of us are breathing a lot easier this week, and more confident going forward.
Thanks to the Unity team for cherry picking my problem! And thanks liortal, good to hear you’re doing well on the gamedev front, I do intend to scope out your game.