Share

Converting an Existing Add-In to be Registry-Free

The following describes the process of converting a standard add-in into a registry-free add-in. Since the process is different for the different programming languages, the process is described for Visual Basic, C#, and VC++.

Making your Visual Basic Add-In Registry Free

  1. Create a new file in the same folder as your project file with the name "MyOEMApp.X.manifest", where MyOEMApp 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. 

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="MyOEMApp" version="1.0.0.0" />
  <clrClass clsid="{2bf59d73-5170-4524-b0e1-391760aaffa5}" 
            progid="MyOEMApp.StandardAddInServer" 
            threadingModel="Both" 
            name="MyOEMApp.MyOEMApp.StandardAddInServer" 
            runtimeVersion="" />
  <file name="MyOEMApp.dll" hashalg="SHA1" />
</assembly>

    The “name” attribute of the clrClass element consists of three parts, separated by periods. The first is the name of the root namespace, which is highlighted below.



    The second part is the namespace that the COM class is defined within. For this example is it MyOEMApp and is highlighted below. The Last piece is the name of the class that implements the ApplicationAddInServer interface, which is “StandardAddInServer” in this example and is also highlighted below.


  2. 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 add-in’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 lines below into the “Post-build Event Command Line” dialog, as shown below; OEMTestAddin is the name of your add-in. 
    call "%VS100COMNTOOLS%vsvars32"
mt.exe -manifest "$(ProjectDir)OEMTestAddin.X.manifest" -outputresource:"$(TargetPath)";#2


  3. 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.

Skip to step 4 below, which is the same for all languages.



Making your C# Add-In Registry Free

  1. Create a new file in the same directory as your project file and name it “CSharpOEMAddIn.X.manifest”, where CSharpOEMAddIn is 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. 

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="InvAddIn" version="1.0.0.0" />
  <clrClass clsid="{2bf59d73-5170-4524-b0e1-391760aaffa5}" 
            progid="CSharpOEMAddIn.StandardAddInServer" 
            threadingModel="Both" 
            name="CSharpOEMAddIn.StandardAddInServer" 
            runtimeVersion="" />
  <file name="InvAddIn.dll" hashalg="SHA1" />
</assembly>

    The “name” attribute of the assemblyIdentity element is the name of the assembly, which is highlighted below.



    The “name” attribute of the clrClass element consists of two parts, separated by periods. The first is the name of the namespace that the COM class is defined within. For this example is it CSharpOEMAddIn, and the second part is the name of the class that implements the ApplicationAddInServer interface, which is “StandardAddInServer”. Both of these are highlighted below.


  2. 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 add-in’s dll. You define a post-build step through the Build Events tab of the Application Properties dialog. On the Build Events tab, click the “Edit Post-build…” button. Enter the string below into the “Post-build Event Command Line” dialog, as shown below. Replace InvAddin with the name of your add-in. 
    call "%VS100COMNTOOLS%vsvars32"
mt.exe -manifest $(ProjectDir)INVAddin.X.manifest -outputresource:"$(TargetPath)";#2


  3. 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 function 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.

Skip to step 4 below, which is the same for all languages.



Making your C++ Add-In Registry Free

  1. Create a new file in the same directory as your project file and name it “CPPOEMAddIn.X.manifest”, where CPPOEMAddIn is 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. 

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="CPPOEMAddIn" version="1.0.0.0" />
  <clrClass clsid="{2bf59d73-5170-4524-b0e1-391760aaffa5}" 
            progid="CppOEMAddIn.CppOEMAddInAddInServer" 
            threadingModel="Both" 
            name="CppOEMAddIn.CppOEMAddInAddInServer" 
            runtimeVersion="" />
  <file name="CppOEMAddIn.dll" hashalg="SHA1" />
</assembly>

    The “name” attribute of the assemblyIdentity element is the name of the project, which is highlighted below.



    The clsid is the class ID for your add-in and can be found in the .idl file associated with your add-in, which is shown below. Remember that the braces are required in the manifest file.

    The “name” attribute of the clrClass element consists of two parts, separated by periods. The first part is the name of your project. For this example it is CppOEMAddIn. The second part is the name of the class that implements the ApplicationAddInServer interface, which is “CppOEMAddInAddInServer” for this example, as shown below.


  2. The next step is to configure some project settings so the manifest is correctly embedded within the dll. The first two settings are part of the Linker settings. The settings and the values to change them to are highlighted in the picture below. Some of these settings may already have the correct value.

    The next setting is of the Manifest Tool settings. Make sure the “Embed Manifest setting is set to “Yes”, as shown below.


    Finally you want to remove the post-build step that registers the add-in in the registry. This is found in the Build Events section of the settings. Clear out any text in the Command Line field, as shown below.


  3. 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 function 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.

    4. Skip to step 4 below, which is the same for all languages.




    ====== The following steps apply to all languages. ======

  4. 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.

  5. 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 Autodesk.AddInName.Inventor.addin Below is the .addin file for an example primary add-in with the portions to change highlighted.

    Please note: When you manually copy the content to a .addin file, make sure there are no leading spaces and blank lines in it.

    <?xml version="1.0" encoding="utf-16"?>
<Addin Type="Standard">
	<ClassId>{2bf59d73-5170-4524-b0e1-391760aaffa5}</ClassId>
	<ClientId>{2bf59d73-5170-4524-b0e1-391760aaffa5}</ClientId>
	<DisplayName>MyOEMApp</DisplayName>
	<Description>Inventor OEM Sample App</Description>
	<Assembly>MyOEMApp\MyOEMApp.dll</Assembly>
	<Hidden>0</Hidden>
</Addin>

    For most add-ins, the ClassId and ClientId elements will be the same value, which is the GUID at the top of the StandardAddInServer class.

    The value of the DisplayName element can be anything and is the name of the add-ins as shown in the Add-In Manager.

    The Description element can also be anything and is the description of the add-in as shown in the Add-In Manager.

    The Assembly element defines the name of the add-in dll. It also defines the path to the dll, relative to the OEM bin directory, but the subdirectory must always have the same name as the add-in dll.

    The Hidden 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.

    There are some other elements that you might see defined for other add-ins that either don’t apply or are ignored for an OEM primary add-in.

  6. See the Creating an Inventor Add-In topic for more information about where the files go.



Was this information helpful?