Mod the Machine

Migrate .Net Add-Ins to registry free

Inventor 2012 allows your Add-Ins to be loaded without them being registered as a COM component in the Windows registry. These Add-Ins are called “registry free Add-Ins”. I was sure happy when I could have my Add-In load without having to use the Windows registry. It really makes installing custom applications much  easier.  The Inventor 2012 Add-In wizard provided with the SDK uses a new template that generates a Registry Free Add-In. If you want to migrate your existing Add-Ins without re-creating them from scratch (using the new template) you can follow these five steps. Happy migration! 1. Remove COM Visibility Uncheck the Register for COM interop check box on the “Compile” tab of the Application Properties dialog, as shown below:

For Visual Express Edition, the setting is slightly different, un-check the “Make assembly COM-Visible”:

Remove any code associated with registering the add-in in the registry. This typically just means removing the Register and Unregister methods from your add-in class. The AddInGuid property is in the same region as the registration functions, so if you intend on using this property in other areas of your add-in you’ll want to be careful not to delete it.

2. Create the manifest file

Create a new file in the same directory as your project file and name it “YourAddin.X.manifest”, where YourAddin will be replaced with the name of your add-in. Add the following to the manifest file. The portions highlighted in yellow need to be edited to match your add-in properties:

<?xml version="1.0"

      encoding="UTF-8"

      standalone="yes"?>

 

<assembly xmlns=

      "urn:schemas-microsoft-com:asm.v1"

          manifestVersion="1.0">

  <assemblyIdentity name="RegFreeVbAddin"

        version="1.0.0.0">

  </assemblyIdentity>

  <clrClass clsid=

      "{6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}"

    progid="RegFreeVbAddin.StandardAddInServer"

    threadingModel="Both"

    name=

"RegFreeVbAddin.RegFreeVbAddin.StandardAddInServer"

    runtimeVersion="1.0">

  </clrClass>

  <file name="RegFreeVbAddin.dll"

               hashalg="SHA1">

  </file>

</assembly>

The “name” attribute of the clrClass element consists of three parts, separated by dots: Assembly.Namespace.ClassName To make sure, you can retrieve the assembly name and root namespace from your project properties:

 

Note: The manifest file is not Unicode!

3. Embed the manifest during post-build

The next step is to add a post-build process to incorporate this manifest into your dll. The post-build process calls mt.exe which is a Microsoft utility that will embed the manifest into your AddIn’s dll. You define a post-build step through the Compile tab of the Application Properties dialog. On the Compile tab, click the “Build Events…” button and then on the “Build Events” dialog click the “Edit Post-build…” button. Finally enter the following string by replacing the correct Add-In name into the “Post-build Event Command Line” dialog, as shown below: call "%VS90COMNTOOLS%vsvars32" mt.exe -manifest "$(ProjectDir)RegFreeVbAddin.X.manifest" -outputresource:"$(TargetPath)";#2

Compile your project. This will cause the manifest to be embedded within your dll. If you get any errors when compiling, verify that the command line that you entered matches the one above. You can verify that the manifest has been correctly embedded by dragging the Add-In dll into Visual Studio. You should see the “RT_MANIFEST” folder, as shown below. Double clicking on the “2” icon will open a window to show you actual manifest data.

It appears that the “build events” functionality is not provided for Visual Basic Express. It is there for C# Express and of course regular versions of Visual Studio. If you use VB Express you can manually invoke the mt utility from the command line or create a batch file.

4. Create the .addin file

A requirement for all registry-free Add-Ins is to have an .addin file. With a registry based Add-In, Inventor relied completely on the registry to get information about the Add-In. The .addin file takes the place of the registry for this same information. The addin filename is in the form of Company.AddInName.Inventor.addin Below is the .addin file for my example Add-In with the portions to change highlighted:

<Addin Type="Standard">     <!--Created for Autodesk Inventor Version 16.0-->   <!--Override settings for ApplicationAddIn: RegFreeVbAddin-->     <ClassId>     {6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}   </ClassId>     <ClientId>     {6e41e3fb-439a-4cbe-b648-ed6a47eeac8d}   </ClientId>     <DisplayName>     RegFreeVbAddin   </DisplayName>     <Description>     A Registry-free Inventor Addin   </Description>     <Assembly>     C:\Autodesk\Inventor\MyAddins\RegFreeVbAddin.dll   </Assembly>     <LoadOnStartUp>1</LoadOnStartUp>   <UserUnloadable>1</UserUnloadable>   <Hidden>0</Hidden>   <SupportedSoftwareVersionGreaterThan>     15..   </SupportedSoftwareVersionGreaterThan>   <DataVersion>1</DataVersion>   <UserInterfaceVersion>1</UserInterfaceVersion>   <LoadBehavior>0</LoadBehavior> </Addin>

