I am having multiple issues with the new plugin inspector functionality.
By default, importing a plugin makes it available for all platforms. This is a problem because I have a version of my plugin for multiple platforms, and some are sharing the same name (MyPlugin.dll). This creates errors when I import my plugins from a .unitypackage.
I have written a script using the new PluginInspector class to properly set all platform settings correctly. After the script is done running, the Plugin Inspector shows the correct settings, but if I look at the associated .meta file in an external text editor, the changes are not persisted. Closing and reopening the project confirms this (after reopening the project, none of the platforms have their checkbox checked in the inspector window). Here is the general flow for setting the platforms for a plugin:
public static void ActivatePlugin(string platformToActivate)
{
PluginImporter[] importers = PluginImporter.GetAllImporters();
foreach(PluginImporter pluginImporter in importers)
{
if( !pluginImporter.assetPath.Contains("MySpecialFolder") )
{
continue;
}
// Get the platform string from the path (each plugin is in its own folder named after the platform)
string pluginPlatform = GetPluginPlatformFromPath(pluginImporter);
if( pluginPlatform != platformToActivate && platformToActivate != ALL_PLATFORMS )
{
continue;
}
// Translate to Unity built-in platform enum. This is just a snippet ignoring architectures.
string editorCPU = string.Empty;
string editorOS = string.Empty;
List<BuildTarget> targetsToSet = new List<BuildTarget>();
bool setEditor = false;
switch (pluginPlatform)
{
case "Android":
targetsToSet.Add (BuildTarget.Android);
break;
case "iOS":
targetsToSet.Add (BuildTarget.iPhone);
break;
case "Linux":
targetsToSet.Add (BuildTarget.StandaloneLinux64);
targetsToSet.Add (BuildTarget.StandaloneLinuxUniversal);
break;
case "Mac":
targetsToSet.Add(BuildTarget.StandaloneOSXIntel);
targetsToSet.Add(BuildTarget.StandaloneOSXIntel64);
targetsToSet.Add(BuildTarget.StandaloneOSXUniversal);
editorCPU = "AnyCPU";
editorOS = "OSX";
setEditor = true;
break;
case "Windows":
targetsToSet.Add (BuildTarget.StandaloneWindows64);
editorCPU = "X86_64";
editorOS = "Windows";
setEditor = true;
break;
/* ... */
/* Insert many platforms here... */
/* ... */
default:
Debug.Log ("Unknown platform: " + pluginPlatform);
break;
}
// Reset the platform settings
pluginImporter.SetCompatibleWithAnyPlatform(false);
pluginImporter.SetCompatibleWithEditor(false);
// Activate this plugin
foreach(BuildTarget target in targetsToSet)
{
pluginImporter.SetCompatibleWithPlatform(target, true);
}
if( setEditor )
{
pluginImporter.SetCompatibleWithEditor(true);
pluginImporter.SetEditorData("CPU", editorCPU);
pluginImporter.SetEditorData("OS", editorOS);
}
}
}
After enabling a plugin for Editor use (using the Plugin Inspector window, and clicking “Apply”), Unity still does not find it (I get a DllNotFoundException when I run the game). I need to close and reopen the project for it to be found.
This is all on b10. Is there a list of known issues for the beta?
By default, importing a plugin makes it available for all platforms. This is a problem because I have a version of my plugin for multiple platforms, and some are sharing the same name (MyPlugin.dll). This creates errors when I import my plugins from a .unitypackage.
There’s no way for Unity to know which platforms are compatible with your plugin, unless you place plugin in specific folder, like for ex., Assets\Plugins\Android, but I guess your case is different. That’s why you need to set settings manually.
2.I have written a script using the new PluginInspector class to properly set all platform settings correctly. After the script is done running, the Plugin Inspector shows the correct settings, but if I look at the associated .meta file in an external text editor, the changes are not persisted. Closing and reopening the project confirms this (after reopening the project, none of the platforms have their checkbox checked in the inspector window). Here is the general flow for setting the platforms for a plugin:
After enabling a plugin for Editor use (using the Plugin Inspector window, and clicking “Apply”), Unity still does not find it (I get a DllNotFoundException when I run the game). I need to close and reopen the project for it to be found.
A somewhat related issue; when you try to import an updated package into a project, and that package contains a DLL, the DLL from the package is added as a duplicate rather than replacing the existing DLL.This really needs to be fixed, as it will cause major issues for Asset Store publishers.
The issue is that the pre-existing DLL will have to be removed before importing the new DLL, and if the DLL contains custom editors, the inspectors for existing components will stop working.
If a dll is imported with the same folder structure as an existing dll, and the dll to be imported has no plugin platform data, I think it’s a pretty fair assumption that the user is intending to overwrite the existing dll with the new dll.
Edit: The issue appears to be that the GUID is different for the DLL’s, so it is creating a copy. I came to this conclusion after performing the following actions:
Create a new project (Project 1) and drag a DLL into the assets folder.
Update the DLL (added new method to one of the classes) and rebuild.
Create another new project (Project2) and import the updated DLL into it.
Export the DLL from Project 2 as a Unity Package.
Import the package from step 4 into Project 1.
This message is printed in the console after these steps:
Created unique file for imported asset as file exists with different GUID (Assets/Events.dll => Assets/Events 1.dll)
I hope this is a bug or I am missing something, as this is going to be an issue for a lot of Asset Store publishers that use DLL’s.
Edit2: I’ve submitted a bug report on this issue. The ticket number is 652856_2trm2veihjr1r54m
I can confirm that this is an issue with at least Beta 18 as I didn’t notice it in Beta 13.
For example:
When importing a package as such:
AssetDatabase.ImportPackage(pFilePath, pInteractive);
In all versions prior including up to beta 13, the import worked as expected. With beta 18, it still works with one exception that I can tell so far. When it is called by my script to import and thereby update itself with a newer version, it now sort of works with the following message and results:
Instead of replacing the existing script and DLL it creates new incrementally numbered files which immediately causes a conflict as follows:
Created unique file for imported asset as file exists with different GUID (Assets/GrabYerAssets/Editor/GrabYerAssets.cs => Assets/GrabYerAssets/Editor/GrabYerAssets 1.cs)
The GUID for Assets/GrabYerAssets/Editor/GYAInternal.Json.dll is already in use by Assets/GrabYerAssets/Editor/GYAInternal.Json 1.dll. Assigning a new guid.
I’ve tested this with updating other assets as well and noticed the same IF it included a DLL. I did test by importing my scripts without the included DLL and there was no issue. So it does seem to be related to the included DLL’s of the asset packages.
I’m running into this issue as well, do you have a link to the case in the Issue Tracker? I’d like to vote up yours instead of filing a duplicate ticket.
I was told this is not a bug, and the only way to avoid this is by assigning a GUID to the DLL (in the assembly file). I haven’t actually tested whether it still creates a duplicate DLL with a GUID assigned.
Obviously this will cause some issues for Asset Store publishers. Our best bet will be to have users update the package with a version that includes a GUID prior to upgrading their project to 5.x.
Oh, shoot. That does cause some problems. We have a shared folder that almost all of our packages import - so the idea now is to assign a matching GUID for all those assets prior to export?
A quick search through the docs don’t bring up any API to do this, so what’s the correct procedure?
The GUID should only be assigned to your DLL’s I believe. You assign it in the AssemblyInfo file and compile your dll after. At least, this is what I believe you’re suppose to do. I’ll test it this week to see if it works. Just search for DLL GUID, its not a Unity specific thing and I’m not sure exactly how you do it.
Unless there’s a GUID in the meta info of the assets and that’s what the guy was talking about. Again, I’ll test it is his week to find out what’s what.
Unity has a GUID in the meta file, and there’s also a Visual Studio GUID. I don’t think they’re the same thing.
Unity GUID (in meta file): e2458a2895fde2741979e5e553c3cd0f
Visual Studio (in Assembly Info): 9469539c-258c-4136-8b2f-5af3c97181f9
I also checked the GUID in my DLLs that are getting duplicated, they are the same (VS assigned), so it’s definitely Unity’s GUID value clashing.
It’s possible to access the meta files and manually re-write the GUID field, but that seems like a bad idea without at least knowing how Unity generates the hash (not to mention the other risks).
Also worth noting - I’ve tried building packages from Unity 4.6 only, mix of Unity 4.6 & Unity 5, and just Unity 5. All iterations create duplicate items.
Okay, I contacted the developer who worked on my case in the hopes of getting clarification on how to configure the GUID’s so that new versions of a package overwrite existing versions. I’ll post when I receive a response, or maybe another developer will chime in on how to do this.
I’m having the same issue about the duplicated files. Using B21, importing a package duplicates any file that has the same name already in the project (.cs files, .png files, .dll files, anything).
The problem about the GUID “fix” is that my .unitypackage will be sent to clients that already have an older version, and I have no way of knowing what the GUID of the files on the client’s machines is, so I can’t set the correct GUID before packaging…
I can relate bsanterre, just imported my updated asset back into my own project and it did the same thing. Time to look into how to properly assign a GUID to a DLL and recompile it I guess.
When I find anything useful, I will post in the forum.
So basically what it boils down to is that we need for Unity to say “Hey, we require THIS to be done otherwise packages imported in Unity 5 will NOT update properly.”