Search code examples
c#com-interopblueprism

Referencing Office Interop Objects in BluePrism


Outside the out-of-the-box MS VBOs available with BluePrism. Has anyone successfully managed to import/reference (COM) Office Interop objects (Word, Excel, Outlook, etc...) for use in BluePrism code stages? Please, tell how?

I note there was a similar question but it was not successfully answered: DLLImportAttribute C# - Outlook.


Solution

  • Please have a look at my answer to the question you are referencing, that should give you and idea on how to do that using VB.NET.

    If you insist on doing it with C#, you need to ensure that you add a namespace and reference to the object's Code Options (my path just points to somewhere in GAC, you should copy the DLL somewhere else):

    enter image description here

    Then you can use the objects from the DLL within code stages:

    Application app = new Application(){
        Visible = true
    };
    
    Workbook wb = app.Workbooks.Add();
    Worksheet ws = (Worksheet)wb.Worksheets.Add();
    ws.Visible = XlSheetVisibility.xlSheetVisible;
    

    As you can see, you can also use the named enums, but just like in C# (and unlike in VBA) you need to specify it fully (XlSheetVisibility.xlSheetVisible instead of just xlSheetVisible)

    EDIT: The benefit of VB.NET is that you can use the CreateObject() method to interact with the Excel Interop DLL without explicitly specifying the path to that DLL. This is useful if you do not have the option to store the DLL to a location common to all Resource PCs. If you can, however, then the C# approach will cause you much less headache.

    And as for being able to refer to Excel objects with the Excel "prefix" (for example: Excel.Workbook instead of just Workbook) you need to specify an alias for your Excel namespace. That you can do like this:

    enter image description here

    Afterwards your code will work:

    var excelApp = new Excel.Application();
    excelApp.Visible = true;
    Excel.Workbooks books = excelApp.Workbooks;
    

    This is actually not a bad approach as some of the Excel classes may have the same name as other .NET classes. I believe I had to do this as well because of Table or Document or something...