For most AddIns, the ClassId (required) and ClientId (required) elements will be the same value, which is the GUID at the top of the StandardAddInServer class. The value of the DisplayName (required) element can be anything and is the name of the add-ins as shown in the AddIn Manager. The Description (required) element can also be anything and is the description of the add-in as shown in the AddIn Manager. The Assembly (required) element defines the name of the AddIn dll. It also defines the path to the dll. There are 3 ways to specify the location of the binaries: A full path including the dll name. Only the dll name. Inventor will look for this dll in the <InstallPath>\bin\ folder followed by the folder in which the .addin manifest was found (i.e. same folder as the .addin file). A relative path including the dll name. Inventor will search for the dll in the specified relative path starting at the <InstallPath>\bin\ folder followed by a search in the specified relative path starting at the folder in which the .addin manifest was found. The LoadOnStartUp (optional - obsolete) element specifies whether the add-in should load on start up. Assumed to be true if this value is not specified. Value can be 0 or 1. The UserUnloadable (optional) element specifies whether the user can unload the add-in. Assumed to be true if this value is not specified (i.e. user can unload the add-in). Value can be 0 or 1. The Hidden (optional) element defines whether the add-in is visible in the Add-In Manager or not. A value of 1 indicates that it is hidden, although the end-user can still right-click within the Add-In Manager and choose “Show hidden members” to display all add-ins. The SupportedSoftwareVersionXXX (optional) element specifies the version(s) of Inventor that the add-in should be available in. Combinations of these can be used. These values are ignored if the .addin file is located in a version-specific folder (i.e. the add-in is always available for that Inventor version). The DataVersion (optional) element specifies the version of add-in data contained within Inventor documents. To be used by add-ins that store migrating data in Inventor documents, indicated by “DocumentInterests”. The UserInterfaceVersion (optional) element specifies the version of the user interface of the add-in. Incrementing this version results in all of the addin’s UI getting cleaned up during Inventor start-up. The LoadBehavior (optional) element allows you to control a brand new feature of Inventor 2012: this will determine for which document type the addin will be loaded. Basically this feature will improve the start-up time of Inventor by delaying the loading of the addin the first time a specific document type is created or open, for example if your addin is only providing part-specific functionalities, you can choose to let Inventor load it only when the user will open his first part in the session. Here is a table that recaps the various values this flag can take and its effect:

LoadBehavior	Effect
0	Load on Start-up (not recommended)
1	Load when any document is open/created
2	Load when first Assembly is open/created
3	Load when first Presentation is open/created
4	Load when first Drawing is open/created
10	Load OnDemand

Assumed to be 0 if this value is not specified. Installer considerations: In the case you are building an installer to deploy your Add-In, you may wonder how you would handle the situation where you let the user select the location where they will install the Add-In dll itself, as the .addin file needs to reflect this path, and the answer is that you have 2 choices here: Do not let the user select a custom location for the install and provide a relative path or no path at all: Inventor will try to load the addin from the locations described above in the “Assembly” element section. Let the user select a custom location, in which case you will have to create a custom dll called from a custom action inside your installer that will dynamically perform the editing of the .addin file based on the selected path.

5. Choose a location for .addin file

Copy the .addin file to one of the following directories, depending on the scope of your add-in and the operating system. Version Independent: The presence of a .addin file in the following locations indicates that the AddIn should be loaded in multiple versions of Inventor based on the values of the “SupportedSoftwareVersionXXX” settings in the manifest file. Windows XP: C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor Addins\ Windows7/Vista: C:\ProgramData\Autodesk\Inventor Addins\ Version Dependent: The presence of a manifest file in the following locations indicates that the AddIn should be loaded in a specific version of Inventor. The values of the “SupportedSoftwareVersionXXX” settings in the manifest file are ignored, if present. Windows XP: C:\Documents and Settings\All Users\Application Data\Autodesk\Inventor 2012\Addins\ Windows7/Vista: C:\ProgramData\Autodesk\Inventor 2012\Addins\ Per User Override: The manifest file in the following locations can be created when per user overrides need to be saved. The settings in these manifest files override the setting values in the manifest files found in the ‘all users’ folder. The names of these override manifest files match the names of the “master” files. Windows XP: C:\Documents and Settings\<user>\Application Data\Autodesk\Inventor 2012\Addins\ Windows7/Vista: C:\Users\<user>\AppData\Roaming\Autodesk\Inventor 2012\Addins\ After following these steps your Add-In should be found and loaded by Inventor without any entries in the registry. Wayne Brill

Bitmaps without VB6 IconToIPicture

I’m very excited to be joining Brian as a co-author on this blog. It’s my first blogging experience and I’m eager to start writing about the many and varied things we’re doing with Inventor’s API!. To start out I thought it would be interesting to discuss a different way to create IPictureDisp needed for button images.

Having to reference Microsoft.VisualBasic.Compatibility and use Microsoft.VisualBasic.Compatibility.VB6.Support.IconToIPicture() to create an IPictureDisp works, but I always thought there should be a better way to create the image for the user interface. Also in a future release of Inventor there is a good chance that it will support .NET framework 4 and warning messages occur using IconToPicture(). (Inventor 2012 uses .NET 3.5).

I was happy to find a utility class that my colleague Philippe Leefsma recently created that uses stdole.IPictureDisp instead of IconToPicture().

This zip file has a project that creates an AddIn that adds a panel to the assemble tab on the assembly ribbon and a panel to the model tab on the part ribbon. This project is a completed lab used in one of the Inventor API trainings. (Originally using IconToIPicture).

Here is the class from the project that creates the IPicutreDisp. (See below for some instructions on how to use this class).

