hey there! I’m having some problems getting this to work on windows phone 8, I get this:
Error building Player: Exception: Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.Runtime.Serialization.SerializationInfo doesn’t exist in target framework.
Error: type System.ComponentModel.TypeDescriptor doesn’t exist in target framework.
Error: type System.ComponentModel.TypeDescriptor doesn’t exist in target framework.
Since windows 8 phone is quite a new release target for unity. I haven’t yet been able to verify that everything works with users. Unfortunately it seems it does not.
Have you read the Building For iPhone page in the docs? It might give you useful hints on what could help.
Also, since it says “it does not exist in the target framework”. What exactly is the target framework version? I did a search but I could not find that information.
Try to add System.Runtime.Serialization.SerializationInfo to the link.xml file (assuming you have it in the correct place as specified by the previously mentioned Build For iPhone page).
I have to admit I haven’t built for WP8 yet, but for generic WinStore 8 there’s quite a bit more than that to fix. In no particular order:
Use of Thread in AStarPath - can be ripped out and threading force-disabled.
References to System.File and System.Type throughout AStarSerialize.
Use of Thread in AStarParallel - can re-add the for loops.
I’m currently porting another product to Win Store, and the last twice I’ve done it, I’ve replaced AStar with Unity’s NavMeshAgent for the WinStore versions. And it still looks like that might be less effort than doing a port. Do you have an ETA on when you might be able to take a look at this?
It feels like the effort would be way lower if there were a way to know which bits of AStarSerialize only get called from the editor classes - then you could just wrap !NETFX_CORE around those and be done with it.
Seriously, can’t even threads be used on windows phone?? That would seriously suck. Even on iPhone, which is very restricted, I can use threads.
Well, with the above port, it has definitely worked, pathfinding has worked for a user I spoke with.
But System.Type CAN be used, definitely. The serializer uses it all the time (blaha.GetType()), if that couldn’t be used, I wouldn’t be able to do any serialization at all since I cannot know what the types of an object are. Some System.Type stuff was disabled (e.g Type.GetType, the static version) but not everything.
I should clarify. Firstly, I was talking about Windows Store, not Windows Phone. They’re surprisingly different.
Secondly, it’s not that you can’t use threads. It’s that System.Threading.Thread doesn’t exist, nor that System.Type doesn’t. It’s just that the way they’re named and accessed has changed. For example, reflection now has to go through (typing from memory) System.Reflection.IntrospectionExtensions(type).IsPrimitive, for example, rather than doing type.IsPrimitive.
Files, on the other hand, are a little more tedious - you have to use WIndows.Storage and async function calls.
So I was wondering if there was any chance you could do a Windows Store build and comment on how you’d go about the issues? Also, you don’t need to port (presumably) the whole codebase to the WinStore APIs (NETFX_CORE), because there are large parts of it that I imagine only run in the editor.
Oh man… Ok, so this means I have to add a huge lot of #if NETFX_CORE stuff everywhere. Mostly in the json serializer though. Seriously, why didn’t they just keep the Type members, the TypeInfo class is almost identical.
Most of the code is unfortunately run the the game as well. Some file io is done in the editor only, but that’s not much. The big chunk of code that would need updating is the json serializer… And do you know why Thread does not exist? Do they think that is a security risk or something and forces you to use their background workers (if I need to use that, I think most of the internal threading structure needs rebuilding as it does not fit well with background workers).
Umm, I think for Threads you have to use Windows.System.Threading, which supports a notion of a threadpool, and actually looks quite nice if you’re writing something from scratch in the Windows Store universe, which appears to be Microsoft’s base assumption with the WinRT class libraries.
As to why Microsoft decided it would be a good idea to take massive amounts of the .NET API and deprecate it so that users who have C# apps (not just Unity) already have almost as much rewriting to do to move their app to WinStore as an iOS developer using objective C, rather than perhaps leveraging the advantage of the millions of lines of C# code out there in the wild, I’m afraid that’s not for me to answer.
Anyway, the last twice I’ve shipped WinStore versions of my apps, I’ve ended up looking at porting A*, starting it, then moving the pathfinding to Unity Pathfinding for the WinStore build only, because it’s quicker for someone who doesn’t know the codebase to get up and running. If you were able to take a look, I’d be hugely grateful, as my pathfinding requirements get more complex with every app, so I’m trying to decide which way to go this time.
Aha…
Well, the problem is that I don’t have a windows phone or windows 8 (barely use windows at all in fact, though I do have windows 7 on a disconnected hard drive).
Do you know if it can be tested without that?
Well, without managing my own threads, there is no way I could allocate the specific memory needed for the individual threads. Each thread needs a specific local storage for temporary path data. Possibly by giving an index as part of the task and using a lock if several paths are trying to get calculated using the same temporary path datastructure, but that would be horribly inefficient. I guess it is best to just disable multithreading (which can be done by commenting out the CalculatePathsThreaded method in AstarPath and removing any code which call it).
No, unfortunately you have to be running Win8 to build WinStore apps, and that’s unlikely to change.
My preference, if I were to place a request, would be an A* without multithreading that works on Win8. But then, I’ve actually already done that bit locally (in a rather more hacky way by making threadCount always zero, then ripping out the Threads member.)
I’m not quite sure how the two other libraries that I use heavily got so lucky that they don’t call any Win8-forbidden API, because it’s true that a LOT of it has been changed or removed, even if we ignore the trivially fixable cases like ArrayList and Hashtable.
A quick and easy way to “fix” the compiler errors for Windows 8 for now is by setting Project -> Build Settings -> Player Settings -> Compilation Override to NONE.
This will not allow you to access any of the new features in .NET 4.5 though.
Well, yes, setting compilation override will work, with the massive caveat that you can’t ship your app (because you won’t pass WACK) until you fix all the errors anyway.
At least, that’s my understanding. I’d love to be wrong though.
Looks like things are starting to get a little more under control for windows phone, I was wondering whats the ETA was for the windows store fixes? I would hate to change back to unity pathfinding …
No idea. Working on it…
The speed of progress would be greatly increased if someone who develops for W8 could upload any dlls present at this location: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\
That would actually allow me to check which parts of my code that I cannot use. Currently I have to decipher msdn documentation pages, which aren’t that friendly for e.g searching for all obsolete members and types.
Please, if anyone has the above dlls, I would be very grateful if you could upload them or send them to me privately.
We are just about to begin a portusing A* Pathfinding and it is for Windows 8 and Windows Phone 8. Can you please clarify the current level of support for Windows Store and/or what needs to be done for fix things up?
I shipped a version of my latest app for Windows Store (note that I’m referring here to WinStore, not WP8) by moving back to the Unity Pathfinding. I spent several days trying to port A*Pro, after which I still couldn’t estimate how much work was remaining, whereas estimating time to rewrite was pretty easy. I might have got there faster by continuing to port. But I can’t say, and I might have still been nowhere.
Unity’s pathfinding has improved, and is now merely not as good as A*Pro, as opposed to completely unusable.
WinStore porting of our future projects is likely, and I’m currently deciding whether to use A* or Unity 4.3 pathfinding for our next project, as if we have to eventually do a Unity Navmesh version anyway, I may just live with its limitations rather than write pathfinding twice (which means running your game logic through QA twice!)
I’d be interested to know if anyone has shipped a WinStore8 app with A* Pro (getting it working by .NET compilation overrides doesn’t count.)