DEV Community: Mario Mignemi

When Rider Forgets How to Write Assembly Definitions: My Day-Long Fight With UnityAtoms

Mario Mignemi — Tue, 18 Aug 2026 05:08:47 +0000

Yesterday, adding a dependency in Jetbrains Rider was a non-event: type the class name, hit Alt+Enter, keep coding. Today, the exact same shortcut quietly stopped writing anything to my .asmdef file and it took me a full day to even understand what was going on, let alone fix it.

For context: right now, I'm working on a flexible selection system for my game The Weight of One: The Jovarko Incident, a tactical space-combat game. The project is split into several modules, each with its own Assembly Definition: Core.asmdef, Systems.asmdef, UI.asmdef, Data.asmdef, and so on. I recently added UnityAtoms through the Package Manager, and I wanted to use types like AtomEvent and AtomValueList from the Data module. Simple stuff. Except it wasn't, and here's the story of it.

The Ghost Import

The first sign something was wrong was almost funny. I'd type AtomEvent, the name would show up red (unresolved), I'd hit Alt+Enter → Reference and import, and the red would disappear. Great, dependency resolved, right?

Then I'd switch focus to the Unity Editor window to check something in the Inspector. The moment I clicked back into Rider, the exact same symbol was red again. Same file, same line, nothing touched in between.

It felt like Rider had briefly pretended to fix the problem and then changed its mind the second I looked away.

What `Reference and Import` Is Actually Supposed to Do

To be clear on what should happen: when you add a dependency through the Unity Package Manager, and you click Alt+Enter on an unresolved type that exist in an external assembly, Rider is supposed to add a reference in your .asmdef file. In my case, Data.asmdef should end up depending on UnityAtoms.UnityAtomsCore.Runtime. That's the whole mechanism that makes cross-module code work cleanly with Assembly Definitions instead of forcing everything into one giant assembly.
Except my Data.asmdef never actually gained that reference. The autocomplete looked like it worked. But the underlying file wasn’t changed, which meant the result was only cosmetic. The Rider’s syntax highlighter got a brief nap before Unity's next domain reload reminded it that, structurally, nothing had actually been connected.

The Troubleshooting Rabbit Hole

At this point, I did what anyone would do: assumed it was something dumb on my end and started working through the usual checklist.
• Invalidate Caches / Restart
• Regenerate project files from Unity
• Fully close Unity, delete the .csproj / .sln files, reopen and let them regenerate
• Clean out the Library/ folder
• Update both Rider and the JetBrains Rider Editor package
• Toggle Git packages and Built-in packages under Unity's External Tools preferences.

None of it stuck. By the end of the day, I had tried basically every standard fix in the book and I was exactly as blocked as when I started.

The Almost-Fix

Here's the one thing that worked, sort of: opening the asmdef file directly inside Rider's own editor and adding the reference by hand. Mind you, not through Unity's Assembly Definition Inspector. Through the raw file directly. That would sometimes get the symbols to resolve and stay resolved.

Sometimes. Not always. And I still haven't figured out what actually triggers it to break again. It's not tied to a specific action I can reproduce on demand, which is the most frustrating kind of bug: the kind where your "fix" is really just a temporary appeasement ritual and nothing else.

Why This Bugs Me More Than a Normal Bug

Well, it turns out I wasn't the only one blindsided by this either. A bit of digging turned up RIDER-94834 on JetBrains' YouTrack, a closely related report of asmdef references not being persisted correctly.

And what gets under my skin isn't that the bug exists — software breaks, that's just how things go. It's how it fails. Nothing about the UI hinted that the import hadn't actually landed on disk. That distinction matters to me.

If package-sourced assemblies are a known blind spot for Rider, that's fine. It's a limitation, and limitations are forgivable. What isn't forgivable is showing that everything is ok when something silently fails. If Rider doesn’t support this type of import, say so: a warning banner, a tooltip, a line in the changelog. Anything beats finding out, after a wasted day, that it’s a visual bug.

I'm not saying this to pile on. I pay for Rider, and it earns that money close to 100% of the time, which is exactly why this one stings. The bar is set high, and watching a core part of the Unity workflow quietly fail with zero warning felt genuinely out of character.

What's Next

I've since opened a thread on the Rider support forum.

If this problem sounds familiar to you, don't just quietly work around it, please. Go upvote and comment on both the thread and the YouTrack issue. A pile of "me too" moves the needle.

For now, I'm sticking with the manual-edit workaround and treating every successful Alt+Enter import with deep suspicion until I've actually reopened the file to confirm the reference stuck. Not a great long-term workflow, but it's hopefully unblocking me for the moment.

Has anyone else seen asmdef references silently drop the moment you switch focus between Unity and Rider? If you've found a workaround that actually holds, not just "sometimes" but reliably, I'd really like to hear it in the comments.

Useful Links:
The Weight of One - Official Channel The Weight of One - Itch.io Page
My Personal Channel

You can find my Dev Vlogs in all channels!

How a Broken Button Forced Me to Rebuild My Entire Architecture

Mario Mignemi — Sat, 15 Aug 2026 16:53:48 +0000

A few weeks ago, I hit a deadlock that took me an embarrassingly long time to fix: I couldn't have a shuttle without a button, and I couldn't have a button without a shuttle.

Here's why. My four-year-old button system required a live GameObject reference to be valid: no reference, and the button would self-destroy. Fine for a button that operates on a ship already sitting in the scene. Not fine for a boarding shuttle, which doesn't exist until a button spawns it. So the button needed the shuttle to exist to avoid self-destruction, and the shuttle needed a button to exist to spawn. Neither one could go first.

The bug wasn't in the shuttle. It was in a button that was four years old.