Imports System.Runtime.InteropServices

 

 Public NotInheritable Class PictureDispConverter

    <DllImport("OleAut32.dll", EntryPoint:= _

    "OleCreatePictureIndirect", ExactSpelling:=True, _

      PreserveSig:=False)> _

    Private Shared Function OleCreatePictureIndirect( _

      <MarshalAs(UnmanagedType.AsAny)> _

      ByVal picdesc As Object, _

      ByRef iid As Guid, _

      <MarshalAs(UnmanagedType.Bool)> _

      ByVal fOwn As Boolean) _

                         As stdole.IPictureDisp

    End Function

 

    Shared iPictureDispGuid As Guid = _

        GetType(stdole.IPictureDisp).GUID

 

    Private NotInheritable Class PICTDESC

        Private Sub New()

        End Sub

 

        'Picture Types

        Public Const PICTYPE_UNINITIALIZED As Short = -1

        Public Const PICTYPE_NONE As Short = 0

        Public Const PICTYPE_BITMAP As Short = 1

        Public Const PICTYPE_METAFILE As Short = 2

        Public Const PICTYPE_ICON As Short = 3

        Public Const PICTYPE_ENHMETAFILE As Short = 4

 

        <StructLayout(LayoutKind.Sequential)> _

        Public Class Icon

            Friend cbSizeOfStruct As Integer = _

              Marshal.SizeOf(GetType(PICTDESC.Icon))

            Friend picType As Integer = _

                PICTDESC.PICTYPE_ICON

            Friend hicon As IntPtr = IntPtr.Zero

            Friend unused1 As Integer

            Friend unused2 As Integer

 

            Friend Sub New(ByVal icon As  _

                           System.Drawing.Icon)

                Me.hicon = icon.ToBitmap().GetHicon()

            End Sub

        End Class

 

        <StructLayout(LayoutKind.Sequential)> _

        Public Class Bitmap

            Friend cbSizeOfStruct As Integer = _

              Marshal.SizeOf(GetType(PICTDESC.Bitmap))

            Friend picType As Integer = _

              PICTDESC.PICTYPE_BITMAP

            Friend hbitmap As IntPtr = IntPtr.Zero

            Friend hpal As IntPtr = IntPtr.Zero

            Friend unused As Integer

 

            Friend Sub New(ByVal bitmap As  _

                           System.Drawing.Bitmap)

                Me.hbitmap = bitmap.GetHbitmap()

            End Sub

        End Class

    End Class

 

    Public Shared Function ToIPictureDisp(ByVal icon As  _

       System.Drawing.Icon) As stdole.IPictureDisp

        Dim pictIcon As New PICTDESC.Icon(icon)

        Return OleCreatePictureIndirect(pictIcon, _

                             iPictureDispGuid, True)

    End Function

 

    Public Shared Function ToIPictureDisp(ByVal bmp _

        As System.Drawing.Bitmap) As stdole.IPictureDisp

        Dim pictBmp As New PICTDESC.Bitmap(bmp)

        Return OleCreatePictureIndirect(pictBmp, _

                              iPictureDispGuid, True)

    End Function

End Class

How to use the PictureDispConverter class.

1. Add a reference to stdole (On the .NET tab of the Add Reference dialog)

2. In your project add a new class and copy the code above into the class.

3. Create a resource in the project.

4. Call  PictureDispConverter.ToIPictureDisp() and pass in the resource. Here is the code from the attached project that does this.

   Dim mIPictureDisp1 As IPictureDisp = _

         PictureDispConverter.ToIPictureDisp _

                                      (My.Resources.Tools)

 

   Dim mIPictureDisp2 As IPictureDisp = _

         PictureDispConverter.ToIPictureDisp _

                                      (My.Resources.wbTest)

 

Wayne Brill

Upgrading your Add-Ins to Support the Ribbon User Interface

I thought I should share some more of the work that was done for the last Autodesk University.  This class covered how to upgrade your add-in to use the ribbon user interface.  It was one of the new virtual classes and the video is available.  However, the paper contains all of the information in the video plus some additional material that I didn’t have time for in the video.

The paper answers the following questions:

1. From a user’s perspective, what is the ribbon user interface?
2. Can my VBA macros work with the ribbon?
3. Will my existing add-ins work with the ribbon?
4. How does the API support the ribbon?
5. What do I need to consider when adding my buttons to the ribbon?
6. What do I do about the classic interface?

Below are links to the paper and some sample programs.

Paper
Sample Programs

How to Write an Inventor Add-In

I’ve posted similar material previously but this is more complete and up to date.  The attached paper and code is from a presentation at this past Autodesk University.  I believe the paper can be used by itself and is not dependent on you having been at the presentation.  The primary focus is on someone that’s now using VBA and would like to move to add-ins, although it will also serve as a good general introduction for anyone that wants to learn more about add-ins.

The paper tries to answer the following questions:

1. What is an Add-In?
2. Why would you want to create an Add-In?
3. How do you create an Add-In?
4. How do you convert your VBA macros?
5. How do you execute an Add-In command?
6. How do you debug an Add-In?
7. How do you deploy an Add-In?

The languages used are VB Express 2008 and Visual Basic from Visual Studio 2008.  It also covers the differences you’ll run into between VBA and VB.Net.

Paper
Sample Files

Update to Visual Basic 6 Add-Ins and 64-Bit Windows

