4

I am writing a VB.NET add-on for Solidworks, in which I first need to connect to an already running instance of Solidworks (similarly to how such connections are made to Excel). I am using Marshal.GetActiveObject method:

Sub ConnectToSolidworks()  
    Const PROG_ID As String = "SldWorks.Application"  
    Dim progType = System.Type.GetTypeFromProgID(PROG_ID)  
    If progType Is Nothing Then MSG("Cannot detect a valid Solidworks installation.") : End : Application.Exit()  

    'connect to Solidworks  
    Try  
        swApp = TryCast(System.Runtime.InteropServices.Marshal.GetActiveObject(PROG_ID), SolidWorks.Interop.sldworks.ISldWorks)  
    Catch ex As Exception  
        printException(System.Reflection.MethodBase.GetCurrentMethod().Name, ex)  
    End Try  

    'check if connected  
    If swApp Is Nothing Then  
        MSG("Unable to connect to Solidworks.")  
        End  
        Application.Exit()  
    End If  
End Sub

Unfortunately, there is a problem. If Solidworks is launched as an Administrator, and my application is not, or vice versa, Marshal.GetActiveObject fails with HRESULT: 0x800401E3 exception.

However, I need my application to work without administrative access, and regardless of whenever Solidworks was launched as administrator.

The reason why I'm not using Interaction.CreateObject, Interaction.GetObject or System.Activator.CreateInstance, is because these methods will launch Solidworks on their own if it is not running already, which I want to avoid at all costs.

With that in mind, how can I get Marshal.GetActiveObject to work when the elevation levels mismatch, or is there yet some another way to get this done?

EDIT: I tried Interaction.GetObject again, and it also throws an exception if elevation levels mismatch ("Cannot create ActiveX component").

Pᴇʜ
  • 56,719
  • 10
  • 49
  • 73
Justinas Rubinovas
  • 197
  • 14
  • 2
    This is the exact reason why UAC was invented. It fixes the "shatter attack" security vulnerability, stopping a non-privileged process from hijacking the capabilities of a privileged one. Well, not like you can't find out that you need to restart your utility, tell the user about it or use the "runas" verb to do it programmatically. Or make it a plugin so it runs inside Solidworks. – Hans Passant May 08 '19 at 14:12
  • That's the solution I am using right now, but my clients said it is extremely inconvenient, and they want my application to connect to Solidworks regardless of whenever it was launched as administrator or not. Plugin is unfortunately out of a question right now. So what can I do? – Justinas Rubinovas May 08 '19 at 14:14
  • 2
    Security is inconvenient. – Hans Passant May 08 '19 at 14:16
  • I think you may need to reconsider the way you architectured your solution. Why would an add-in that is working from inside one instance of SOLIDWORKS need to get a pointer of another instance of SOLIDWORKS? – Amen Jlili May 11 '19 at 07:31
  • My add-on is not working from inside Solidworks. It's an external executable that needs to connect to an instance of Solidworks. – Justinas Rubinovas May 12 '19 at 10:48

0 Answers0