I'm building The Weight of One: The Jovarko Incident, a tactical space-combat game where you command a capital ship and its subsystems. The shuttle in question is a small craft you launch from your own hangar to either forcibly dock an enemy ship from the outside, or peacefully move into the hangar of a neutral or allied ship. Simple concept. It broke everything I had.

This post isn't really about the shuttle, though. It's about the module structure I ended up building because of it, and whether drawing hard boundaries — before writing a single line of code — was worth the friction it's currently causing me.

Every button in my prototype came with a spaceship stapled to it

My original UI code, written during early prototyping, made buttons stateful. A ButtonModel held a direct reference to the ship it operated on, and if that reference wasn't there, another script would destroy the button on the spot:


    // Pseudo-Code
    public class ButtonModel : MonoBehaviour
    {
        public Transform linkedShip;
    }

    public class SelfDestructOnDestroyedObject : MonoBehaviour
    {

        private ButtonModel model;

        ...

        private IEnumerator OnLostReferenceDestroySelf()
        {
            ...
                    Destroy(gameObject);
            ...

That's fine when the ship already exists in the scene before the button does, which has been the case so far. However, for a shuttle, it's exactly backwards: the button is what's supposed to trigger the creation of the gameobject. The classic Mexican standoff.

I don't blame past-me for this. It was prototype code from 2021-2022, and it did its job for years, until it didn't in 2026. But I'm not the type to bolt on a special case just for shuttles and move on. If I have the feeling that the design is wrong, I want to know why and fix it.

Making the button stop caring whose ship it was

The fix felt obvious once I named the actual problem: the button shouldn't hold a reference at all. It should announce an intent and let something else figure out the target.

Stateless buttons break the deadlock cleanly. The catch: something still needs to track which button maps to which ship. There’s no getting around it. That something is basically a lookup — conceptually a Map<Button, Spaceship> — and I didn't want a bare dictionary sitting inside a MonoBehaviour pretending to be a service, and six months later nobody remembers what it's for.

Down the ScriptableObject rabbit hole

I had used ScriptableObjects for exactly one thing before this story: configuration data. Stat blocks, balance numbers, that kind of thing. Looking into how larger studios structure decoupled systems, I found a much bigger use of SOs: as runtime variables, event channels, and typed runtime sets that replace both generic EventBuses, which I've been using so far, and direct references.

It solved my mapping problem cleanly.

What it didn't solve was a bigger question: full rewrite, or hybrid architecture? I have no problem resetting and rebuilding systems, that's genuinely part of why I enjoy programming. However, a full architectural rewrite of a project that's somewhere between a prototype and an actual demo is a different bet than restructuring one feature. So I picked a feature that didn't exist at all — a flexible mission system — and decided to build it entirely with a ScriptableObject architecture in a separate project, as a real test.

Drawing five boxes before writing any mission code

Before touching the mission system, I made one decision on purpose: assembly definitions, not just folder conventions, would decide where files were allowed to live. In fact, almost everything I came across about SO architecture — articles, videos, you name it — flagged a common problem: every variable, event channel, and runtime set is its own small asset, and that adds up fast.

A feature that used to be two files in the old EventBus system could easily turn into five or six files. Left unorganized, that adds up into a mess fast, so I wanted the boundaries locked in from day one.

Five main modules, five assemblies:

Core: Generic, game-agnostic primitives — base SO wrappers, generic interfaces, extensions
UI: Draws to Canvas/Screen, captures interface input, raises intent events
Data: SO Variables, Event Channels, Runtime Sets, and config schemas — no Update() loop
Gameplay: Moment-to-moment entity behavior like movement, combat, mission triggers.
Systems: Global, cross-scene infrastructure, like save/load, scene transitions, campaign progress.

Dependency graph:

The one rule that makes the other five make sense

None of this is exotic on its own. Assembly definitions weren't new to me, but I’ve never actually reached for them. Game development isn't my day job, so they just weren't on my radar until now.

This is the part that maps directly back to the shuttle deadlock. The old ButtonModel was a compile-time UI-to-Gameplay dependency wearing a MonoBehaviour costume. The new rule makes that specific mistake impossible to write by accident. The assembly definition simply won't allow it.

Where the shuttle actually landed

Here's the part I want other people to take away from this. Understanding ScriptableObject architecture hasn't stopped me from placing files where I think they belong, only to have the assembly definition reject them.

At first, this was annoying. Then I noticed a pattern: every one of those errors was telling me one of two things. Either the file is genuinely misplaced, or the code design underneath it is wrong: future tech debt I hadn't noticed yet, because nothing was preventing me from writing it that way.

Is it paying off?

Honestly, provisionally, yes! But I'm not going to pretend the trade-off is free: having a ScriptableObject architecture and five modules means more files, which adds real ceremony for a solo dev before any feature ships. There's no dodging that.

I picked the mission system specifically because it was new territory: a contained way to test the architecture before betting the rest of the game on it. I'm treating that as a deliberate validation step. I want to see it hold up across a few more features before I call it the standard.

On the plus side, what I didn't expect was how much the friction itself became useful information. Every misplaced file is a small, cheap lesson about my own design, delivered immediately instead of six months later as an unmaintainable spaghetti mess.

If you're staring down a similar dilemma, the one thing I want you to take from this “happy accident” is: don't draw module boundaries as folders, draw them as dependency "permissions". Enforce them with assembly definitions, and let the compiler be blunt with you.

This whole approach is a sharp departure from the generic EventBus pattern I used to lean on, which is a big enough topic to deserve its own post. For now: I'll keep building the mission system and report back on whether five assemblies still feel right once the feature list grows.

Developers unite! Let me know how you've drawn your own lines.

Useful Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page
My Personal Channel