I recently made a post discussing the issues around Add-Ins written using Visual Basic 6 and 64-bit Windows.  I made the mistake of not testing it completely before making that post.  Everything in the original posting is correct but it’s incomplete because I hadn’t thought through the registration process.  I’ve update the original post to add more information to cover registering your Add-In on the 64-bit machine.

Visual Basic 6 Add-Ins and 64-Bit

I saw a question in the customization newsgroup where someone has an Add-In written using Visual Basic 6 and wants to use that add-in with the 64-bit version of Inventor.  In doing this there are some issues to be aware of:

• 64-bit Windows can run both 32-bit and 64-bit applications (exe’s and dll’s).
• Visual Basic 6 can only create 32-bit applications (exe’s and dll’s).
• A 64-bit exe can only load 64-bit dll’s.  It cannot use 32-bit dll’s.

In this case, Inventor is a 64-bit exe and the Add-In is a dll.  A VB 6 Add-In will be a 32-bit dll.  Based on the statements above, this means that it can’t be used by 64-bit Inventor since that results in a 64-bit exe trying to load a 32-bit dll.  There are two possible solutions; change the add-in to be an exe instead of a dll or convert the add-in to .Net where you have the ability to create a 64-bit dll.

 

Changing a VB 6 Add-In from a DLL to an EXE
Changing an existing VB 6 Add-In from a dll to an exe is very easy.  Open the project and use the Properties command in the Project menu to display the dialog shown below.  Change the project type from “AcitveX DLL” to “ActiveX EXE”.  Recompile and now you have an exe Add-in.  However, continue reading…

There are two things to be aware of when converting a dll Add-In to an exe Add-In.  The first is that the performance of the exe Add-In won’t be as good as the dll Add-In.  A dll Add-In is loaded into Inventor’s process space and API calls are made directly.  An exe Add-In runs in its own process space and is separate from Inventor.  This requires API calls to be marshaled between the two processes which is not as efficient.  How much slower it is will differ from Add-In to Add-In because it depends on what kind of API calls you’re making.

The second issue is more of a problem and is a side-effect of the fact that data has to be marshaled between the two processes.  Inventor’s API relies on Microsoft technology to do the marshaling between the two processes.  Unfortunately, this technology doesn’t support the marshaling of bitmap data.  This means that any Inventor API calls you make where an IPictureDisp object is passed as an argument won’t work with an exe Add-In. 

Their are only a few calls in Inventor’s API that work with bitmaps but one of these is a function that most Add-Ins use.  That’s the AddButtonDefinition method that’s used to create a button for the user-interface.  An exe Add-In won’t be able to have icons on its buttons because of this limitation.  Icons are optional so you can remove those arguments from the AddButtonDefinition call and then the Add-In should function correctly but you’ll only have text on the button instead of an icon.

Another area of the API where a bitmap is used is when getting or setting the thumbnail image for a document.  This will fail for an exe Add-In.

Using the VB6 version of the SimpleAddIn sample that’s delivered as part of Inventor’s SDK, here are the changes that are required to make it work on 64-bit Windows.

1. Change the project type to ActiveX EXE, as explained above.
   
2. Comment out the lines that load the bitmaps for the icons.

   Dim oIcon1 As IPictureDisp
   '    Dim oIcon2 As IPictureDisp
   '    Dim oIcon3 As IPictureDisp
   '    Set oIcon1 = LoadPicture(App.Path & "\AddSlotOption.ico")
   '    Set oIcon2 = LoadPicture(App.Path & "\Slot.ico")
   '    Set oIcon3 = LoadPicture(App.Path & "\Toggle.ico")
   

3. Edit the lines where the buttons are created to remove the icons.  The following three lines (please pay attention to the line wrapping) are changed from this:
   Set oButtonDefAddOption = ..., "Add slot option", oIcon1, oIcon1)
   Set oButtonDefDrawSlot = ... , "Draw Slot", oIcon2, oIcon2)
   Set oButtonDefToggleSlotState = ..., "Toggle Slot State", oIcon3, oIcon3)

   to this:

   Set oButtonDefAddOption = ..., "Add slot option")  
   Set oButtonDefDrawSlot = ... , "Draw Slot") 
   Set oButtonDefToggleSlotState = ..., "Toggle Slot State")

   This is possible because the icon arguments are optional.

4. Compile the Add-In to create the EXE version of it and run the the registration file to register it, (AddInSample.reg in the case of the example Add-In).
   
5. Run Inventor to make sure the Add-In is loading and working correctly on a 32-bit system.
   
   The tricky part now is getting this Add-In to register correctly on a 64-bit system.  Since it’s a 32-bit application, by default it will register itself in the 32-bit section of the registry on a 64-bit system, but Inventor will only look for Add-Ins in the main section of the registry, which is the 64-bit section in this case.  The following steps illustrate one way to get the registration in the correct area on the 64-bit system.
   
