En este punto en el tiempo, el modelo de plugin para Windows Store con IL2CPP scripting backend es mucho más similar a otras plataformas de Unity (como un Windows standalone), en vez de Windows Store con .NET scripting backend.
A diferencia del .NET scripting backend, IL2CPP scripting backend no soporta managed plugins si se apunta a .NET 4.5 o cualquiera de las Windows Runtime APIs. Todos los managed plugins deben estar apuntando a .NET 3.5 o un API equivalente.
Otra diferencia comparada a .NET scripting backend es que IL2CPP scripting backend expone la misma .NET API surface que el editor de Unity o el standalone player, por lo que es posible utilizar los mismos plugins sin necesidad de compilar distintas versiones orientadas a diferentes API .NET para Windows Store.
El IL2CPP scripting backend soporta el uso de plugins nativos a través del mecanismo de P/Invoke . Esto significa que puede llamar a los plugins nativos directamente desde su código C# especificando el prototipo de función nativa y luego llamarla. Por ejemplo:
[DllImport("MyPlugin.dll")]
private static extern int CountLettersInString([MarshalAs(UnmanagedType.LPWSTR)]string str);
private void Start()
{
Debug.Log(CountLettersInString("Hello, native plugin!"));
}
La implementación de tal función dentro del MyPlugin.dll se vería así:
extern "C" __declspec(dllexport)
int **stdcall CountLettersInString(wchar_t* str)
{
int length = 0;
while (*str++ != nullptr)
length++;
return length;
}
Las reglas de ordenación P/Invoke coinciden aquellas del ordenamiento .NET oficial, con excepciones de unos pocos tipos no soportados:
La convención predeterminada de llamado para funciones P/Invoke en x86 es **stdcall
.
Los Native Plugins pueden ser autorizados en dos maneras: DLL precompiladas o código fuente C++.
P/Invoking a unos plugins nativos precompilados funciona al cargar el DLL en tiempo de ejecución, encontrando el punto de entrada de la función y luego llamarla. Estos DLLs deben estar compilados contra el Windows SDK apropiado para la arquitectura CPU objetiva. Los DLLs también deben estar configurados en el Plugin Inspector cuando se agregue al proyecto de Unity.
Es posible agregar archivos de código C++ (.cpp) directamente a su proyecto de Unity, que funcionará como un plugin en el Plugin Inspector. Si es configurable para que sea compatible con Windows Store y IL2CPP scripting backend, estos archivos C++ serán compilados juntos con el código C++ que es generado de managed assemblies:
Ya que las funciones están enlazadas juntas con código generado C++, no hay un DLL separada para P/Invoke. Debido a esto, es posible utilizar la palabra clave “__Internal” en lugar del nombre del DLL, que haría que la responsabilidad del C++ Linker resuelva las funciones, en vez de cargarlas en tiempo de ejecución:
[DllImport("__Internal")]
private static extern int CountLettersInString([MarshalAs(UnmanagedType.LPWSTR)]string str);
Ya que la llamada está resolvida por el linker (enlazador), crear un error en la declaración de la función en el lado managed producirá un error de linker (enlazamiento), en vez de un error en tiempo de ejecución. Esto también significa que no hay necesidad de que una carga dinámica tome lugar en tiempo de ejecución, y la función se llama directamente. Esto decrece significativamente la sobre carga de una llamada P/Invoke.
En Windows Store usted no puede P/Invoke a librerías del sistema específicas especificando el nombre dll (como “kernelbase.dll”) cuando utilice IL2CPP scripting backend. Intentar P/Invoke a cualquier DLL que exista afuera del proyecto resultará en un DllNotFoundException en tiempo de ejecución.
No obstante, es posible P/Invoke a estas funciones del sistema, especificando la palabra clave “Internal”" en vez del nombre del DLL, que resulta en un linker (enlazador) que resuelve las funciones en el tiempo de construcción.