25 Replies Latest reply on Mar 1, 2018 4:37 PM by Jim Sculley

    EPDM add-in installation problem

    Tim Webb



      A client is attempting to install one of my class library EPDM add-ins and receives the error "archive server could not open windows registry" while adding the addin. This is usually resolved by setting the .Net framework in the dev environment from 4.0 to 2.0. Not this time. Not even close.


      • Development machine Win7 x64 VB.Net 2010 EPDM 2013 SP5 .Net framework 4 Client profile
      • Target server Windows server 2008 R2 EPDM 2013 SP5 .Net 4.5.1 framework


      These are the troubleshooting steps taken to date:

      1. No success: Changed .Net framework in VB from 4.0 to 2.0, 3.0, 3.5 without resolution but did notice something weird while at 3.5, the addin would load but would not run.
      2. No success: Make COM assembly visible, set the interop for copy local true, embed interop types false...etc. build for any cpu
      3. No success: Generated my own interop targeting .Net 2.0 using tlbimp recommended here
      4. No success: Removed all unused references from the solution
      5. No success: Copied out all code from the solution and created a new solution & built
      6. Success: Created a stand alone apploader that makes calls into the DLL add-in without loading the addin in the admin tool



      1. The addin loads from the stand alone app when all the public functions are called so instantiating a new object of my class library is working on the system.
      2. Loaded the same addin on 2 other client servers, one in the UK running 2013 SP5 and one in Portland running 2013 SP5 with success loading and running.
      3. While on a webinar with them recently I noticed their .Net framework is sitting on 4.5.1 on their servers and client machines...which has me VERY curious.


      On the servers mentioned in #2, these are both running the .Net 4 framework client profile and so far this seems to be the tricky point. Every EPDM server running .Net 4 accepts the add-in and will run it in its current state.


      The head scratcher: when first installing this addin back in November, the addin in an earlier generation would load and loading that version of the add-in still loads today. The code I've added since the November generation is an array, calls to read an XML file and a CSV file. The rest of the code is basically just EPDM interface stuff.


      As a result, spent a few hours on webinar with a seasoned consulting programmer to discuss interops and settings in the program that could cause the error whose recommendation was to build the stand alone apploader to ensure the server could indeed instantiate the class library and it does. His claim is that the DLL is sound if we are able to do that and it is more than likely a .Net issue.


      Looking for areas to investigate.


      Tim CEPA


        • Re: EPDM add-in installation problem
          Dan Miel

          This may not help because you have been able to get add-ins to load but I had problems because i was using Visual Studio 21010 Ver00.

          I had to update to Ver 01 before I was able to load add-ins in EPDM 2013 SR03.


          Dan Miel

          • Re: EPDM add-in installation problem
            Tim Webb

            Received a response from apisupport today on SR:1-5200028166:


            Hello Tim,

            The first thing that comes to my mind here is the client machine’s .Net FrameWork is 4.5.1 (CLR 4.5.1)but your Addin is targeting to 2.0 i.e. CLR 2 (after you changed it from 4.0). So, what I will suggest here is enable/install the .Net FrameWork of the client machine to 2.0 or 3.0 or 3.5 i.e. CLR 2. This will ensure that both application and the client machine or on same .Net FrameWork version.

            Let me know if you see any issues here.

            Also, you can distribute your Add-in by exporting the *.CEX file from the development machine i.e. Vault > Add-ins > “Test Addin” > RMB > Export > Save. The clients just need to import this *.cex file.

            On a side note, the SolidWorks Enterprise PDM API does not currently support .NET Framework 4.0 add-in applications.


            We have an article about this in the EPDM API help documentation –


            ...we should be .Net FrameWork 4.0 compatible back in EPDM 2013, ...there are still few unresolved issues...

            We have the following issues still open at our end-


            1. API methods using ref arrays (SAFEARRAY structs) fails with 'the parameter is incorrect' exception (access is denied) when using .Net 4.0 framework


            2. Error loading addin targeted for .NET framework 4.0: 'The Archive Server could not open the Windows Registry'


            3.Cannot debug addins on x64 bit machines if using Visual Studio (VB .Net) 2010 - 'The Archive Server could not open the Windows Registry'


            emphasis in itallics mine

            • Re: EPDM add-in installation problem
              Pete Yodis



                   Not sure if this helps... but I also had problems loading an add-in from a developer and received the same message.  What I found was that the files could not be on a network directory when attempting to add them in - they had to be local on the machine I was adding them in from.  I think it had to do with security settings in Windows 7.

              • Re: EPDM add-in installation problem
                James Guilford

                Not Sure where my problem fits here.


                I was able to upload the .dll files with no problem until one day it stopped working.


                I have pretty much followed all the solutions in the forum and knowledge base and I still get the same error.


                I have contacted API support for assistance. I'll post something once the issue is resolved.

                • Re: EPDM add-in installation problem
                  Jim Sculley

                  SW and EPDM 2015 SP 1.1


                  I have run into this problem on a few occasions and it has struck once again.  I have a C# add-in that I am developing.  It was working correctly and I have been making minor changes here and there.  All of a sudden, I started getting the 'archive server could not open windows registry' when I tried to use the 'Debug Addins' or 'New Addin' commands in the EPDM Admin tool.


                  This time I was determined to located the cause of the problem.  I began commenting out code until the add-in would load.  I commented out *everything* except the declarations for GetAddinInfo and OnCmd and still could not load the add-in.  Bizarre.  My add-in project includes a Windows form.  When I excluded the form from the project in Visual Studio, the add-in would load.  So I started concentrating on the form.  I created a brand new form with nothing in it.  The add-in would load.  I copied all the controls form my original form to the new form.  The add-in would load.  So nothing in the form design was causing the problem.  I started looking more closely at the code added to the form for event handlers and such.  After commenting all that out, the problem remained.  Finally, I commented out a second constructor I had added to the form.  Eureka!  The add-in loaded properly.  But why?  The constructor looked like this:


                  public ExportRevisionsDialog(List<IEdmFile10> exportCandidates, IWin32Window parentWindow) : this()


                       this.exportCandidates = exportCandidates;

                       this.parentWindow = parentWindow;



                  So, I commented out just the constructor body, but the add-in would not load.


                  I commented out the constructor arguments.  The add-in loaded.  So one of the arguments is the culprit.  I commented them out one at a time.  It turns out that the first argument is the source of my problem.  Any reference to IEdmFile10 (or IEdmFile9 for that matter) will prevent the add-in from loading properly.  If I use IEdmFile8, all is well.


                  Interestingly, IEdmFile10 isn't even listed in the EPDM API docs, but Visual Studio shows it first in the auto-complete, which is how it ended up in my code.  Of course, IEdmFile9 is in the API docs, so it isn't simply a problem of using undocumented objects.


                  I created a brand new add-in to see if the problem is repeatable.  It is.  In fact, you don't even need a form or even a separate file to cause the error to appear.


                  Here is the code for the shortest, complete add-in example I could come up with that exhibits the bad behavior:

                  using System; 
                  using EdmLib;
                  using System.Runtime.InteropServices; 

                  namespace AddinBug {    
                       [Guid("c8cbce7a-ff73-4d1b-ba1c-b3c1993edc48"), ComVisible(true)]    
                       public class SWEPDMAddin : IEdmAddIn5    
                            void EdmLib.IEdmAddIn5.GetAddInInfo(ref EdmAddInInfo poInfo, IEdmVault5 poVault, IEdmCmdMgr5 poCmdMgr)        
                               poInfo.mbsAddInName = "Addin Bug";        

                            void EdmLib.IEdmAddIn5.OnCmd(ref EdmCmd poCmd, ref System.Array ppoData) {}    

                       public class Bug    
                            public Bug(IEdmFile9 file) { } //FAIL        
                            //public Bug(IEdmFile8 file) { } //OK        
                            //Bug(IEdmFile9 file) { } //OK    

                  Please try it out and confirm that it fails.


                  Any public constructor that references IEdmFile9 or IEdmFile10 will prevent the add-in from installing.  A non-public constructor doesn't fail and a public constructor using IEdmFile8 doesn't fail.  I would not be surprised at all if there were other EPDM classes that cause the problem since many of the classes have gone through multiple versions over the years.


                  I have also come to the conclusion that the Windows Registry message is a bit of a red herring since the real problem has nothing to do with the registry.  The Debug Addins command in the admin tool will add an entry to the registry only when the add-in is loaded successfully.  The procmon.exe registry monitor shows no activity for addin loading that fails.  The problem occurs and the error bubbles up to an error handler that is catching a more general exception and spits out the registry message.


                  I'm currently running the admin tool via the Visual Studio debugger to see if I can determine exactly what the admin tool is doing at the point of failure.


                  Jim S.

                  • Re: EPDM add-in installation problem
                    Wayne Matus

                    I know this is an old post, but have more info to share and none of the solutions work for me. I have a simple .NET Framework 4.0 add-in written in VB.Net 2015 for PDM 2016. All it does is add a right mouse menu item, poCmdMgr.AddCmd(1, "Test V1") and menu item pops up simple message box poCmd.mpoVault.MsgBox(poCmd.mlParentWnd, "V1 of ADD-In"). I then made a copy of it and changed V1 to V2. I can add V1 just fine, but V2 does not when I install it on a computer. In this case, I can install V2 on the development computer. But the other day, it was the opposite. I could not install V2 from the development computer, but could from the other computer.


                    It does not make any sense at all what is going on!