Inventor Addin Build Pipeline Tool

This is something that I have wanted for a while now, but just hasn’t reached a point for me where I felt like I needed to spend the time. Now with Inventor 2025 and the upgrade from .NET Framework to .NET8 it has brought things to a head. Perhaps others have already come up with their own solution on this but here is what I ended up doing.

When publishing to the store, the Autodesk suggested package format is to have all of the different Inventor releases in a single folder, with sub-folders for each of the versions and updates to the different .addin files to include/exclude from the the different versions of Inventor.

The above image is from the Inventor help docs and shows an example of this structure. It would be nice if there was a way to automate these directory structures and more importantly, automate the updates of the addin files to correctly reflect which version of Inventor to load into.

There is nothing magical about this, as long as it is command line compatible, just pick a tool and do it. I ended up building a command line tool in .net that will allow you to specify the path to the .addin file and update the version information in the file to reflect the version of Inventor you are loading into. Then I added to a powershell script to setup the package that gets submitted to the Autodesk store. Here is an example of what that looks like

addinxform.exe update --addinpath "C:\users\mike\AppData\Roaming\Autodesk\ApplicationPlugins\Sample.Inventor.addin" --SupportedSoftwareVersionGreaterThan "25.0.0" --SupportedSoftwareVersionLessThan "29.0.0"

In the example above, the desired addin file has its SupportedSoftwareVersionGreaterThan and SupportedSoftwareVersionLessThan tags updates to effectively have the addin loaded in Inventor 2021 through 2024.

The above command line is called from a powershell script that builds the solution, copies the output to a store package location, output files are signed and the addin file is updated. If there are other builds (such as for Inventor 2025), these files are signed and the addin file updated as required.

The utility also has a deploy command which you can use to deploy your addin file locally and have it setup to refer back to your development output for debug purposes.

I have put the code for this utility into Github. If you like you can fork it and adapt it to your own purposes or submit issues.

Github Repo

Inventor, Addins, Modeless WPF Window

If you are building an add in for Inventor and want to setup your window to be modeless and always on top of Inventor itself, like a toolbar, you need to set the Owner property of the window itself and you can use the value stored in the “MainFrameHWND” property of the Inventor application object passed to your addin.

The not so straight forward part is that the Owner property expects a reference to a Window object and all we have is the handle to the Inventor window.

public partial class MyAddinWindow : Window
{
    public MyAddinWindow(int inventorWindowHandle)
    {
        InitializeWindow();

        // setup loaded event
        Loaded += (s, e) =>
        {
            WindowInteropHelper wih = new WindowInteropHandler(this);
            wih.Owner = (IntPtr) inventorWindowHandle;
        };
    }
}

Missing Packages After Cloning

Just a quick post!

Ever clone your .NET solution to a new computer and find that all of your nuget packages are missing?

Right-clicking on your solution and selecting "Restore Nuget Packages" doesn’t seem to do anything? This happens to me and then I never remember the command and have to google it. This time, I am going to write it down!

How To Do It

Open up your Package Manager Console window. It should be on the bottom, but if it isn’t, in your pull down menus, goto Tools | Nuget Package Manager | Package Manager Console. This was for Visual Studio 2019, but probably the same for 2017.

At the command prompt type:

update-package -reinstall

And that’s it! You should find all your annoying yellow warning triangles gone.

Nuget Versioning In Your Library

I was building up a library this morning, and I wanted to use Json.NET with it for deserializing. I was planning on using this library for a number of different apps, and it made me wonder, if I add a dependency such as Json.NET, will it cause problems if I am already consuming it in my app?

Nuget Versioning

For my library, version 10 or higher should be sufficient. I dug into the nuget docs and found a bunch of handy examples.

I installed 10.0.3 into my library project. In the project file itself, I changed the reference version from 10.0.3 to be just 10.0. According to the nuget docs, this will enable 10.0 to be the minimum version, and if there are higher versions, they will be accepted.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="a_class_file.cs" Link="a_class_file.cs" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0" />
  </ItemGroup>
</Project>

Other Versioning

Some other helpful items:

Notation	Description
Version="[10.0,11.0]"	includes anything from 10.0 to 11.0 including 10.0 and 11.0
Version="(,11.0]"	Includes anything up to and including 11.0
Version="[11.0]"	Only accept version 11.0

There are lots of other helpful examples in the documentation.

Xamarin Forms: iOS and SIGABRT

Introduction

I have been working on a new project, one that involves Xamarin Forms and communicating with IOT devices over BluetoothLE. BluetoothLE is a very new thing for me, and I have been struggling a bit with getting it setup.

Plugin

Before I go into the SIGABRT issue, I want to give a shoutout to Allan Ritchie @aritchie for his bluetoothle plugin. I have definitely learned a lot from it.

SIGABRT

Did I mention that I am not that familiar with iOS dev work? Or Apple for that matter? When starting up my application, it crashed the moment I tried to access the BLE adapter with this message:

Got a SIGABRT while executing native code. 
This usually indicates a fatal error in the mono runtime or one of the native libraries.

I had no idea what this actually meant. I had the above library sample app and it worked fine. I did some digging and found a post on the Xamarin Forms forums which said this usually corresponds to a privacy issue. And you can use the device logs to figure out which one. I wish I had kept that post so I could attribute it better.

I am using Visual Studio, so in the View | Other Windows there is a Device Log that will give you a view into your device. Be aware, it is literally a fire hose: stop and clear the log before you start your app and it will hopefully reduce some of the clutter.

I did find out that it was indeed a permission issue! I needed to add NSBluetoothPeripheralUsageDescription key and text prompt to the info.plist file. Once added, I was back in business.