New PluginInspector issues

Hi,

I am having multiple issues with the new plugin inspector functionality.

1. 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.
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:
   
   Code (CSharp):

   1. public static void ActivatePlugin(string platformToActivate)
   2. {
   3.     PluginImporter[] importers = PluginImporter.GetAllImporters();
   4.    
   5.     foreach(PluginImporter pluginImporter in importers)
   6.     {
   7.         if( !pluginImporter.assetPath.Contains("MySpecialFolder") )
   8.         {
   9.             continue;
   10.         }
   11.        
   12.         // Get the platform string from the path (each plugin is in its own folder named after the platform)
   13.         string pluginPlatform = GetPluginPlatformFromPath(pluginImporter);
   14.         if( pluginPlatform != platformToActivate && platformToActivate != ALL_PLATFORMS )
   15.         {
   16.             continue;
   17.         }
   18.        
   19.         // Translate to Unity built-in platform enum. This is just a snippet ignoring architectures.
   20.         string editorCPU = string.Empty;
   21.         string editorOS = string.Empty;
   22.         List<BuildTarget> targetsToSet = new List<BuildTarget>();
   23.         bool setEditor = false;
   24.         switch (pluginPlatform)          
   25.         {
   26.         case "Android":
   27.             targetsToSet.Add (BuildTarget.Android);
   28.             break;
   29.         case "iOS":
   30.             targetsToSet.Add (BuildTarget.iPhone);
   31.             break;
   32.         case "Linux":
   33.             targetsToSet.Add (BuildTarget.StandaloneLinux64);
   34.             targetsToSet.Add (BuildTarget.StandaloneLinuxUniversal);
   35.             break;
   36.         case "Mac":
   37.             targetsToSet.Add(BuildTarget.StandaloneOSXIntel);
   38.             targetsToSet.Add(BuildTarget.StandaloneOSXIntel64);
   39.             targetsToSet.Add(BuildTarget.StandaloneOSXUniversal);
   40.             editorCPU = "AnyCPU";
   41.             editorOS = "OSX";
   42.             setEditor = true;
   43.             break;
   44.         case "Windows":
   45.             targetsToSet.Add (BuildTarget.StandaloneWindows64);
   46.             editorCPU = "X86_64";
   47.             editorOS = "Windows";
   48.             setEditor = true;
   49.             break;
   50.        
   51.         /* ... */
   52.         /* Insert many platforms here... */
   53.         /* ... */
   54.        
   55.         default:
   56.             Debug.Log ("Unknown platform: " + pluginPlatform);
   57.             break;
   58.         }
   59.        
   60.         // Reset the platform settings
   61.         pluginImporter.SetCompatibleWithAnyPlatform(false);
   62.         pluginImporter.SetCompatibleWithEditor(false);
   63.        
   64.         // Activate this plugin
   65.         foreach(BuildTarget target in targetsToSet)
   66.         {
   67.             pluginImporter.SetCompatibleWithPlatform(target, true);
   68.         }
   69.        
   70.         if( setEditor )
   71.         {
   72.             pluginImporter.SetCompatibleWithEditor(true);
   73.             pluginImporter.SetEditorData("CPU", editorCPU);
   74.             pluginImporter.SetEditorData("OS", editorOS);
   75.         }
   76.     }
   77. }
3. 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?

 

i think its a bug, on my side the inspector changes will be restored to All Platforms when restarting unity.

 

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:

1) Create a new project (Project 1) and drag a DLL into the assets folder.
2) Update the DLL (added new method to one of the classes) and rebuild.
3) Create another new project (Project2) and import the updated DLL into it.
4) Export the DLL from Project 2 as a Unity Package.
5) 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 have reported it as a bug as well.

 

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.

 

My report was closed as it was considered a duplicate report.

 

Just did a quick test on b19 and it seems to be fixed from what I can tell. I'll do some more testing and report back later on.

I'll have to wait till later to download/test b20, metered bandwidth here.

UPDATE: Yes, this is still occuring with the latest beta.

 

I was running beta 18 - will try 19 now.

 

Yes, Importing a package containing a script, several images, and DLL still creates duplicate files as of 5b20.

 

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...

Is there an open bug about this?

 

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.

 

VS does this for you automatically. And besides, as I mentioned earlier in this thread the issue persists even when the GUIDs are the same.

 

karl-

Ah yes, had forgotten you mentioned that, sigh.

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."

In that case, I am eagerly awaiting THIS! Grin.

 

Here is the message I was sent regarding this issue:

So it sounds like it is indeed to the meta file's GUID that needs to be adjusted rather than the DLL's GUID. If anyone figures it out, let us know. I tried contacting the person who sent me this email but have not received a response.

To be honest I don't really understand the reasoning. Most if not all Asset Store publishers store their assets in a specific folder structure, and files are only overwritten if the folder structure of one package matches another (correct?). I have yet to see two packages that have matching folder structures. This seems like an unnecessary change for an issue that will be relatively rare, but perhaps I am overlooking something.

 

Haha, that would be nice

I'm wondering if this change was intentional, or if it is a bug. If it's intentional, what do they expect Asset Developers to do about upgrading? Just adopt the mindset of requiring a clean slate every time you import a new version to the project? (Though this doesn't help if you have multiple assets using a 'Shared' folder).

Alternatively, could Unity provide a way of making certain that the GUID in metadata does not change unless there are actual changes to the asset?

 

The change was intentional, see post above yours.

I'm not sure what you mean by your last sentence. If there's a change to the asset, wouldn't we want the GUID to stay the same so that the asset is overwritten by the "altered" asset (rather than creating a new copy)?

 

Oops, yes - I meant the opposite of what I said. Thanks gilley033.

 

Here's what gets me:

1- My DLL file has not changed since it was made, so if VS assigned a GUID it has not changed either. (I'm getting ready to load VMware up and check the DLL project in VS as we speak.)
2- The only other files in the folder are (1) .CS file and (2) .TXT files. Typically, I update the .CS and the Version.TXT file. However ALL 4 files are being incremented when updated. I don't get it.

Maybe this is a partial cause of the isuee, no clue: After I've done all my coding for a recent update, I copy my .CS & Version.TXT file from Unity 5 over to Unity 3 for submission for backwards compatibility. The DLL and other .TXT file remain unchanged. Maybe it's that, that is part of the problem?

*Scratches head in befuddlement. This is gonna drive me to drink.

In all seriousness, something so simple should not be so dang'd complex/confusing.

EDIT: Checked VS, yes it has a GUID as expected which has 1 value. Then checked Unity by running: "AssetDatabase.AssetPathToGUID" for the DLL file from within the asset under both versions of Unity 3&5 and both return differing GUID's. Which I believe has been mentioned prior as well, Unity GUID's not matching the DLL GUID. So 3 differing values in all.

 

Here is what I did and it seems to have resolved the issue.

1) Enable Meta files via Edit -> Project Settings -> Editor -> Version Control (Visible Meta Files).
2) Make a copy of your project that contain the DLL's/other files that are having the duplication issues.
3) Upgrade the copy to Unity 5.
4) Examine the meta files of the problem files. The GUID of these files will have changed. For each file, open the meta file in the original pre-upgrade project and set it's GUID to the GUID of the file from the upgraded project, saving each file. The project will recompile after each save (assuming you click on the project after saving).
5) Now, if you upgrade the original project to Unity 5, the GUID's remain the same. I am guessing they used a different algorithm to assign the GUID's in Unity 5, but this algorithm is only used on some files (DLLs for example), while most other files retain their GUID's from Unity 4.

