a software development blog by Bojan Resnik

  • Archives

  • Advertisements

Installing the same managed addin in 32bit and 64bit Autodesk Inventor

Posted by Bojan Resnik on May 21, 2009

I have an addin for AutoDesk Inventor 2009, written in C# and a setup project to go with it. In order to register the addin with Inventor, I needed to register the assembly with “/codebase” switch, so I made a custom installer action:

public partial class AddinInstaller : Installer
    public override void Install(System.Collections.IDictionary stateSaver)
        RegistrationServices regsrv = new RegistrationServices();
        regsrv.RegisterAssembly(GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase);

    public override void Uninstall(System.Collections.IDictionary savedState)

        RegistrationServices regsrv = new RegistrationServices();

The actual registration code run by the registration service modifies some registry keys under HKEY_CLASSES_ROOT. This worked fine on Windows XP, but when run on my Vista 64, the setup completed successfully, but failed to register the addin with Inventor. The reason became apparent when I realized that my Inventor installation is also 64 bit – which means it looks for the keys using the 64bit view of the registry, while the installer action runs with the 32bit view.

The code itself is all C#, compiled as “Any CPU”, so it should have no problems running unmodified with both 64 and 32 bit Inventors. The only problem is how to run the installer as 64 bit. I also wanted to allow the same MSI to be used on all platforms, so compiling multiple versions was not an option. And searching the net, I got the impression that it would not solve the problem anyway – at least not without some other tools.

The solution I came up with is simpler: instead of using RegistrationServices object, I can manually execute the RegAsm.exe tool to register the assembly. On my Vista 64, there are two versions of this tool:

  • C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
  • C:\Windows\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe

The directories might not be the same on other machines, of course. Fortunately, .NET provides the RuntimeEnvironment.GetRuntimeDirectory() static method which returns the folder of the common language runtime. On my machine, it returns C:\Windows\Microsoft.NET\Framework\v2.0.50727\ inside the installer action. We can use this, combined with RuntimeEnvironment.GetSystemVersion() to construct the paths to 32bit and 64bit versions of the tool:

public partial class AddInInstaller : Installer 
    public AddInInstaller() 
    { InitializeComponent(); }

    public override void Install(IDictionary stateSaver) 

    public override void Uninstall(IDictionary savedState) 

    private static void RegAsm(string parameters)
        // RuntimeEnvironment.GetRuntimeDirectory() returns something like
        //    C:\Windows\Microsoft.NET\Framework64\v2.0.50727\
        // We need to get to the
        //    C:\Windows\Microsoft.NET
        // part in order to create 32 and 64 bit paths
        var net_base = Path.GetFullPath(Path.Combine(RuntimeEnvironment.GetRuntimeDirectory(), @"..\.."));
        // Create paths to 32bit and 64bit versions of regasm.exe
        var to_exec = new[]
            string.Concat(net_base, "\\Framework\\", RuntimeEnvironment.GetSystemVersion(), "\\regasm.exe"), 
            string.Concat(net_base, "\\Framework64\\", RuntimeEnvironment.GetSystemVersion(), "\\regasm.exe")

        var dll_path = Assembly.GetExecutingAssembly().Location;
        foreach (var path in to_exec)
            // Skip the executables that do not exist
            // This most likely happens on a 32bit machine when processing the path to 64bit regasm
            if ( !File.Exists(path) )
            var process = new Process
                StartInfo =
                    CreateNoWindow = true,
                    ErrorDialog = false,
                    UseShellExecute = false,
                    FileName = path,
                    Arguments = string.Format("\"{0}\" {1}", dll_path, parameters)
            using (process)

8 Responses to “Installing the same managed addin in 32bit and 64bit Autodesk Inventor”

  1. Randy said

    I have the Swrink wrap Addin for Inventor 2009 32-bit that will not run with my Inventor 2009 64-bit system, will this allow me to install the addin?

    • Bojan Resnik said

      Not necessarily – the addin has to be built as ‘Any CPU’ in order to be supported with both 32bit and 64bit versions of Inventor.

      You can manually run 64bit RegAsm.exe from the command line to attempt registering the addin with 64bit Inventor. Note, howeve, that if the addin is not comptaible with 64bit, either this will not work or the addin will not appear in 64bit Inventor.

  2. Hello,
    sorry my english is bad.
    I have many problem with Addin for Inventor 64bit.
    Sorry, but can you send a example of addin (for x86 / x64) and a installer.

    I would like send money.


  3. Philippe said

    Hi Sir,

    Thanks for the trick!

    I created a single installer for my Inventor addin, so I used target platform x86 in order to be able to run it on both platforms (which you don’t mention).

    My issue is that when installing on 64b the default path proposed is (let’s say) “C:\Program Files(x86)\…”, which obviously will lead the user to install at a wrong location.

    I would like to know if you dealt with this problem? Of course the solution would be to detect the the platform is 64 and correct the default path accordingly. I would not prefer to use a “hard coded” default path if possible, but I’m not an MSI expert.


    • Bojan Resnik said

      Yes, obviously, in order for the installer to run on 32bit platforms the target platform must be x86.

      I’m sorry I can’t help you with installation location, as I was not concerned with it – to me, any location is fine as long as the addin works correctly in Inventor. My users don’t care either – they just click through the installer and run Inventor afterwards. The only things they expect is that the addin works and that it can be uninstalled if needed.


  4. Ecko said

    nice share, thanks

  5. Samir said

    I had the same problem, but in my case it was a SolidWorks add-in…. 🙂

    It seems both “worlds” have similar problems.

    Thank you, it was very helpful.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: