2 Replies Latest reply on Jun 23, 2014 11:22 AM by Ron Bates

    .net assembly registration problems on some machines

    Ron Bates

      I'm using proper regasm...as far as I know...e.g.

       

      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe C:\path\to\my\assemblyaddin.dll /codebase

       

      On one win7 x64 machine, no problems registering.

       

      On another, I get error RA0000: Unable to locate input assembly 'assemblyaddin.dll' or one of it's dependencies.

       

      I assume it's simply a dependency...but I'm struggling to find out what it is exactly.  This is a super simple plug-in, one function and just the typical assembly references set up in VS.  (Microsoft.CSharp, SolidWorks.Interop.sldworks, SolidWorks.Interop.swconst, SolidWorks.Interop.swpublished, SolidWorksTools, System, System.Data, System.Drawing, System.Windows.Forms and System.XML)

       

      I tried using .NET Reflector to view dependencies on a system where it fails, but I'm not sure it's telling me anything at all about what's actually missing...

       

      Can anyone shed any light on how to best troubleshoot regasm issues with .net assemblies???

       

       

      -Ron

        • Re: .net assembly registration problems on some machines
          Artem Taturevych

          Are the following dll located in the add-in folder when you register? SolidWorks.Interop.sldworks, SolidWorks.Interop.swconst, SolidWorks.Interop.swpublished, SolidWorksTools

          ______________________________________________

          Regards, Artem Taturevych | Snr. Developer | IC3D ANZ

           

          IC3DSteel – New Steel Solution for SolidWorks

          LinkedIn - SolidWorks API Group

          • Re: .net assembly registration problems on some machines
            Ron Bates

            I found an article that talked about a similar issue when trying to run regasm on dll's in a network location.  The solution was to provide the full UNC path to the dll, and not a mapped drive.  While this was NOT my scenario, it suggested some permission issues and using a full path.  I was running the .bat file to register my DLL from the same location/directory.  So I wasn't specifying a full path.

             

            e.b. my .bat file looked something like this (obviouly variables defined above this bit) and the .bat file iteself lived in the same directory as the DLL.

             

            "%Windir%\Microsoft.NET\Framework64\%FMWK%\regasm" MyDotNetDLL.dll /codebase

             

            This worked on 3 out of 4 machines.  Given the note on UNC paths and mapped drives and permissions...I suspected the same difference in security settings, from machine to machine...  So changing to use the full path to the dll works OK.

             

            "%Windir%\Microsoft.NET\Framework64\%FMWK%\regasm" "C:\path\to\MyDotNetDLL.dll" /codebase