Posted 20 July 2020, 4:20 am EST
I wanted to add our experience so far.
First, Section Reports in .Net Core are not ready for prime time. They are still apparently working on porting these to run properly in a .Net Core environment; you will have to use .Net Framework 4.8 to support them.
We tried in vain (with support’s help) to get the .gclicx thing working; never did.
We finally found that we simply had to include a license.licx file in any project that dealt with or consumed a report. But what is included in the file is a matter of trial and error.
We had multiple issues upgrading existing reports, with broken NuGet packages and the like, until the team handed us release 14.1.20250. That seemed to fix a lot of headaches.
We had multiple issues upgrading NuGet packages from their stock installed versions… until we found that the release we were attempting to upgrade to had broken dependencies. They since seemed to have fixed that and we can now upgrade packages to the newer releases.
We have repeatedly asked for release notes for the NuGet packages so we know what was fixed, etc.; to my knowledge and in communication with support, AR has no intention of releasing this information. I was advised that the flurry of NuGet package updates are for “customer specific” issues. I find this very much a shame - most if not all our other third party vendors provide release notes for each version of packages. How are we to know if we could benefit from someone else’s fix?
We found that AR adds a ton of NuGet packages to support things - as a result we have on my team gone the route of doing the following. Keep in mind that ALL of our reports are Section Reports, and therefore we’re a bit of a special case here, but this has worked and we have things in production.
For our .Net Framework projects:
- Ensure they are at .Net 4.8
- Create a separate class library project for reporting, .Net 4.8.
- Place all of our reports in that project, and create functions which can be called and return memory streams.
- Reference the class library in our primary project and simply call the functions when needed.
For our .Net Core projects:
- Create an entirely separate .Net 4.8 Web API project.
- Put all our reports in the project and call using combinations of JWT (access) and passsing data using shared DTO/model classes. It returns a byte array.
- No references required - because we can’t (section reports). Also, keeps the incredible number of NuGet references from clobbering our web references.
Was this a lot of work? Yes. A ton, and I feel like (afterwards) it was a mistake to jump on the 14.x bandwagon from 13, but I figured by 14.1 surely things must be stable. We were too far down the road to go back. That, and this is the very first release I can remember where we couldn’t have AR versions live side by side.
Good luck to all,
–J