When you update a DLL or other problem file in your base project (the one you're using to submit to the Asset Store), you may need to make sure the GUID doesn't get reset to a different value. It might be a good idea to store all the Unity 5 GUID's in a file so you can check this.

Again, this is what seems to work for me. I'm not saying it is THE solution to this problem. Please post if this works for you!

 

I see what you mean, I reimported multiple old versions of my project into Unity 3 to check the GUID's in play and they remained stable. Import into Unity 5 and viola, it changes as you mentioned.

Just messed with it a bit more even going so far as to delete my assets folder structure and reimport the asset, and received an error complaining about the GUID's of the folders already being assigned even though they had been deleted prior. I think that this is going to be a very interesting issue.

I'll do some further testing later on.

 

Just an update my this: I submitted a bug report yesterday, and I got the same answer as you all : "Use GUIDs". Here is the link to my bug report: http://fogbugz.unity3d.com/default.asp?668098_97vecbckutdr7hrv

 

I see you have done some testing and found that different projects produce different GUIDs for the same asset. Were the projects using the same version of Unity?

I any event, I'd be interested to see how they respond to the issue of not knowing what the GUID is on a client's machine. How are we suppose to ensure our GUID matches when it could be anything?

 

All my testing was done using B21. I might be doing something wrong in my packaging process, but the fact remains that I have clients in the wild with my package, and random GUIDs.

 

Hopefully they have some sort of secret method to ensure the GUID's are all the same . . .

Otherwise, this change will have to be reverted. There is just no way the threat of files from different packages overwriting each other is great enough to warrant the headache that this change will cause.

If a Unity employee wants to chime in on this issue, I know we would all really appreciate it.

 

Well, I think they might be looking into it, from the latest update in my bug report...
http://fogbugz.unity3d.com/default.asp?668098_97vecbckutdr7hrv

 

bsanterre-

Good to hear. This change is certainly an annoyance. Add in the undocumented steps that seem to be required to account for this when distributing a pkg from Unity 3 or 4 and it just compounds the issue.

Hopefully it all gets sorted out and things go back to being simpler again.

 

This is a horrid change.

1. open new project
2. import megafiers
3. import megashapes

As these libraries share files, it becomes a nightmare of conflicts instead of smoothly overwriting like in older versions. To solve, I have to import each unitypackage to it's own project, then manually merge and overwrite files in my main project. I have to do this every single update, and updates are frequent. It's a chore and frankly, not something I'm interested in letting go on much further, so it's easier to just skip using asset store.

Optional pop/checkbox suggestion for import:
When it happens with high profile assets like megafiers and megashapes, surely it's a problem solved by having an import checkbox for this sort of thing, so that unity can overwrite the files and merge guid's in the project, specifically scanning the imported assets and resolving conflicts by changing guid for all imported assets to match.

Done optionally should work fine with source control and in upgrading. You should understand what a stressful chore it is updating assets which share resources with this new behaviour.

 

Thanks for the in-depth answer, but is there detailed documentation on how we can make the GUID the same through many iterations of the same package? In the bug report I submitted, I mention that I took my package, and imported it in three different projects. For each different project, the GUID was different.

People keep saying that the real way to identify a file is by its GUID, but never say HOW we can ensure the GUID stays the same. Also, my package is already on people's machines. If the fix to having a consistent GUID is through the packaging process, then it's too late for all my clients; they will have duplicate files when they upgrade to Unity 5.

Yes, the behavior we see in Unity 4 might be a bug in your eyes, but Unity has been acting like this for so long that people have started relying on this. This is a huge change, and will cause many problems to people not participating in the Unity 5 beta.

 

Any hints on how one goes about doing this?

 

Everything.

 

My problem is that, right after package import, I rename and delete files in order to do the proper installation steps. I need to do this because after my package has been imported, I can have various situations:
- Brand new installation
- Update of an existing package
- Addition of a new platform (I have one package by platform. To install additional platforms, you import a new package).

My post import script (called by a DidReloadScripts callback) determines in what situation we are, and renames files accordingly. This where the problem arises: when renaming the file, I don't control what GUID is given to the renamed file.

I just did a test with a package created in Unity 5, imported in two different empty projects. After my installation procedure, all files have a different GUID between the two projects.

As I said: the old package import behavior has been there forever, and people (including me) have be using it for a long time. If you don't want to bring it back, we need an easy way to reproduce the old behavior.

 

I haven't tested 3.X to 5.X, but 4.0 to 5.X definitely changes the GUID for my DLL's.

To be honest, I don't really understand how we can ensure the GUID's are the same for all users. I mean, aren't they just assigned randomly? When a user imports my package from the asset store, isn't there a very small chance that a GUID from an asset in my package conflicts with the GUID from an asset in their project? Or perhaps I am not understanding the GUID assignation process.

The main advantage to your approach seems to be the ability to have multiple files with the same name in the same folder. While this sounds great, it seems insignificant in the face of the massive issues this "bug fix" will cause for asset store publishers. Hopefully though, the current issues are caused by a bug, in which case a guide on how to ensure the GUIDs remain consistent would be very much appreciated.

 

Isn't it actually a niche case to have filenames of the exact same name in the same folder (with same extension) ?

 

So if one wanted to be able to share source files in different assets one has to find all the meta files for every source file and manually change the meta files so that each and every GUID matches between those assets? Great fun for assets that share hundreds of files.

 

With this goal in mind, can you explain the best way to update a DLL file? The Reimport command does not work properly with DLLs, and importing a new version of the DLL into a project (via Import New Asset) creates a duplicate rather than overwriting the existing DLL. To avoid this, I have to delete the old file and then import the updated one. In addition to some other issues, this results in the DLL getting a different GUID, so I'll have to manually reassign the correct GUID every time in order to comply with the new specifications.

Fixing the Reimport command would be the best option, but perhaps there is some other work flow that I am missing? Thanks!