thought i remember one of the speakers at a Unite saying that they already had IL2CPP working on standalone but one needed to be on the platform they were building for

Click to expand...

Im not really sure about that, maybe Unity thinks its better to quickly roll out IL2CPP to all platforms and give us the Mono upgrade faster than fix the problem with the need to be on the platform your building for.

Also microsoft recently acquired Xamarin which owns Mono so we might see the Mono upgrade come sooner since Unity and Microsoft are buddies.

Unity Technologies

Well, there are a couple of reasons why standalone player is not a target for IL2CPP yet.

First of all, today you can build windows standalone player on any platform, be it windows editor, mac editor or even linux editor. You don't need to have anything else than Unity installed (no SDKs, no compilers, nothing). With IL2CPP, you can actually only build windows standalone player on Windows, and you have to have Visual Studio + C++ compilers/SDK installed.

Secondly, standalone player is not a platform that prevents us from making the Mono upgrade, so naturally it comes as lower priority compared to the platforms that do prevent it. We want to first roll IL2CPP out to non-desktop platforms and make the only scripting backend available: that's a prerequisite for upgrading Mono.

so upgrading Mono will happen before having a IL2CPP Windows standalone build option

Click to expand...

I can't promise it, but it is likely.

Click to expand...

I'd like to hear what's the current standing on IL2CPP for Windows standalone.

To the original response, I don't quite understand the concern of not being able to compile IL2CPP content on other than target platforms, that's hardly any kind of real issue for windows game developers.

All in all, I'm bit concerned that IL2CPP on Windows standalone isn't even mentioned on the official roadmap, is it not planned at all? Or if it's in some plans, would it be realistic to expect that to happen with Unity 2017?

From the FAQ: "Does the Steam DRM wrapper work with Unity or XNA/Monogame?
No it doesn’t. Unfortunately the Steam DRM wrapper does not play well with .NET applications such as Unity and your application will likely fail to start if it’s wrapped. Even if it does succeed and work for you it will often fail on other computers."

I've not used it so I can't speak from experience, but this seems to be a common thing I'm seeing when looking into it

I'm curious though, what is the real issue that prevents this feature to be implemented yet?

According to the old talk on 2015:

Unity staff has been running Windows standalone IL2CPP a long time already (video is from 2015) and only reason mentioned on the video is that IL2CPP windows standalone toolchain could only run on windows so cross-platform compiling wouldn't work.

I really struggle to understand that reason though as every team who dev a game for windows will have a computer that runs windows.

Unity Technologies

The issue with cross-compilation is that a number of users compile standalone players for macOS or Linux from Windows (which works fine with the Mono scripting backend). That won't work with IL2CPP. Still, that is not really a big technical hurdle, we can just document the restriction.

The bigger reason why IL2CPP is not supported on desktop platforms is lack of time to make it production quality and support it. As with anything else, there are trade-offs, and we've simply not put the resources on this feature yet, as they have been used elsewhere.

Unity Technologies

The bigger reason why IL2CPP is not supported on desktop platforms is lack of time to make it production quality and support it. As with anything else, there are trade-offs, and we've simply not put the resources on this feature yet, as they have been used elsewhere.

Click to expand...

Yup, this pretty much sums it up. It's a prioritization issue right now. But we do have plans to get to it soon™.

I know that many modders will hate IL2CPP but then again, it really should be up to the devs to make the call what parts of the codebase they share with the final game. At the moment, devs don't have that choice (besides sticking everything into unmanaged native dlls).

I want to have this, since all the codes of the Windows standalone games on the Unity are de facto open source (easy hacked). I also hope for better performance. Please do IL2CPP for standalone builds!!!

