Multiple UnitsNet versions being loaded into same context

[dschuermans]

Hello 👋

Been a while, but here I am with something I'm running into:

Whilst working on an AutoCAD plugin. I started using UnitsNet v5 for the algorithm I was working on.
When a new version that included this functionality was released, we got complaints from a customer that was using our plugin alongside another plugin, saying they no longer worked side by side.

After a brief investigation, I came to the conclusion that one of the issues was the fact that we were shipping v5, whilst the other plugin shipped v4.

Now here comes the fun part:

Our plugin loads upon startup of AutoCAD - theirs load on demand (as soon as a command defined in their plugin is executed by the user)
Because of our setup / initialisation process, we're always making sure v5 gets loaded

Whenever the other plugin executes Length.FromMeter(1), they're actually getting back Length.FromLightyears(1), due to the shift in the underlying units enumeration (I believe you got rid of the Undefined=0 values on the enumerations)

No errors, nothing

Any thoughts on how to go about this?

Options i'm considering:

• Downgrading to v4 ourselves
• Using ILrepak / ILMerge to merge the v5 dll into our own dll
• Using https://github.com/getsentry/dotnet-assembly-alias to alias the unitsnet into something else, so it no longer matches by name when .NET tries to load it

[ChangkeunJ]

The Undefined = 0 removal isn't it. Here's the complete diff of UnitsNet/GeneratedCode/Units/LengthUnit.g.cs between tags UnitsNet/4.152.0 and UnitsNet/5.0.0:

     public enum LengthUnit
     {
-        Undefined = 0,
 
         /// <summary>
         ///     Angstrom is a metric unit of length equal to 1e-10 meter

That's the whole thing. Every other member kept its explicit value, Meter = 21 on both sides. Same for Mass, Area and Pressure. Volume additionally gained Nanoliter = 53, which is the highest value in that enum, so it sits alphabetically in the source but numerically on the end and moves nothing. And it couldn't have mattered anyway, because LengthUnit.Undefined in a caller compiles down to ldc.i4.0, a literal baked into their IL. Deleting the member can't move anything at runtime. It's a source break, not a binary one.

What's actually biting you is older than v5. Explicit values only arrived in 4.133.0. Before that every member was an implicit ordinal in alphabetical order, so any new unit anyone contributed shifted everything after it. Here's 4.118.0:

    public enum LengthUnit
    {
        Undefined = 0,
        AstronomicalUnit,
        Centimeter,
        Chain,
        Decimeter,
        DtpPica,
        ...

Count those out and Meter is 18. The timeline, evaluating the ordinals at each tag: 17 through 4.49.0, 18 from 4.50.0 through 4.118.0, 19 at 4.119.0 only, 20 from 4.120.0 through 4.129.0, and 21 from 4.130.0 on when DataMile was added. In v5, 18 is LightYear.

So the lightyears aren't generic corruption, they're a fingerprint. They pin the other plugin to a UnitsNet between 4.50.0 and 4.118.0. Had it been built against 4.119.0 you'd be seeing megalightyears, and against 4.120.0 through 4.129.0, megaparsecs. That's the same mechanism as #1068, where a library on 4.107.0 was consumed by an app on 4.126.0 and produced megalightyears, because 18 is MegalightYear in 4.126.0. The name you get out is whatever the loaded version calls the caller's baked-in integer.

That got fixed in 4.133.0 by #1097, which fixes #1068. Values now live in Common/UnitEnumValues.g.json and are enforced by CodeGen/Helpers/UnitEnumValueAllocation/UnitEnumValueAllocator.cs, whose doc comment says the quiet part out loud:

///     Allocates unique enum values per quantity and persists the mapping to a JSON file to ensure the values do not
///     change when adding new units.

angularsen confirmed the same in #1114, "as of v4.133.0, at least the enum values should now be stable". In that JSON at 5.75.1, Length.Meter is 21 and Length.LightYear is 18.

Two corrections to the framing. First, Length.FromMeters(1) on its own cannot give you lightyears. That callsite carries no enum, and the signature is FromMeters(QuantityValue) in both 4.118.0 and 5.0.0, so it binds and returns 1 meter. The corruption only enters where a LengthUnit value crosses the assembly boundary: Length.From(x, LengthUnit.Meter), .As(LengthUnit.Meter), .ToUnit(...), or a LengthUnit held in a field or passed as an argument. #1068's repro shows exactly that split, its Length.FromMeters(10).As(MeterUnit) case is fine up to the .As.

Second, downgrading yourselves to v4 isn't neutral, it's worse. Any v4 you ship advertises Version=4.0.0.0, which is the identity the other plugin already references, so the two assemblies stop being distinguishable by identity at all and unify to whichever loads first. And every v4 from 4.130.0 up, 4.152.0 included, still has LightYear at 18, so you'd get the identical bug with the last thing that could have kept them apart removed. Matching them would mean living between 4.50.0 and 4.118.0, which is not a place to live.

Cheapest test before you build anything, and don't use the file version for it. UnitsNet.csproj pins <AssemblyVersion> to the major and doesn't set <FileVersion> separately in the v4 line, so every single v4 build on nuget.org reports 4.0.0.0. I pulled 4.118.0 and 4.152.0 and checked all six DLLs, all 4.0.0.0. The real number is in the informational version, which surfaces as "Product version" in the file properties dialog:

Get-ChildItem "C:\Path\To\TheirPlugin" -Recurse -Filter UnitsNet.dll |
  ForEach-Object { "$($_.FullName)  $((Get-Item $_.FullName).VersionInfo.ProductVersion)" }

4.118.0 comes back as 4.118.0+0957e34c7414b62f3012d5bbc2f72a51819af914. Anything in 4.50.0 to 4.118.0 and this is settled. 4.130.0 or later and I'm wrong, Meter is already 21 for them and you should look elsewhere.

Now the question I'd actually chase, which is why anything is unifying at all. Both packages are strong-named with the same key. I pulled the DLLs off nuget.org and the public key token is f8601875a1f041da in 4.118.0, 4.152.0, 5.0.0 and even the 6.0.0 prereleases. UnitsNet.csproj pins <AssemblyVersion> to the major, 4.0.0.0 for the whole v4 line, 5.0.0.0 for the whole v5 line. So UnitsNet, Version=4.0.0.0, PublicKeyToken=f8601875a1f041da and Version=5.0.0.0 are two distinct assembly identities.

What that buys you depends on which runtime AutoCAD hands you, and this is the part I'd nail down first. On .NET Framework those two identities load side by side in one AppDomain with no config at all, so something in your process is overriding it, either a binding redirect in acad.exe.config or an AppDomain.AssemblyResolve handler matching on simple name. Given "because of our setup / initialisation process, we're always making sure v5 gets loaded", I'd bet on your own resolver. The usual shape:

AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
    AppDomain.CurrentDomain.GetAssemblies()
        .FirstOrDefault(a => a.GetName().Name == new AssemblyName(e.Name).Name);

Whatever you hand back from AssemblyResolve is taken as-is on .NET Framework. The loader doesn't re-check that it matches the requested version or public key token, which is exactly why you get silent lightyears rather than a FileLoadException. Compare the full e.Name, or just return null for names you don't own, and both plugins go back to loading their own copy.

On .NET there's nothing to override, because the default AssemblyLoadContext resolves by simple name and the first UnitsNet loaded wins for everybody, which is precisely your symptom with no redirect and no resolver involved. I'm fairly sure AutoCAD moved plugins to .NET 8 in the 2025 release, so if that's the host you're on, there's no misconfiguration to find and aliasing is the fix rather than a workaround.

Either way, confirm which world you're in from a scratch command once both plugins are loaded:

foreach (var a in AppDomain.CurrentDomain.GetAssemblies()
                           .Where(a => a.GetName().Name == "UnitsNet"))
    ed.WriteMessage($"\n{a.FullName}\n  {a.Location}");

Two lines means side by side is working and the bug is somewhere else. One line means you've found it, and the runtime tells you whether it's your resolver or just how that loader works.

Of your three options I'd take the alias. It renames and fixes references so nothing can match you by simple name again, which is the one fix that works under both loaders. Pass -k with an snk if you need to stay strong-named, because with no key it strips strong naming from everything it touches, and -i if you want the aliased types internalized too. ILRepack works as well, but only with /internalize, only if no UnitsNet type appears anywhere in your own public surface, and you'll need /keyfile to re-sign afterwards.

Two things queued up behind this. All of v5 pins AssemblyVersion to 5.0.0.0, still true at 5.75.1, so you can move freely within v5 without redirects, but 6.0.0-pre103 is already on nuget with 6.0.0.0 and the same key, so a third plugin on v6 puts you right back here. Whatever you pick should be symmetric. And v5 dropped the net40/net47 targets v4 had, 5.0.0 ships netstandard2.0;net7.0 and 5.75.1 ships netstandard2.0;net8.0;net9.0. On a .NET Framework host that means you're on the netstandard2.0 build plus the netstandard.dll facade, which you never needed on v4 since it had a real net47 target. Worth confirming that's resolving cleanly while you're already in there.

[dschuermans]

Hey @ChangkeunJ

Thanks a lot for this detailed write-up!

When I said downgrade to v4, i actually meant matching the v4 version exactly from the conflicting plugin, but it really would be a last resort if nothing else worked.

We're in the most horrible possible scenario - We support AC24, AC25, AC26 and now AC27. AC24 is still .NET Framework, since AC25 they switched to .NET8 and AC27 is .NET10 😅

The algorithm that uses UnitsNet however is only shipped in a release after we supported AC25.
AC24 is net48, i just double checked and the algorithm performs as expected there too

I tried the aliasing approach, but there ran into a wall when it came to XAML / BAML. I couldn't alias the UI framework we're using as the assembly names are hardcoded inside the BAML once they're referenced in XAML, and the alias tool doesn't bother re-writing those

I then briefly looked into Eazfuscator.NET, since they do have a merge / re-write XAML/BAML feature but that path showed we have some third party dependencies that we're using as-is (not proxied or anything) and shared cross-assembly. So merging those wouldn't be possible either and I'd have to end up with a mix of aliasing & merging

Right now I'm investigating the possibility of using a custom ALC, but only for the targets running on .NET8 or higher (so AC25 and up) and results are looking promising. I won't be needing any aliasing or merging in this approach

[ChangkeunJ]

The ALC route should work, and the reason it fixes the customer's bug is slightly different from isolation — it's that you stop occupying the default context. Their v4 loads there cleanly once yours isn't sitting in it first. That's worth using as the acceptance test: after the change, load their plugin and confirm Length resolves to 4.x in Default.

The same framing gives you the constraint. Nothing in the default context may touch a UnitsNet type — not a parameter, not a return, not a local in a method that never runs. First reference triggers a Default load and you're back where you started. So the isolated assembly's public surface has to be UnitsNet-free: primitives, or types from an assembly you deliberately share by returning null from your ALC's Load override.

If one does leak across, you get an InvalidCastException naming the same type on both sides, which reads like nonsense until you remember they're two distinct Types. Printing Assembly.Location for each is the fastest way to confirm that's what happened.

Two things that bite specifically in a NETLOAD deployment. AssemblyDependencyResolver needs the .deps.json sitting next to your entry assembly, and folder deploys drop it often enough that it's worth checking first when resolution quietly returns null. And UnitsNet's statics are per-ALC — UnitConverter.Default and UnitAbbreviationsCache.Default both hang off UnitsNetSetup.Default — so if you register custom abbreviations or conversions anywhere, that has to happen inside the ALC. Doing it in host-side startup will look like it worked and do nothing.

AC24 has no equivalent, so that target stays on whatever AutoCAD's resolver hands it. Given the algorithm only shipped after you supported AC25, that may be moot.