Vba Excel Trust access to the VBA project model

Question

I need to execute the following lines of code for my client, the problem is that in order to access them I must have activated a certain option within the project, is there any way to avoid that?

Application.VBE.ActiveVBProject.References.AddFromFile "C:\Windows\System32\mshtml.tlb"
Application.VBE.ActiveVBProject.References.AddFromFile "C:\Windows\System32\msxml6.dll"

They are a couple of libraries necessary for the execution of my Macro.

The macro that I am running is as follows:

Sub GetCurrentDate()
    Dim S$

    With CreateObject("MSXML2.XMLHTTP")
        .Open "GET", "http://www.fechadehoy.com/venezuela", False
        .send
        S = .responseText
    End With

    With CreateObject("htmlfile")
        .body.innerHTML = S
        MsgBox .getElementById("fecha").innerText
    End With
End Sub

libraries needed for the execution of my macro

Microsoft XML, v6.0
Microsoft HTML Object Library

It is correct, thanks for your response, the problem is that to add those links you must have activated the option shown in the image. — Eduardo Gonzalez, Aug 20 '19 at 16:23
Side note, please don't do `Dim S$`, think of future maintainers and spell it out: `Dim S As String`. Also consider using an actual meaningful identifier name, e.g. `contents`, or `response`, whatever. — Mathieu Guindon, Aug 20 '19 at 17:20

Mathieu Guindon · Answer 1 · 2019-08-20T16:34:18.137

in order to access them I must have activated a certain option within the project, is there any way to avoid that?

The option isn't within the project, it's at the host application level (Excel): whether programmatic access to the VBIDE API is trusted or not is an important part of macro security settings, and no, there isn't any way around it.

Any programmatic way to circumvent this security setting would make a huge gaping security hole every macro-virus in the world would jump into.

But you don't need to do this. Your code is creating instances of classes located in these libraries using CreateObject, not the New operator: the references are not needed.

With CreateObject("MSXML2.XMLHTTP") ' returns an Object/XMLHTTP reference
    .Open ...  'late-bound member call (no intellisense, no compile-time validation)
    '...
End With

CreateObject uses the specified ProgID string to find the registration in the Windows Registry, locate the type library, create an instance of the type, and return a reference to that object - everything is resolved at run-time (hence "late" bound), and as long as the ProgID exists in the registry and there's no typo in the late-bound code (Option Explicit can't save you from those), everything "just works".

If you used the New keyword instead...

With New MSXML2.XMLHTTP ' returns an XMLHTTP reference
    .Open ... 'early-bound member call (with intelilsense and compile-time validation)
    '...
End With

This couldn't be compiled without a project reference to the MSXML2 library.

Vba Excel Trust access to the VBA project model

1 Answers1