Active Reports 15 DLLs

Posted by: mdynna on 5 May 2021, 5:03 am EST

  • Posted 5 May 2021, 5:03 am EST

    We recently upgraded to Active Reports 15. After the process was completed, a total of 30 DLL references were added to our Reports assembly. Are all of these required to be distributed with our application? If not, how do we determine which are needed based on the features that we use for our application?

    For example, ours is a Windows Forms application and we only use Section reports.

  • Posted 6 May 2021, 5:09 am EST

    Hello,

    All these dll are needed for the different feature. However, you can try with following dll at your end:

    GrapeCity.ActiveReports

    GrapeCity.ActiveReports.Chart

    GrapeCity.ActiveReports.Design.Win

    GrapeCity.ActiveReports.Core.Drawing.Gdi

    GrapeCity.ActiveReports.Core.Export.Pdf.Page

    GrapeCity.ActiveReports.Core.Rdl

    GrapeCity.ActiveReports.Core.Rendering

    GrapeCity.ActiveReports.Documents

    GrapeCity.ActiveReports.Export.Pdf

    GrapeCity.Documents.Common

    GrapeCity.Documents.Imaging

    GrapeCity.Documents.pdf

    Thanks,

    Mohit

  • Posted 3 June 2021, 2:03 am EST

    Thanks I was able to work this out with some experimentation.

    I have another question about DLLs in the development environment. When processing the update to Active Reports 15 the tool installed all the new DLLs via NuGet and put them in a “packages” folder under the solution. All the DLLs seem to be duplicates of those installed in C:\Program Files (x86)\GrapeCity\ActiveReports 15\Tools when the update was installed. We have several different products in different solutions that all use the same shared assembly for reports. Are the ones retrieved from NuGet different, or could they be different in the future?

    Is there a reason I can’t (or shouldn’t) move these DLLs to a shared location and then have all the assemblies reference them? I like to have all of the referenced DLLs checked into Source Control so the version is controlled between developers.

  • Posted 3 June 2021, 4:38 am EST

    Hello,

    Are the ones retrieved from NuGet different, or could they be different in the future

    Dlls which is present in ‘Tools’ folder are needed to run the tools in the same folder. Installed will be updated whenever AR packages updated on the NuGet server. So you need to install the AR with updated installer to get the dll of same version in Tools folder.

    Due to .Net Core support, we move dlls to NuGet server instead of GAC. You can put the dll in the shared folder to use in different application. However, you need to update the dll in folder manually with every new release of AR.

    Hope it clarifies.

    Thanks,

    Mohit

  • Posted 4 June 2021, 9:28 am EST

    Yes thanks. I worked it out by choosing one of our applications (Solutions) as the “host” and then all the other applications point to that. In the future I just need to remember to update the “host” application when new DLLs are released.

    I ran into one new problem today. When we go to export a report to XLSX format we get this exception:

    System.IO.FileLoadException: Could not load file or assembly ‘DocumentFormat.OpenXml, Version=2.12.1.0 …’

    We are including DocumentFormat.OpenXml.dll as part of our application, but it is version 2.13.0 as that is the latest from NuGet. GrapeCity.ActiveReports.Export.Excel is 15.1.3.0, and it is a Section report that we are running.

    Is there a way to correct the Excel Export so that it is referencing 2.13.0, or alternatively roll back DocumentFormat.OpenXml back to 2.12.1.0?

  • Posted 8 June 2021, 7:43 am EST

    Wondering if there is any insight on the DocumentFormat.OpenXml.dll version error?

  • Posted 9 June 2021, 5:14 am EST

    Hello,

    Request to please confirm that are you using DocumentFormat.OpenXml.dll in your project?

    Thanks,

    Mohit

  • Posted 9 June 2021, 8:11 am EST - Updated 30 September 2022, 7:40 am EST

    So I did a bunch of checking. There was a weird Visual Studio thing were some products had a old version hanging around and it wouldn’t replace the DLL until I manually deleted it from the output folder.

    In addition to the Reference I made sure that some of our code actually uses a class from the DLL as VS doesn’t always copy the DLL to the output folder unless you actually use it. After all that, I’m still getting the error both in the development environment and on our deployment test machines.

    I have verified that the output folder contains DocumentFormat.OpenXml.dll v2.13.0.0

  • Posted 9 June 2021, 8:12 am EST

    Oh and here’s the full text of the exception being thrown:

    Tax and Assessment 2.1.10.0

    Unexpected Error - Export Report from Viewer in Tax and Assessment 2.1.10.0

    An unexpected error has occurred. Please retry the operation or contact MuniSoft Support for assistance.

    System.TypeInitializationException

    The type initializer for ‘GrapeCity.ActiveReports.Export.Excel.Internal.’ threw an exception.

    This error occurred at GrapeCity.ActiveReports.Export.Excel.Internal.…ctor()

    at GrapeCity.SpreadBuilder.Workbook.get_ExportHandler()

    at GrapeCity.SpreadBuilder.Workbook.Save(String filePath)

    at GrapeCity.ActiveReports.Export.Excel.Section.XlsExport.Export(SectionDocument document, String filePath, String pageRange)

    at GrapeCity.ActiveReports.Export.Excel.Section.XlsExport.Export(SectionDocument document, String filePath)

    at Reports.ReportViewer.Export_Button_Click(Object sender, EventArgs e) in C:\Version 2.1.10\Development\Reports\CM_Reports\Forms\ReportViewer.vb:line 364


    System.IO.FileLoadException: Could not load file or assembly ‘DocumentFormat.OpenXml, Version=2.12.1.0, Culture=neutral, PublicKeyToken=8fb06cb64d019a17’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

    File name: ‘DocumentFormat.OpenXml, Version=2.12.1.0, Culture=neutral, PublicKeyToken=8fb06cb64d019a17’

    at GrapeCity.ActiveReports.Export.Excel.Internal.…cctor()

    WRN: Assembly binding logging is turned OFF.

    To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

    Note: There is some performance penalty associated with assembly bind failure logging.

    To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

  • Posted 11 June 2021, 5:28 am EST

    Hello,

    If you are not using the “DocumentFormat.OpenXml.dll” especially in your application then, please use the dll of version 2.12.1 instead of 2.13.0 in your folder to avoid this issue as it needed to export the report into excel file.

    Thanks,

    Mohit

  • Posted 11 June 2021, 9:57 am EST

    Ok that worked. Thanks.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels