> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/help/removing-the-package.md). # Removing Binding System What happens to the bindings when the package leaves a project, and how to choose. Every binding in a project is made of types this package provides. When the package is removed, those types stop existing, and the scenes, prefabs and assets that use them hold data Unity can no longer read. The values in bound fields are lost the next time those files are saved, and Unity does not warn you. The **removal assistant** is there so that this is a decision rather than an accident. It reads the project first, writes down what every binding was doing, and then does whichever of three things you choose. **Window ▸ Binding System ▸ Remove Binding System...** {% hint style="warning" %} Use version control, or keep the backup the assistant makes. A removal cannot be undone from the editor. {% endhint %} ## The three answers

Answer	What happens
Do nothing	Writes the record and changes nothing else. The bindings break when the package goes, and the record is what tells you what they were. For a project only trying the package out, or one that will rebuild the connections some other way.
Replace the bindings with their values	Every bound field becomes a plain field holding the value the binding was showing. The proxy bindings are removed, and the scripts that declared bind fields are rewritten to match. The project compiles and runs without the package; what the bindings did each frame stops happening.
Replace the simpler bindings with generated components	Everything the answer above does, and then generated C# that carries on applying the bindings it can, with no reference to this package. See Baking to components.

Press **Scan the project** first. The window then shows what it found: bindings on script fields, proxy bindings, bindings on UI Documents, the assets holding them, the scripts that mention the package, and the scripts that will need your attention after a rewrite. With the third answer selected, the scan also says how many bindings can be baked. ## Options

Option	What it does
Keep a copy of every file that changes	On by default. Copies go under the report folder, outside `Assets` so Unity does not import them.
Read each binding once and keep its value	On by default. Without it a bound field keeps whatever was last serialized into it, which for a field only ever driven by its binding is the type's default.
Rewrite the scripts which declare bound fields	On by default. `Bind<T>` becomes `T`, and reads of `.Value` are rewritten. Anything with no plain equivalent is left where it is and listed in the report.
Report what would happen and change nothing	A dry run. Only the report folder is written.
Report folder	Where the record and the report go, relative to the project folder. `BindingSystemRemoval` by default.
Generated code folder	Where a bake writes its code. `Assets/BindingSystemBaked` by default.

The open scenes are closed before a run starts, because the assistant opens every scene in turn. While the assistant is running, Unity's automatic asset refresh and script reloads are held off, so nothing recompiles underneath it. ## The record Written whichever answer you choose, into the report folder:

File	What it holds
`Bindings.md`	Every binding, grouped by asset, one line each saying what fed what. For reading.
`Bindings.csv`	One row per binding. For a spreadsheet.
`Bindings.json`	The same, for a script that rebuilds the connections somewhere else.
`Removal.md`	Written after a run: what was actually done, and anything that was not.

None of these files names a type from this package, so they still read in a project that can no longer compile it. **Window ▸ Binding System ▸ Write down every binding** writes the record on its own, without opening the assistant or changing anything. ## Baking to components A bake turns each binding it can into the line of C# a person would have written by hand, under a comment naming the binding it came from. It writes into the generated code folder:

File	What it is
`BakedBindingRunner.cs`	A component that applies its entries at the update points the bindings had. The same file in every project.
`BakedBindingTable.cs`	The generated part: one case per binding.
A variables store	Only when bindings read bind variables: one static field per variable, starting from the value it held at bake time.

A binding is baked only when **every part of it** has a plain equivalent: its source, its path, its converters and its modifiers. One part with no plain form takes the whole binding out, and it is removed like the rest. So expect some bindings to be left behind. The ones that are, and the reason for each, are listed three times: in the window before you run, in the Console after the scan, and in `Removal.md`. What changes in a baked binding: * **A source found while the game runs** (by name, tag, pattern, context or scene search) is resolved once, at bake time, to the object it points at then. A search that ran every time the source was lost now never runs. The entry says so in a note. * **Bind variables** become one store for the whole project, rather than one per scene, and are put back to their baked values at the start of every play session. * **Two-way bindings**, a slider bound both ways for example, keep working both ways only where every modifier can be undone exactly on the way back, as a remap onto the control's range can. A clamp cannot: it threw away whatever lay outside its range. Installing the generated components needs a second pass, because their type only exists once Unity has compiled the first pass's code. It runs by itself after that compile. If the compile failed, fix the error and use **Window ▸ Binding System ▸ Finish the baked bindings**. {% hint style="info" %} A switched-off bind field is not counted as a binding that could not be baked. It is a field holding a plain value, and becomes exactly that. {% endhint %} ## Deleting the package folder Deleting the package folder from the Project window does not go through straight away. A dialog explains what would be lost and offers **Open the assistant**, **Cancel** or **Delete anyway**. While the assistant is open, imports and script compiles are paused, so the project cannot change underneath the decision. ## Removing it from the Package Manager A removal from the Package Manager cannot be stopped from inside the package. A dialog says what is about to be lost while the package is still loaded, and the Console repeats it for whoever reads it afterwards. To convert the bindings instead of losing them: 1. Add Binding System back to the project. 2. Open **Window ▸ Binding System ▸ Remove Binding System...** 3. Choose what should happen to the bindings, and let it finish. 4. Remove the package again. ## From the command line For a large project converted on a branch, in a job, with the diff read afterwards: ``` Unity -batchmode -quit -projectPath \ -executeMethod Postica.BindingSystem.Removal.BindRemovalBatch.StripToValues ```

Argument	What it does
`BindRemovalBatch.WriteInventory`	The record only, as Do nothing.
`BindRemovalBatch.StripToValues`	As Replace the bindings with their values.
`-bindRemovalDryRun`	Report what would happen and change nothing.
`-bindRemovalNoBackup`	Skip the copies of changed files.
`-bindRemovalKeepScripts`	Do not rewrite the scripts.
`-bindRemovalReportFolder <folder>`	Where the record and the report go.

The bake is not offered here: its second pass needs the editor to compile the code the first pass wrote, and a batch run exits before that can happen. Strip in a job, bake in the editor. ## Related pages * [Windows, Menus and Components](/binding-system-3/reference/windows-and-menus.md): the menu items above. * [Upgrading from Binding System 2](/binding-system-3/getting-started/upgrading.md): the other direction.