So, I’ve been changing the script of a MonoBehaviour by using debug mode of the inspector and dragging the new script to the Script field. It worked and was super useful. But now in Unity 2022.2.0, I’ve just discovered that the Script field is disabled even in debug inspector.
Do you guys plan to bring the feature back at some point? Or do you recommend an alternative way to change the script of a MonoBehaviour?
Thank you,
I just noticed this too!
Did you come up with any work around?
What’s wrong with just removing and adding the correct component?
Sure you can, but it would take a lot more work (to refill the value and reconnect the reference to the script).
Downgrade Unity hehe
Any official update on this?
Just realized this as well 
You can always modify manually the script guid in the serialized asset if you use text serialization.
Get the guid of the former script you used and the guid of the new one, and swap them where needed in a text editor. (You can find the guid either in the meta files, or from a script - for example, in order to get the guid of the currently selected script: AssetDatabase.AssetPathToGUID(AssetDatabase.GetAssetPath(Selection.activeObject.GetInstanceID())) )
Thanks. Still hope the drag-and-drop will be back sometime.
Yup that would be more convenient!
UP, we need replace script reference back, its very useful to replace inherited mono behaviours without break references
Exactly. I just found my way to this thread and your comment couldn’t be more true. In fact its such a major breaking change for our team that we can’t upgrade all of our projects to Unity 6 because we have replied heavily on how this has worked for over a decade.
The lack of being able to change the script to a subclass renders prefab variants all but useless to us OR we have to make sure no script is added to a base prefab so we can add subclasses to variants of a base prefab, but this means no inherited serialised data. This seems to be a huge breaking change!
To be honest seeing as it had to be done via the debug inspector, makes me think being able to do it at all was an accident/oversight was never an intended/supported workflow.
It’d be long term more flexible architectural wise and design wise to use thin container components, and use pluggable scriptable objects or [SerializeReference] fields to provide the required extensibility or modularity. I honestly prefer to keep data out of prefabs as prefab serialisation can be really unstable sometimes.