6. Find out the CLSID for your Add-In.  There are two ways to find this out.  If you’re already using a .reg file to register your Add-In, it will be in that.  Here’s the second line from the AddInSample.reg file that’s part of the sample.

   [HKEY_CLASSES_ROOT\CLSID\{DB59D9A7-EE4C-434A-BB5A-F93E8866E872}]

   The “{DB59D9A7-EE4C-434A-BB5A-F93E8866E872}” portion of the line is the CLSID of the Add-In.  Just remembering the first 3 or 4 characters is enough for what you need to do in the subsequent steps.

   The other way to find out the CLSID is to look it up in the registry.  First, you need to know what to look up.  You can use the ProgID of your Add-In.  This is determined by the name of your project and the name of the class that supports the Add-In interface.  You can see these in the Properties window inside Visual Basic.  In this case the ProgID of the Add-In will be “AddInSample.clsSampleAddIn”.

   

   Run RegEdit and look in the HKEY_CLASSES_ROOT section for the ProgID of your Add-In.  This is shown below for the sample Add-In.

   

   Once you’ve found the ProgID for the Add-In, expand the key in the registry and then expand the Clsid key and select “Clsid”.  In the right-hand portion of the Registry Editor you’ll see the CLSID of your Add-in.

7. Now using the Registry Editor, find the HKEY_CLASSES_ROOT\CLSID section of the registry.  Within this key, find the CLSID for your Add-In.  The picture below shows this key selected in the browser and expanded so you can see its subkeys.  You can verify that you have the correct registry key by checking on the right-hand side of the Registry Editor to see if the ProgID matches the one for your Add-In.
   
   
   
8. Right-click on the CLSID key of your Add-In and choose Export, as shown below.  Specify a name and save the .reg file.
   
   
9. Copy the Add-In to the 64-bit system by copying the EXE, the reg file you just created in the previous step, and any other files your Add-in might require.  The SimpleAddIn sample doesn’t need anything except these two files but your Add-In may need some other files.
   
10. Edit the .reg file so that it contains the correct path for your Add-In as it exists on the 64-bit system.  You’ll need to edit one line in the .reg file to correct the path.  The edited portion is highlighted below.  Notice how the backslashes of the actual path are replaced with double back slashes.

    [HKEY_CLASSES_ROOT\CLSID\{DB59D9A7-…-F93E8866E872}\LocalServer32]
    @="C:\\Users\\ekins\\Documents\\AddInSample.exe"

11. Run the .reg file to register your Add-In.  When you run Inventor, your Add-In should be running and work.  If it isn’t working, check the Add-In Manager to see if your Add-In is in the list.  If it is in the list but isn’t listed as being loaded, then the Add-In is likely failing in the Activate method.  Make sure you removed the icons as instructed above and double-check that you’re not trying to access something that’s not available on the 64-bit machine.
    
    If your Add-In doesn’t show up at all in the Add-In Manager then go through the directions above and double-check that you didn’t leave out anything.  For your Add-In to not show up at all indicates that it’s not being registered correctly.

Converting a Visual Basic 6 Add-In to 64-Bit
Visual Basic 6 is only capable of creating 32-bit applications.  To convert an existing project to a 64-bit application will require porting the application to VB.Net, which does support the creation of a 64-bit application.  VB.Net has a VB 6 conversion tool but I would suggest that you NOT use it.  Instead, I would use the Add-In Wizard that’s delivered as part of Inventor’s SDK to create a new Add-In and copy the code manually from VB 6 into the VB.Net project.  There are too many differences between VB 6 and VB.Net and my experience is that cleaning up the resulting code from the conversion is harder than copying over smaller portions of code at a time an manually converting it.

You’ll also need to recreate your dialogs.  The dialogs are much more powerful in VB.Net so this lets you take advantage of those new features.  The basics of converting your code is covered in this post: Converting VBA Auto Macros to an Add-In.

Extracting a Specific Size Icon From a .ico File

Here’s something that I recently discovered after a lot of searching and some experimenting.  In my add-ins I prefer to use .ico files for my button icons.  Icons have some advantages over .bmp files in that you can define a transparent background and you can save multiple images within a single .ico file.  This is convenient because to fully support Inventor’s interface you should have three icon sizes, as listed below.

16x16 pixels – Used for small icons in both Classic and Ribbon interfaces.
24x24 pixels – Used for large icons in Class interface.
32x32 pixels – Used for large icons in Ribbon interface.

Using an icon editor it’s fairly easy to create the icons of the various sizes and then use that .ico file in my program.  What I couldn’t figure out was how to extract an icon of a specific size from the .ico file.  My searches just lead to postings from other who had the same question but no answers.  I finally began experimenting and found something that works.

In my add-in project I add each of the .ico files as a resource to my project.  In VB.Net you can access any item in your resources by name.  The name of my icon in the example below is “MyCommand1”.  The code below reads the icon of the specified size from the resource and ends up holding a reference to an Icon object. 

Dim smallIcon As System.Drawing.Icon
smallIcon = New System.Drawing.Icon(My.Resources.MyCommand1, 16, 16)

The code below reads in the large icon file from the same icon resource. 

Dim largeIcon as Sytem.Drawing.Icon
largeIcon = New System.Drawing.Icon(My.Resources.MyCommand1, 32, 32)

You can’t directly use an Icon object with Inventor’s API since it is expecting an IPictureDisp object.  The code below demonstrates how to convert an Icon to an IPictureDisp.  You’ll need to reference the Microsoft.VisualBasic.Compatibility and stdole libraries into the project first.

Dim smallPic As stdole.IPictureDisp
smallPic = Microsoft.VisualBasic.Compatibility.VB6.IconToIPicture( _
                                                          smallIcon)

