Renaming script files with Unity is russian roulette every time. I did it from visual studio with the dedicated renaming tool on a file test and went good. I went on an important one with many instances and it broke all meta files. I reversed the name but too late. I don’t now what to do now. When I open the scriptable object file with a text editor, I can see all parameters are ok. but in the editor there are all initialized to zero. the meta file is here and has same name. What is happening and how I fix this ?
I routinely modify the names of Unity class files due to incessant refactoring. I follow a pattern and have never had an issue. First don’t rename files outside of Unity, have Unity rename them. It will keep any required links up-to-date.
So I rename the .cs file, open the file with VS and edit the class name. VS in this case is the perfect tool for renaming a class as it will update the change across the project. Save of course and then rename the meta file using Unity so the two files match again.
I don’t know how you can “fix” things if they got messed up but you should endeavor to make a backup copy before embarking on anything experimental. And that can mean before importing a new asset and/or making modifications that can affect the entire project. Dumping the broken project and renaming the folder with the backup is a whole lot easier.
I sometimes have multiple copies if I’m working on a rewrite and then need to test some new idea, etc. Things go wrong it is best to have a restoration point.
1 Like
ok first rename in Unity then in visual studio. i will go with this now 
Here’s my version of what tleylan says above:
SCRIPTS OR ASSETS ARE MISSING OR BLANK
ALWAYS move all Unity assets by using the Unity Editor. Any other way risks disconnecting the GUID in the meta file from the original file, and this will result in all connections to that asset being broken.
Some info about Missing script warnings, broken prefabs, GUIDs, renaming GUIDs, etc:
EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile, and hence why the metafiles ALWAYS MUST be source-controlled.
When Renaming: It is super-easy to inadvertently change the GUID by renaming outside of Unity. Don’t do that. Instead:
- close Visual Studio (important!)
- rename the file(s) in Unity
- in Unity do Assets → Open C# Project to reopen Visual Studio
- now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!
If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.
REMEMBER: the main problem with causing this type of renaming damage is that it does NOT get caught by the compiler or by Unity until you actually run that piece of code, and it might be weeks later. And when it is caught, it just fails, no clues, no way to track it back unless you use source control always.
thanks for all advices
1 Like
btw unity 6 doesnt seem so bent on the name of the file and the class within being the same…
Interesting if that is a case. As a matter of organization I’m likely to stick with the convention.
Quick comment on the above “when renaming”. There is no absolute reason to close VS prior to doing this. Again I do this at least every other day, frequently several times a day and often 2 or 3 times in a row as I’m not happy with my latest naming choice.
The “connection” with VS is quite robust. I would certainly close the .cs file but even that won’t break anything. VS should/will say it can’t find the file. That is annoying so I’d just close it. I also move entire folders again from within Unity. This won’t affect GUID values of course but again VS doesn’t care except if you haven’t closed the files affected. Simply close them first or put up with “can’t find” message and close them afterward.
I am really on the top ten “let’s refactor stuff” list of developers.
I actually think it can end up causing more problems than it fixes, but it should mean that as long as there is a monobehaviour it will show on the gameobject, but now “test” can contain GameManager or something and well good luck finding that from the unity end
I actually had issues… here was what happened:
- I made file Foo.cs and opened it to edit
- I went back to Unity and renamed it to Bar.cs
- I opened it in VS (still open) and began renaming Bar.cs internals, then started writing some code, writing a few lines and variables so i can put it on a GameObject and start thinking about it.
- press SAVE in Visual studio
- Go back to Unity… all my changes are gone and I have an empty class called Foo in a file called Bar.cs
After that happened about the 4th or 5th time I got wise and always close it.
It has never done it again.
I consider this a huge plus for you. At any given point in time you probably understand a larger fraction of your projects than I do, since I am a little more reticent to refactor. I definitely do it, but I hold very high bars for pain before I do a full refactor. Refactor really drives you to learn a lot more about full context.
I’m actually more of a conservative “Okay, let’s leave this one precisely in place and gently make a new one next to it for this new application and make sure nothing breaks over a period of a month or so,” assuming it is a more complex piece of code with many possible use combinations, combinations I might not have front-of-brain at the moment of refactoring.
And I do that a lot of that “careful refactor” with partial classes… you’ve probably even seen my scribblings:
Partial classes in Unity3D:
Regarding the rename. I suspect but we could test it out if that would help. That you may have had an unsaved version of your file open in VS. I can see how buffered data and open files can muck up the works. I prefer to not have the file open but closing VS isn’t necessary.
In any case I don’t close VS but would if I found my files getting corrupt.
I’ve always just renamed the class in Visual Studio - using the rename function (double CTRL-R) - and Unity updates the file name when I next refresh the asset database.