Creating a Solid Edge addin using Visual Basic is easy, but the following points have to be noted:

SolidEdge requires a class id (commonly referred to as a CLS 16216t1922q ID) which is a unique identifier for a particular addin

VB, while building the ActiveX addin DLL creates a ProgID (the ProgID is a programmatic name for the object/application that can be instantiated via automation; for example, SolidEdge.Application is the ProgID for Solid Edge) which points to a unique CLSID.

The ProgID in the VB ActiveX DLL project is usually the <ProjectName>.<Classname>

For C++ clients, the CLSID is usually specified once and never changes (unless the addin writer decides to change it). However, VB keeps changing the CLSID (pointed to by the ProgID for the DLL) every time there is a compile after a code change in the ActiveX DLL, but does keep the ProgID same. This is a problem, because Solid Edge requires certain Solid Edge specific information to be registered under the CLSID hive in HKEY_CLASSES_ROOT in the Windows system registry. So to run this special registration script, we need to constantly keep updating the CLSID in the script, which becomes a nightmare.

To make VB NOT change the CLSID, make a copy of your ActiveX DLL (once it is nearly complete), and store it away as "compatbl.dll", say. Then, in the addin project's properties, under the "Component" tab, click on "Binary Compatibility" and specify "compatbl.dll". This will ensure that the CLSID for that DLL will NEVER change again. Then, the CLSID in the registry file can be updated with this new CLSID that can be obtained from the ProgID as mentioned above). If however, the addin writer does something that truly breaks compatibility (by removing methods on a class etc.), then they just need to replace "compatbl.dll" with a copy of the current addin dll, which of course might need the addin writer to update the CLSID in the registry script as well, if it has changed.

Finally, after building the DLL, be sure to register the special information that SolidEdge looks for when loading the addins. See the addin.reg file. Use regedit.exe to register this information.

The only changes the addin writer needs to make to this registry script file is to:

Change the CLSID (which they will get from the registry under their ProgID).

Change the environments under "Environment Categories" to those the addin supports

Change the string "409" to the number corresponding to the user's locale. Accordingly change the localized string.

Note also that on the development platform of the designer of the addin DLL, the dll is automatically registered by VB while building the dll, but when the dll is delivered to a client, the setup/installation script must explicitly register the dll during installation by running the following script: "regsvr32 <YourAddinDLLName>.dll", followed by running their version of the above registry script.

Important !!! Please read if you are starting with a copy of the delivered sample

The VB sample as delivered internally uses a unique CLSID for the addin object (as explained above). Every addin writer that starts with our sample gets the SAME CLSID. So if they don't change it, there may be more than one addin registered for Solid Edge that has the same CLSID. This means that every time such an addin gets registered on the system, it might overwrite the registry entries for another such addin and cause it to break. In any case, Microsoft mandates that CLSIDs need to be UNIQUE in the registry for every COM object in the system. So the bottom line is to ensure that you generate a unique CLSID for your own addin. Therefore, follow the steps below to ensure that your addin has a unique CLSID:

First delete the following files: compatbl.dll and seaddin.dll

Change the "Version Compatibility" option (under Project/SEAddin Properties/Component) to "No Compatibility". This will force VB to generate a new CLSID for the addin object.

Change the ProjectName (currently "SEAddin") and Classname (currently "Sample") for the project so that your addin has a UNIQUE ProgID in the registry. Typically, this reflects your company name/product name/functionality. Using your company name/product name etc. will minimize chances of another addin overwriting your registry entries.

Make your other needed changes to the project settings (say output DLL name) and any changes/additions/modifications to the addin code

Build the DLL. At this time VB should have assigned a new GUID for your DLL.

Copy the DLL built above and call it say, compatbl.dll. This will be the DLL that we will force VB to look at for the CLSID of the addin DLL.

Change the "Version Compatibility" option to "Binary Compatibility" and set the compatibility to look for the compatbl.dll created in the previous step. From this point forward, VB will ensure that the new CLSID in compatbl.dll is maintained for your addin, unless you break binary compatibility with compatbl.dll.

Look up the new CLSID for the addin by going to the ProgId for your addin in HKEY_CLASSES_ROOT as explained in the section above.

Update the addin.reg file you copied from our sample and replace every occurrence of our VB addin's CLSID with the CLSID in the previous step (that is newly generated for the addin).

Make sure you save the addin.reg file.

If you changed the names of the addin dll and/or the addin registration file, make sure the regaddin.bat file references the renamed files.

At this point, your addin is guaranteed to be unique among all other Solid Edge addins on the system, when it is registered.