Signing Your .Net Add-In

In my previous posting Converting VBA Auto Macros to an Add-In I described how to create a basic add-in and install it.  There's one additional item that I didn't cover in that posting related to the installation of your add-in.  When you install your add-in you'll get the warning shown below.  It is just a warning and can be ignored, but it's often misinterpreted as an error and it would be best to avoid it.

If you read the warning you'll see that it doesn't like you to use the /codebase argument with an unsigned assembly.  We have to use the /codebase argument with an add-in to get it to register correctly so it's not an option to leave it out.  The only other option is to sign the assembly, which is what I'll show you how to do here.

What is Signing? 
Signing is a way of creating a unique ID for your add-in.  This is also referred to as a "strong name".  Without signing your add-in there is the potential, although very minimal, of it conflicting with another .Net assembly.  A strong name consists of the filename, a key, version, culture (language), and processor type.

The concept of signing can also extended to serve as a security mechanism.  In addition to providing a unique identifier for the assembly it also identifies the make of the assembly.  Microsoft calls this Authenticode and the process is handled by Verisign.  This type of signing is not required and not something I'll discuss here.

Creating a Key
To sign an assembly you need to have a unique key to sign it with.  You generate a key using the .Net sn.exe (strong name) utility.  This utility is located in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin.  I would recommend creating a new directory for the resulting key because a single key can be used to sign all of your add-ins.  Here's an example of executing this utility from the command line.  (This is for Visual Studio 2008.  If you're using something else you may need to search for sn.exe.)

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sn.exe" -k MyKey.snk

This is all shown below.  Note that because of the spaces in some of the directory names that the double quotes around the full command line are required.

 

If you have a version of visual studio besides one of the Express editions, you can use the Visual Studio Command Prompt to make this a bit easier because you won't need to know where the utility is.  This creates a cmd window where the paths are set to all of the various .Net related tools.  If you're new to Visual Studio, you open a Visual Studio Command Prompt window through the Start menu in the "Visual Studio Tools" list, as shown below.

 

In the Visual Studio Command Prompt you only need to enter:

sn -k MyKey.snk

Signing the Add-In
Now that you have the key, you can use it to sign your add-in.  To do that run the Project -> Properties... command, (the last command in the Project menu).  Pick the "Signing" tab, click the "Sign the assembly" check box and browse to select your key file.  Recompile your project and you now have a signed assembly.

Now when you run the regasm utility when installing your add-in you should see this and no more errors.

Using a signed Add-In

Using a signed add-in is no different than an unsigned one with one exception.  To use it you just need to copy it to the computer you want to use it on and register it.  That's the same process as an unsigned one, except you won't get the warning message anymore.  The difference to be aware of is if you want to replace the existing add-in with a newer version.  With an unsigned add-in you can just copy the new dll to the computer and everything is fine.  With a signed add-in you must re-register the add-in.  Signing ties the registration to the dll version so you need to re-register the add-in to update the version information in the registry to match the current dll.

(Thanks to Neil Munro for a question about the versioning that caused me to investigate this some more and update this posting.)

Converting VBA Auto Macros to an Add-In

This posting assumes you have a VBA auto macro and want to quit using the auto macro functionality and convert it to an add-in. See the previous posting VBA Document Projects as to why you might want to do this.  Without a lot of explanation, here are the prerequisites and the steps required to create the add-in.

Here is an example of an automatic macro that exists within a drawing document. It automatically writes out dwf and pdf files of the drawing whenever the drawing is saved.  The rest of this post looks at the process to create an add-in to replace this auto macro.

Public Sub AutoSave()
    ' Get the filename minus the extension.
    Dim strFilename As String
    strFilename = ThisDocument.FullFileName
    strFilename = Left(strFilename, Len(strFilename) - 4)

    ' Save the current SilentOperation and then turn it on.
    ' This will suppress the dwf viewer from being displayed.
    Dim currentSetting As Boolean
    currentSetting = ThisApplication.SilentOperation
    ThisApplication.SilentOperation = True

    ' Save the file as dwf.
    Call ThisDocument.SaveAs(strFilename & ".dwf", True)

    ' Reset SilentOperation back to its previous value.
    ThisApplication.SilentOperation = currentSetting

    ' Save the file as pdf.
    Call ThisDocument.SaveAs(strFilename & ".pdf", True)
End Sub

What You'll Need

A Programming Language - To write an add-in you need to use a language that supports creating COM components. For this example I'll illustrate the process using both Visual Basic 2008 and C# 2008. Microsoft provides free Express versions of both of these languages. You can install them from the Microsoft web site. Microsoft also provides online training resources for learning these languages. If this is all new to you and you don't know which one to get I would recommend Visual Basic, but it really is a personal preference.

Inventor SDK Developer Tools - You'll also need some Inventor specific development tools.  This is delivered when you install Inventor but you need to run its setup to install it. Assuming you're using Inventor 2009, locate the following file in Explorer and run it:

C:\Program Files\Autodesk\Inventor 2009\SDK\DeveloperTools.msi

Inventor 2009 was released when Visual Studio 2005 was the current development platform. Because of that the Add-In wizard provided with it does not get installed for use with Visual Studio 2008.  To work around this you can copy the files below to the specified directories.  Don't unzip the files but just copy the file as-is.

