How to Have Fabrication 2019 and Fabrication 2023 Co-Exist in the Same PC?

JC_BL · ‎02-23-2023

I have developed a set of add-ins in CADmep 2019 (Fabrication 2019 API). They work fine. But CADmep 2019 is getting old. We are thinking of switching to CADmep 2023. During the transition period, we need to have both CADmep 2019 and 2023 to co-exist for quite a long while.

I have fixed the incompatible data types in the source code to have it compiled correctly in both CADmep 2019 and 2023 (using Conditional Compiling Symbols). But my program always fails in CADmep 2023 as soon as it needs to use any object/function related to Fabrication API, such as Job.Items, Database.CustomItemData, Job.GetFabricationItemFromACADHandle(). The program still works fine in CADmep 2019.

This has nothing to do with AutoCAD API, they work fine. The problem has to do with Fabrication API -- specifically related to the version of Fabrication API.

I have traced the problem to the possibility that both versions of my program "seem" to use Fabrication 2019 API regardless it is running in CADmep 2019 or 2023. This explains why the program works fine in CADmep 2019, but not in 2023. This is odd because I have purposefully built a version of my program for each CADmep -- one for CADmep 2019 and another one for 2023. And I know for a fact that I am using the 2023 version of my program (because I have added a special command called "JayTest2023" in the 2023 version of my program that is not available in the 2019 version of my program).

I can work around this problem by renaming the Fabrication 2019 folder from this:

C:\Program Files\Autodesk\Fabrication 2019

Into something like this:

C:\Program Files\Autodesk\Temp_Disabled_Fabrication 2019

After I have renamed that folder, seems like this "forces" CADmep 2023 not to use Fabrication 2019 API. And all the suddenly, everything works.

Obviously this is not a good solution because this prevents someone from using CADmep 2019 and 2023 in the same computer.

Please let me know if you have any suggestion that I can try.

By the way, my add-ins are deployed through PackageContents.xml in C:\ProgramData\Autodesk\ApplicationPlugins\MyCadLib.bundle folder. Not sure if this matters or not.

If you need some sample source code to look at, please let me know and I will prepare it.

JC_BL

JC_BL · ‎02-24-2023

I dig into this issue a bit using Resource Monitor to see which version of FabricationAPI.dll is being loaded, and I find that the 2019 version of FabricationAPI.dll is loaded whenever CADmep 2023 is loaded. That is even before my add-in is loaded. And also 2019 version of FabricationCore.dll is also loaded.

The IExtensionApplication.Initialize() of my 2023 add-in tries to load the correct version of FabricationAPI.dll. But seem like the fact that 2019 FabricationAPI.dll has already been loaded prevents the 2023 version of FabricationAPI.dll from being loaded. There is no error message. The LoadFrom() function shown below simply returns the info about the 2019 FabricationAPI.dll in the Assembly object:

void IExtensionApplication.Initialize()
   {
   try
      {
      String sFullPathFabApiDllFileForCAD = "C:\\Program Files\\Autodesk\\Fabrication 2023\\CADmep\\FabricationAPI.dll";
      Assembly oAsm = System.Reflection.Assembly.LoadFrom( sFullPathFabApiDllFileForCAD );
      if ( oAsm == null )
         {
         MessageBox.Show( "Fail to load FabricationAPI.dll",
                          "MyAddin", MessageBoxButtons.OK, MessageBoxIcon.Exclamation );
         }
      }
   catch( System.Exception ex )
      {
      Document doc = Autodesk.AutoCAD.ApplicationServices.Application.DocumentManager.MdiActiveDocument;
      Editor   ed  = doc.Editor;
      ed.WriteMessage( "\n" + ex.Message );
      return;
      }
   finally
      {
      }
   }

But the add-in is built for 2023 Fabrication API. This "may" have caused the add-in to fail whenever it needs to talk to Fabrication API.

So, the question is "Why CADmep 2023 pre-loads the 2019 FabricationAPI.dll?". Any idea?

Thanks in advance.

JC_BL

JC_BL · ‎02-28-2023

This problem is fixed.

The cause of the problem has to do with the PackageContents.xml of a _different_ add-in in my computer contains an "inappropriate" version number. It was like this in that PackageContents.xml file:

<RuntimeRequirements ... SeriesMin="R19" />

R19 is for AutoCAD version 2013 to 2014. My computer doesn't have that version of AutoCAD.

That add-in also needs to use Fabrication API. I had been focusing on the add-in that I am working on, and I didn't realize that the problem was coming from a different add-in.

With that wrong version number in PackageContents.xml in that add-in, when I launched CADmep, seem like CADmep chose to launch the oldest version of FabricationAPI.dll in my computer and that happens to be version 2019. This explains the reason why the 2019 version of FabricationAPI.dll has been pre-loaded when I launch CADmep 2023. And that somehow prevents my program from loading 2023 version of FabricationAPI.dll. This explains the reason why I had a problem loading 2023 version of FabricationAPI.dll in CADmep 2023.

As for the reason why I cannot get CADmep 2021 to load "any" version of FabricationAPI.dll, I still don't know. Nevertheless, the problem in CADmep 2021 is also fixed.

The fix is to enter the correct version of AutoCAD in PackageContents.xml in that add-in, like this:

<RuntimeRequirements ... SeriesMin="R23" SeriesMax="R23"/>

R23 is the version number for AutoCAD 2019.

Now, I find that CADmep can pre-load the correct version of FabricationAPI.dll or CADmep can allow my add-in to load the correct version of FabricationAPI.dll. And the add-in works properly in multiple versions of CADmep.

Hope this helps someone.

JC_BL

JC_BL · ‎02-28-2023

If someone knows why fixing the version number in PackageContents.xml in the other add-in can fix the problem in CADmep 2021, please let me know. Thanks.

JC_BL