While trying to link my own c++ code directly into Unity project (following setup found here: https://docs.unity3d.com/Manual/windowsstore-plugins-il2cpp.html ) I don't actually get the Platform settings to show up for Windows standalone (no settings show under it so I can't even select x64), I only see the options for Unity Editor. Is this functionality implemented in 2018.1 beta and if not, will it be done for the final 2018.1?

I'm getting errors for unresolved external symbols for my native functions so it didn't include the files in build. When using external native DLL without __Internal, IL2CPP works but would prefer the internal method to minimize the overhead.

Unity Technologies

While trying to link my own c++ code directly into Unity project (following setup found here: https://docs.unity3d.com/Manual/windowsstore-plugins-il2cpp.html ) I don't actually get the Platform settings to show up for Windows standalone (no settings show under it so I can't even select x64), I only see the options for Unity Editor. Is this functionality implemented in 2018.1 beta and if not, will it be done for the final 2018.1?

Click to expand...

I'm guessing not. Can you report a bug? It slipped through my radar - but I will do the best to fix it if you tell me the case #!

Unity Technologies

I would like to try the new IL2CPP on Windows build using Unity 2018.1.0b2. However, when I select it as the Scripting Backend, on the Build Settings it shows: "Currently selected scripting backend (IL2CPP) is not installed".

I uninstalled VS 2017 and installed it again with the Windows 10 SDK, VC++ 2017 v141 toolset, C++ profiling tools and Just-In-Time debugger. But it's still showing the same message on Unity ("Currently selected scripting backend (IL2CPP) is not installed"). Am I missing something?

I would like to try the new IL2CPP on Windows build using Unity 2018.1.0b2. However, when I select it as the Scripting Backend, on the Build Settings it shows: "Currently selected scripting backend (IL2CPP) is not installed".

I uninstalled VS 2017 and installed it again with the Windows 10 SDK, VC++ 2017 v141 toolset, C++ profiling tools and Just-In-Time debugger. But it's still showing the same message on Unity ("Currently selected scripting backend (IL2CPP) is not installed"). Am I missing something?

Make sure that c++ build tools are selected when you run the installer. Not sure if VS2017 selected those automatically, I know VS2015 made you pick those manually or you didn't get c++ building support.

Yeah, that sounds like C++ tools in VS2017 aren't installed. And they're not enabled by default.

Click to expand...

Talking of which, might be worth changing the defaults from the Unity installer to include these tools when you install VS2017 with it. I think it's now silent install (I could remember it wrong) so users don't get the option to pick the c++ build tools with it.

This would avoid a lot of confusion amongs new users in the future as people have gotten used to that when they install unity and platforms, things just work out of the box.

Hmmm, are we supposed to be able to include .lib? I tested it again and Unity Editor doesn't even recognize the file type.

I'd essentially want to replace my native dll with something that gets compiled into final game dll but including each cpp and h separately is kinda tedious, so including just a static library would solve this (as I could use similar setup as now with the dll).

As a side note, .obj is not going to work either as unity thinks it's a mesh in that case.

Unity Technologies

.lib files are complicated because they must be linked against code that was compiled with the same C++ compiler. The way IL2CPP works is that it tries to detect any il2cpp compiler and will use the newest that is installed on the machine. So if you build your .lib file with VS2010, VS2012 or VS2013 and you have VS2015 installed on your machine, IL2CPP will use VS2015 to build generated source code and will error out at link stage because compiler versions didn't match. Same will happen if you build .lib file with VS2017 and then only have VS2013 installed when building your project from Unity.

.lib files are complicated because they must be linked against code that was compiled with the same C++ compiler. The way IL2CPP works is that it tries to detect any il2cpp compiler and will use the newest that is installed on the machine. So if you build your .lib file with VS2010, VS2012 or VS2013 and you have VS2015 installed on your machine, IL2CPP will use VS2015 to build generated source code and will error out at link stage because compiler versions didn't match. Same will happen if you build .lib file with VS2017 and then only have VS2013 installed when building your project from Unity.

Click to expand...

Yeah, I guess it's tricky if you just allowed it out of the box, considering people might try all kinds of things with it. But I already thought about workaround to not having unity UI include the lib support. One could just throw in a dummy header that has something like

#pragma comment(lib, "mylibrary.lib")

Click to expand...

and it should do the job, unless you guys filter out this kind of preprocessor commands (I hope not).

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.