VB 2008
Copy VBInventorAddInTemplate.zip to 
"My Documents\Visual Studio 2008\Templates\ProjectTemplates"

C# 2008
Copy VCSInventorAddInTemplate.zip to 
"My Documents\Visual Studio 2008\Templates\ProjectTemplates"

Creating the Add-In

The add-in is created using the add-in template. Start VB or C# and choose to create a new project. For the template choose "Autodesk Inventor AddIn", as shown below. You can also specify the name of the add-in at this point, ("AutoSaveAddIn" in the example below).

 

In the Visual Studio Solution Explorer you'll see the various files listed that were created for the project. For a Visual Basic add-in, most of the code is in the StandardAddInServer.vb file and for a C# add-in it is in the StandardAddInServer.cs file. Double-click on this file to open it in the code editor. You should see something very similar to one of the pictures below. Your GuidAttribute value will be different than those shown below since that is unique for every add-in.

 
Visual Basic Code Window

Visual C# Code Window

Editing the Name and Description of the Add-In

One common thing you'll want to do when creating an add-in is to define the name and description of the add-in as it will be seen in the Add-In Manager. You do this by editing the code in the "COM Registration" block of the code. Click on the "+" next to this region to expand it. The code in red is the portion I've changed to modify the name and the description. The code below is from the VB add-in but the C# code is almost identical and it will be obvious what to edit.

