4 Replies Latest reply on Jun 21, 2017 9:44 AM by Alexandre Gragnano

    Addin versions conflict

    Alexandre Gragnano

      I developed two SW C# DLL addin versions

       

      - I noticed that 2 addins cannot have the same Title:

      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\AddIns\{GUID_2016}\Title = "{Product}"
      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\AddIns\{GUID_2017}\Title = "{Product}"
      

      One of them will not be visible in SW Addin panel

       

      - I noticed that DLL must have a different filename:

      C:\Programs\[Product]\2016\Addin.dll
      C:\Programs\[Product]\2017\Addin.dll
      

      Cannot be loaded together in same SW session

       

      - So I changed the filenames but now I have a conflict whith namespace:

      Addin2016.dll => [Company].[Product].A
      Addin2017.dll => [Company].[Product].B
      

      Depending on the loading order of the addins, SW tries to get A class into Addin2017.dll and B class into Addin2016.dll

       

      If anybody know the rules to avoid conflicts between versions, it will be very useful!

          • Re: Addins conflict
            Alexandre Gragnano

            Thank you Ivana, I already use different GUID's for COM visible classes (ISwAddin, ISwComFeature...)

            The problem seems happens with internal calls. I did not set any GUID for my internal classes. Do I have to do it?

            Any addin loaded single works nice but when they are loaded together, they become  unstable.

            • Re: Addins conflict
              Alexandre Gragnano

              I think I found my mistake. My addin dll's are registered as:

               

              HKEY_CLASSES_ROOT
                  CLSID
                      {_GUID_2017_}
                          (Default) => Company.Product.Addin
                      {_GUID_2016_}
                          (Default) => Company.Product.Addin
                  Company.Product.Addin
                      CLSID
                          (Default) => {_GUID_2017_}
              
              

               

              They have a different GUID but a same ProgId.

              - The "{_GUID_2016_}" resolution gives "Company.Product.Addin" ProgId

              - The "{_GUID_2017_}" resolution gives "Company.Product.Addin" ProgId

              - But the "Company.Product.Addin" resolution gives the last registered GUID (ex: "{_GUID_2017_}")

               

              So, I suppose when SW tries to call a method from "Company.Product.Addin",

              it tries to call the method in the last registered DLL (ex: Addin2017.dll).

               

              If I look at: Key (COM) (ProgId definition)

              A programmatic identifier (ProgID) is a registry entry that can be associated with a CLSID. Like the CLSID, the ProgID identifies a class but with less precision because it is not guaranteed to be globally unique.

              So I understand that SW does not take into account the fact there can be several CLSID for one ProgId.

              Am I wrong?

               

              I am not aware about techniques to manage different addin versions.

              I would like to keep the Addin2016.dll & Addin2017.dll for a certain time.

              • Re: Addins conflict
                Alexandre Gragnano

                During debugging, I finally found the statement which causes the problem:

                 

                var sheets = new List<Body2>();
                var sheet = surface.CreateTrimmedSheet4(...);
                sheets.Add(sheet); // Throws System.ArgumentException
                

                 

                Because I forgot to cast sheet into a Body2 type. It was in Dynamic type. So I now have:

                 

                var sheet = (Body2)surface.CreateTrimmedSheet4(...);
                sheets.Add(sheet);
                

                 

                I cannot say why this exception was thrown only when the two addins was activated together

                and not thrown when addins was activated single... I suspect an internal Reflection process

                to resolve an object type by ProgId. It working fine now, thank you.