locked
How to get past default settings 'macros disabled' when installing an Excel Automation project RRS feed

  • Question



  • My VB.net programme creates a workbook with 14 worksheets and four code modules which are filled with VBA macros by reading from text files.
    It compiles and runs on the development machine (Windows 7) and installs and runs perfectly on an XP machine. When it was loaded on another Windows 7
    machine it failed. After putting “& ex.message” on all my Try Catch blocks we got the message “Programmatic Access to Visual Basic project not trusted”.
    So it seems an exception was thrown at the point of adding the first module or immediately thereafter when writing the text file to the module which thereby
    becomes VBA code. After checking the box “Trust VBA project model” my user was able to it install and it runs OK. I understood that it was not necessary for this to be checked on the target machine. Presumably he could have checked one of the other options. Since macros are disabled by default how best can I programmatically get past this block with a user option to say NO and quit.

    AVENMARG


    Thursday, February 9, 2012 7:01 AM

Answers

  • Hi Avenmarg

    <<After checking the box “Trust VBA project model” my user was able to it install and it runs OK. I understood that it was not necessary for this to be checked on the target machine. >>

    On what information do you base this statement?

    As soon as you want to do anything with the macro interface of an Excel workbook, this option must be activated.

    If you're referring to information in the VSTO documentation, a typical VSTO customization does not include VBA code in its make-up and rarely would a VSTO customization manipulate the VBA interface. This option is a security setting to prevent "bad software" from adding potentially dangerous macros to "innocent" Office documents. It is different from the settings that allow macros to load and run.

    A possible alternative would be to build these workbooks using Open XML. Then you could also add the VBA module as a "part" to the whole. When the workbook is opened later in Excel, the macros would then fall in the macro disable/enable category.


    Cindy Meister, VSTO/Word MVP

    • Marked as answer by avenmarg Thursday, February 9, 2012 11:58 PM
    Thursday, February 9, 2012 9:50 AM

All replies

  • Hi Avenmarg

    <<After checking the box “Trust VBA project model” my user was able to it install and it runs OK. I understood that it was not necessary for this to be checked on the target machine. >>

    On what information do you base this statement?

    As soon as you want to do anything with the macro interface of an Excel workbook, this option must be activated.

    If you're referring to information in the VSTO documentation, a typical VSTO customization does not include VBA code in its make-up and rarely would a VSTO customization manipulate the VBA interface. This option is a security setting to prevent "bad software" from adding potentially dangerous macros to "innocent" Office documents. It is different from the settings that allow macros to load and run.

    A possible alternative would be to build these workbooks using Open XML. Then you could also add the VBA module as a "part" to the whole. When the workbook is opened later in Excel, the macros would then fall in the macro disable/enable category.


    Cindy Meister, VSTO/Word MVP

    • Marked as answer by avenmarg Thursday, February 9, 2012 11:58 PM
    Thursday, February 9, 2012 9:50 AM
  • For Cindy Meister

    Your answer clarifies things for me. I am only a latecomer to VB though I am very familar with VBA.

    I think my best option is to put a notice up front that enabling macros is required so user can fix before running the program.

    Thank you for the help.

    AVENMARG 

    Thursday, February 9, 2012 11:58 PM
  • Hi Avenmarg

    I think telling the users to "enable macros" is the wrong information. Enabling macros usually means, letting macros that are in a project run.

    But the problem with your proposed approach is enabling programmatic access to the VBE interface. That's an entirely different proposition and you need to be clear and up-front about it, because it is a massive security risk.


    Cindy Meister, VSTO/Word MVP

    Friday, February 10, 2012 6:49 AM