Public Shared Sub Register(ByVal t As Type)
   Dim clssRoot As RegistryKey = Registry.ClassesRoot
   Dim clsid As RegistryKey = Nothing
   Dim subKey As RegistryKey = Nothing
   Try
      clsid = clssRoot.CreateSubKey("CLSID\" + AddInGuid(t))
      clsid.SetValue(Nothing, "Automated DWF and PDF Save")
      subKey = clsid.CreateSubKey( _  
    "Implemented Categories\{39AD2B5C-7A29-11D6-8E0A-0010B541CAA8}")
      subKey.Close()       subKey = clsid.CreateSubKey("Settings")
      subKey.SetValue("AddInType", "Standard")
      subKey.SetValue("LoadOnStartUp", "1")
      'subKey.SetValue("SupportedSoftwareVersionLessThan", "")
      subKey.SetValue("SupportedSoftwareVersionGreaterThan", "12..")
      'subKey.SetValue("SupportedSoftwareVersionEqualTo", "")
      'subKey.SetValue("SupportedSoftwareVersionNotEqualTo", "")
      'subKey.SetValue("Hidden", "0")
      'subKey.SetValue("UserUnloadable", "1")
      subKey.SetValue("Version", 0)
      subKey.Close()
      subKey = clsid.CreateSubKey("Description")
      subKey.SetValue(Nothing, "Saves drawings as DWF and PDF.")
   Catch ex As Exception
      System.Diagnostics.Trace.Assert(False)
   Finally
      If Not subKey Is Nothing Then subKey.Close()
      If Not clsid Is Nothing Then clsid.Close()
      If Not clssRoot Is Nothing Then clssRoot.Close()
   End Try
End Sub

Reacting to Events in Visual Basic

Now we can add the code that will react anytime a document is saved. For a VB add-in, add the code below that's shown in red. The second line is in the "ApplicationAddInServer Members" code region so you'll need to expand that region to see the code.  The code consists of a declaration and an assignment.

Public Class StandardAddInServer
   Implements Inventor.ApplicationAddInServer
   ' Inventor application object.
   Private m_inventorApplication As Inventor.Application
   Private WithEvents m_appEvents As Inventor.ApplicationEvents

#Region "ApplicationAddInServer Members"
   Public Sub Activate( _

          ByVal addInSiteObject As Inventor.ApplicationAddInSite, _ 
          ByVal firstTime As Boolean) _

               Implements Inventor.ApplicationAddInServer.Activate
       ' Initialize AddIn members.
       m_inventorApplication = addInSiteObject.Application
       m_appEvents = m_inventorApplication.ApplicationEvents
   End Sub

At the top of the code window are two combo boxes. The one on the left displays a list of classes and the one on the right displays a list of methods for the selected class. Choose "m_appEvents" on the left and "OnSaveDocument" on the right, as shown below. This will insert the sub m_appEvents_OnsaveDocument as shown below. This is the event handler for the OnSaveDocument event will be called whenever a document is saved in Inventor.

 

Here's code that's equivalent to the original AutoSave macro. This performs a couple of additional checks that the original automatic macro didn't need to do. First, the OnSaveDocument is fired before and after the document is actually saved.  This listens for when the event is fired after the Inventor save. The event is also fired whenever any document is saved. This looks for and only handles drawing documents.

Private Sub m_appEvents_OnSaveDocument( _                  
               ByVal DocumentObject As Inventor._Document, _  
               ByVal BeforeOrAfter As Inventor.EventTimingEnum, _  
               ByVal Context As Inventor.NameValueMap, _  
               ByRef HandlingCode As Inventor.HandlingCodeEnum) _  
                                  Handles m_appEvents.OnSaveDocument 
  If BeforeOrAfter = EventTimingEnum.kAfter Then 
    If DocumentObject.DocumentType = DocumentTypeEnum.kDrawingDocumentObject Then 
      ' Get the filename minus the extension. 
      Dim filename As String 
      filename = DocumentObject.FullFileName 
      filename = Left(filename, Len(filename) - 4) 

      ' Save the current SilentOperation and then turn it on.  
      ' This will suppress the dwf viewer from being displayed.  
      Dim currentSetting As Boolean  
      currentSetting = m_inventorApplication.SilentOperation  
      m_inventorApplication.SilentOperation = True 

      ' Save the file as dwf.  
      DocumentObject.SaveAs(filename & ".dwf", True)  

      ' Save the file as pdf.  
      DocumentObject.SaveAs(filename & ".pdf", True)  

      ' Reset SilentOperation back to its previous value.  
      m_inventorApplication.SilentOperation = currentSetting 
    End If  
  End If
End Sub

Reacting to Events in C#

The code highlighted in red below was added to support handling the save event in C#.  The last two lines are in the "ApplicationAddInServer Members" code region so you'll need to expand that region to see the code.  The line where the delegate is created to handle the event is mostly created by using Intellisense.  Go slowly as you type and you'll see options pop up that allow you to press the tab key to create much of the code.

private Inventor.Application m_inventorApplication;
private Inventor.ApplicationEvents m_appEvents = null;

public StandardAddInServer()
{
}
#region ApplicationAddInServer Members

public void Activate(

               Inventor.ApplicationAddInSite addInSiteObject,

               bool firstTime)
{
   // Initialize AddIn members.
   m_inventorApplication = addInSiteObject.Application;
   m_appEvents = m_inventorApplication.ApplicationEvents;

   // Create the delegate object to handle the event.
   m_appEvents.OnSaveDocument += new 
        ApplicationEventsSink_OnSaveDocumentEventHandler(

                                     m_appEvents_OnSaveDocument);
}

Intellisense can also create the event implementation code as you're typing the line above.  Below is the code it created with the additional code in red that I added to save the dwf and pdf files.

void m_appEvents_OnSaveDocument(_Document DocumentObject,

                EventTimingEnum BeforeOrAfter,

                NameValueMap Context,

                out HandlingCodeEnum HandlingCode)
{
   // A value has to be returned for the handling code.
   HandlingCode = HandlingCodeEnum.kEventNotHandled;

   if (BeforeOrAfter == EventTimingEnum.kAfter)
   {
      if (DocumentObject.DocumentType == DocumentTypeEnum.kDrawingDocumentObject)
      {
         // Get the filename minus the extension.
         String filename = DocumentObject.FullFileName;
         filename = filename.Substring(0, filename.Length - 4);

         // Save the current SilentOperation and then turn it on.
         // This will suppress the dwf viewer from being displayed.
         Boolean currentSetting = m_inventorApplication.SilentOperation;
         m_inventorApplication.SilentOperation = true;

         // Save the file as dwf.
         DocumentObject.SaveAs(filename + ".dwf", true); 

         // Save the file as pdf.
         DocumentObject.SaveAs(filename + ".pdf", true);

         // Reset SilentOperation back to its previous value.
         m_inventorApplication.SilentOperation = currentSetting; 
      }
   }
}

Cleaning Up

Finally, just a bit of code to clean up everything when the add-in is unloaded.  This is in the Deactivate method of the add-in.  The code I added is in red.

Public Sub Deactivate() Implements Inventor.ApplicationAddInServer.Deactivate
   ' Release objects.
   Marshal.ReleaseComObject(m_appEvents)
   m_appEvents = Nothing

   Marshal.ReleaseComObject(m_inventorApplication)
   m_inventorApplication = Nothing

   System.GC.WaitForPendingFinalizers()
   System.GC.Collect()
End Sub

Here's the equivalent code for C#.

public void Deactivate()
{
   // Disconnect the event delegate.
   m_appEvents.OnSaveDocument -= new
       ApplicationEventsSink_OnSaveDocumentEventHandler(

                                m_appEvents_OnSaveDocument);

   // Release objects.
   Marshal.ReleaseComObject(m_appEvents);
   m_appEvents = null;
   Marshal.ReleaseComObject(m_inventorApplication);
   m_inventorApplication = null;

   GC.WaitForPendingFinalizers();
   GC.Collect();
}

Using the Add-In

Now all you need to do is build the add-in.   Building the add-in creates the dll and also registers it.  When you run Inventor you should see the add-in in the Add-In Manager and when you save a drawing document the corresponding pdf and dwf files will also be created.

To use the add-in on another computer you need to copy the add-in dll to that computer and register it.  Below are some commands you can use within .bat files to both register and unregister the add-in for 32 and 64-bit installations.

Register on 32-bit

@echo off
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe /codebase AutoSaveAddIn.dll
PAUSE

Unregister on 32-bit

@echo off
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe /unregister AutoSaveAddIn.dll
PAUSE

Register on 64-bit

@echo off
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe /codebase AutoSaveAddIn.dll
PAUSE

Unregister on 64-bit

@echo off
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe /unregister AutoSaveAddIn.dll
PAUSE

When you test the add-in you can't just open an existing drawing, immediately save it, and expect to see the dwf and pdf files.  The reason is because the drawing hasn't changed so clicking the save button doesn't do anything.  If you make any change to the drawing, i.e. edit an iProperty or move a view or dimension, the OnSaveDocument event is fired and the additional files will be created.