Which I believe has been mentioned prior as well, Unity GUID's not matching the DLL GUID. 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. In all seriousness, something so simple should not be so dang'd complex/confusing.ĮDIT: Checked VS, yes it has a GUID as expected which has 1 value. Maybe it's that, that is part of the problem? CS & Version.TXT file from Unity 5 over to Unity 3 for submission for backwards compatibility. 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.
However ALL 4 files are being incremented when updated. (I'm getting ready to load VMware up and check the DLL project in VS as we speak.)Ģ- The only other files in the folder are (1). So it does seem to be related to the included DLL's of the asset packages.ġ- My DLL file has not changed since it was made, so if VS assigned a GUID it has not changed either. I did test by importing my scripts without the included DLL and there was no issue. I've tested this with updating other assets as well and noticed the same IF it included a DLL. The GUID for Assets/GrabYerAssets/Editor/ is already in use by Assets/GrabYerAssets/Editor/GYAInternal.Json 1.dll. Created unique file for imported asset as file exists with different GUID (Assets/GrabYerAssets/Editor/GrabYerAssets.cs => Assets/GrabYerAssets/Editor/GrabYerAssets 1.cs) Instead of replacing the existing script and DLL it creates new incrementally numbered files which immediately causes a conflict as follows:
How do i move slate vcc dll to another folder update#
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: With beta 18, it still works with one exception that I can tell so far. In all versions prior including up to beta 13, the import worked as expected. I can confirm that this is an issue with at least Beta 18 as I didn't notice it in Beta 13.ĪssetDatabase.ImportPackage(pFilePath, pInteractive) The ticket number is 652856_2trm2veihjr1r54m 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.Įdit2: I've submitted a bug report on this issue.
This message is printed in the console after these steps:Ĭreated unique file for imported asset as file exists with different GUID (Assets/Events.dll => Assets/Events 1.dll) 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. 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.Įdit: The issue appears to be that the GUID is different for the DLL's, so it is creating a copy. 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. 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.
0 kommentar(er)
