Inventor 2027 and .NET 10: "No Migration Needed" — Until You Need Entitlement

On April 16, 2026, Autodesk published a .NET compatibility note for Inventor 2027 add-ins. The headline reassurance:

"Existing .NET 8 add-ins should continue to work without recompilation."

"No mandatory migration is required for upgrading to Inventor 2027."

That's accurate for the common case — pure-managed add-ins that only depend on Autodesk.Inventor.Interop and the BCL. There's one specific exception that anyone shipping a commercial add-in will hit, and it's the reason for this post.

The exception: anything that uses entitlement

Inventor 2027 hosts on .NET 10 while 2023–2026 ran on .NET 8.

The .NET runtime forward-compat story is real — net8.0 binaries generally run unmodified inside a net10.0 process — but it doesn't apply to the helper assemblies Autodesk ships next to Inventor.

The one that breaks is the entitlement wrapper. In 2023–2026 it was AddinNETFramework.AdWebServicesWrapper.dll (built for .NET 8 since 2025). In 2027 it has been renamed to AdWebServicesWrapper.dll and ships only as net10. The rename alone breaks any csproj with <Reference Include="AddinNETFramework.AdWebServicesWrapper" />; the net10-only retarget means that even after fixing the reference, a net8.0 add-in cannot resolve it at runtime.

To be precise: the only thing affected is calls into Autodesk's own entitlement service through AdWebServicesWrapper / Autodesk.WebServices.CWebServicesManager — typically WebServicesUtils18Plus.GetUserId() or GetUserName(). App Store entitlement checks (apps.autodesk.com/webservices/checkentitlement) live entirely on top of this wrapper, so every App Store-distributed add-in is in.

It would be nice to have this case spelled out in the official compatibility note. In the meantime, here's the fix.

The fix: target .NET 10 for the 2027 build

Bottom line: your 2027 build needs to be net10.0-windows, and the assembly-reference name changes. If your repo only supports a single Inventor version, that's a one-line edit. Most commercial add-ins support a range, so you want a conditional pattern keyed on InventorVersion.

A shared Directory.Build.props at the repo root, picking the TFM per Inventor version:

<PropertyGroup>
    <InventorVersion Condition="'$(InventorVersion)' == ''">2026</InventorVersion>

    <!-- Inventor 2027 hosts on .NET 10; earlier versions stay on net8.0-windows. -->
    <TargetFramework Condition="'$(InventorVersion)' == '2027'">net10.0-windows</TargetFramework>
    <TargetFramework Condition="'$(TargetFramework)' == ''">net8.0-windows</TargetFramework>
</PropertyGroup>

A shared Inventor.targets imported by every Inventor-touching csproj, branching the wrapper reference and its simple name per version:

<Choose>
    <When Condition="'$(InventorVersion)' == '2027'">
        <ItemGroup>
            <Reference Include="AdWebServicesWrapper">
                <HintPath>$(InventorReferencesPath)2027\AdWebServicesWrapper.dll</HintPath>
                <Private>false</Private>
            </Reference>
        </ItemGroup>
    </When>
    <Otherwise>
        <ItemGroup>
            <Reference Include="AddinNETFramework.AdWebServicesWrapper">
                <HintPath>$(InventorReferencesPath)$(InventorVersion)\AddinNETFramework.AdWebServicesWrapper.dll</HintPath>
                <Private>false</Private>
            </Reference>
        </ItemGroup>
    </Otherwise>
</Choose>

Two things worth keeping in mind. Don't multi-target a single project: single-target the whole graph per Inventor version and build twice — multi-targeting forces every dependency to multi-target too and confuses Visual Studio about which TFM is "active". And keep <Private>false</Private> on these references so the build doesn't copy a second copy of the wrapper next to your add-in, which causes COM type-identity collisions when Inventor tries to load both.

You'll also need the .NET 10 SDK installed for the 2027 build. And gate the 2027 .addin manifest with <SupportedSoftwareVersionGreaterThan>30..</SupportedSoftwareVersionGreaterThan> plus a matching <SupportedSoftwareVersionLessThan> on your 2026 manifest, so a net10 DLL never tries to load into a net8 Inventor host.

In short

Build with -p:InventorVersion=2027 against a 2027 SDK install. If the build complains about AdWebServicesWrapper, switch that leg to net10 with the conditional pattern above and bracket your .addin manifests so each version only matches its own host.

The "no migration" message holds up well for most hobby and free add-ins. For commercial add-ins that touch entitlement there's a little extra work, but it's mechanical once you know to do it. Hopefully a future revision of the compatibility note picks this case up; in the meantime, if you're hitting AdWebServicesWrapper errors you're not doing anything wrong, and you're not the only one.

---

All build configuration excerpts in this post are real and live in production across 13 Inventor add-ins as of May 2026.