Hi

I am attempting to get trdp files to generate a pdf in a .net core application using ObjectDataSource.

in my appsettings I have the following code to reference my dll.

running the report results in error The assembly "EXTERNAL_ASSEMBLY_TYPE" is not permitted to be used by an ObjectDataSource component. Please include it in an AssemblyReferences element in the Telerik.Reporting configuration section of your application configuration file.

But when I put in a app.config as suggested https://www.telerik.com/forums/reporting-asp-net-core-rest-service-configuration#f0fajfr44E6tvOjTRMr33g, 

everything works fine. 

Should we still need this step? What are the requirements so that the telerikReporting section of the appsettings.json are read? I have made sure all of the dlls are installed as specified here https://docs.telerik.com/reporting/use-reports-in-net-core-apps

Its not a big deal but seems un-nessesary. Any ideas?

Hi Silvia

Activating JSON-based configuration did the trick, my startup method now looks like this and works great,

Thanks Again

Ross

Hi,

I'd just like to point out the fact that WAY too many times, Telerik demos look nothing like the instructions published in the documentation.  In your post above, you recommend the app.settings file. 

Then you say: "Additionally, Telerik Reporting ships with a ready-made ASP.NET Core example that demonstrates how to show the sample reports in an ASP.NET Core application. The example also shows how to inject an appsettings.json configuration file to the controller and how to initialize a WebHostBuilder so it runs under Windows and Linux."

No it doesn't.  Not the one shipped with 14 R1, anyway. 

If you look at the Asp.NetCoreFullDemo project, there are no references to the ConfigurationBuilder or any ConfigurationHelper as suggested here: https://docs.telerik.com/reporting/telerik-reporting-rest-service-aspnetcore-mvc-core2

Instead, somehow the only connection string defined anywhere is in an XML config file called app.config with no indication of how that is referenced. 

That's not how things are done in ASP Core.  It's not how things are done in your documentation.  And it's not what you are recommending here although you do recommend following the demo and then what, modifying it?

Why?

I think things are challenging enough without all the ambiguity.

Will

Hi Will,

Thank you for your feedback. I agree that we haven't updated part of our Documentation to correspond to the demos we provide. For example, the How to implement Telerik Reporting in ASP.NET Core 2.1 MVC KB article. The approach suggested there is valid until version 13.2.19.1020 and we will add this information explicitly. If you find other discrepancies we would appreciate it if you shared them with us so that we can edit the corresponding articles.

The .NET Core framework evolves fast and we try to keep up. For that reason, we introduced dependency injection to the Web API controllers in .NET Core. We have updated the demos and the Documentation article correspondingly:

• How To: Host Reports Service In ASP.NET Core 2.1 and 2.2
• How To: Host Reports Service In ASP.NET Core 3+

Note that the Asp.NetCoreFullDemo project is an obsolete demo as it targets the .NET Framework. For that reason, it is also not included in the solutions with our demos. We still ship the project as a reference for our users that have adopted the approach for hosting Telerik Reporting REST Service in .NET Core projects targeting the .NET Framework. We recommended this approach before introducing the support for pure .NET Core projects in version 13.0.19.116. In this obsolete approach, it was necessary to introduce an XML configuration file to read the settings.

Regards,
Todor
Progress Telerik

Hi Todor,

I just took a look at How To: Host Reports Service In ASP.NET Core 3+.

That's a good start but there are still some flaws.  If you reference my support ticket ID #1452773 you'll see a conversation with Ivan Hristov about this topic. 

As I pointed out to him, the ConfigurationHelper is completely unnecessary because you can simply pass the IConfigurationRoot object that is created by default in the Startup.cs file's constructor.  That is, of course, unless you choose to add separate configuration just for Reporting.  But the doc should make it clear that if you choose to us the standard appsettings.json + appsettings.[EnvironmentName].json configuration files, there is no reason to mess around with the Helper class.  And, yes, that section is labelled "(Optional)" but no mention is made of the alternative or default.  So, if you opt not to "Add Configuration Settings" how do you communicate the connection strings to Reporting??

Also, in the description of the helper class, it would be nice if you referenced the appsettings.[EnvironmentName].json files as well as the appsettings.json file since many of us use them.  It could save confusion (like mine) or at least act as a reminder that if you have different connection strings in different environments, you need to include the Environment specific configuration.

Thanks,

Will

Hi Will,

We have discussed the subject and - as promised in support ticket - we'll refactor the code examples shipped with our product and will edit the documentation articles to match the examples.

Indeed, the "Add Configuration Settings" is optional because it is not required to configure the Reporting engine through a configuration file. There are default settings that will be applied when the configuration is not provided explicitly. For example, if you use an embedded connection string or you don't use a SqlDataSource you may not need this configuration. The 'ReportingEngineConfiguration' is not required to be set by the user. It provides flexibility that will be useful in most cases though. For example, we do not provide an alternative for resolving the value of a named/shared connection string.

We agree that the 'ConfigurationHelper' class can be removed. We introduced it as we considered it as more OOP-approach that segregates the configuration dedicated to the Reporting service from the rest of the configuration entries. In some scenarios a separate configuration file only for the Reporting engine will be useful and 'ConfigurationHelper' class served that purpose. After refactoring the examples code, we decided to extract the code to a separate method and get rid of 'ConfigurationHelper' class. To summarize, the code in the Startup.cs class would look like this:

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

            // Configure dependencies for ReportsController.
            services.TryAddSingleton<IReportServiceConfiguration>(sp =>
                new ReportServiceConfiguration
                {
                    //The default ReportingEngineConfiguration will be initialized from appsettings.json or appsettings.{EnvironmentName}.json:
                    ReportingEngineConfiguration = sp.GetService<IConfiguration>(),

                    //In case the ReportingEngineConfiguration needs to be loaded from a specific configuration file, use the approach below:
                    //ReportingEngineConfiguration = ResolveSpecificReportingConfiguration(sp.GetService<IHostingEnvironment>()),
                    HostAppId = "Html5DemoAppCore",
                    Storage = new FileStorage(),
                    ReportResolver = new ReportTypeResolver()
                        .AddFallbackResolver(new ReportFileResolver(
                            Path.Combine(sp.GetService<IHostingEnvironment>().ContentRootPath, "..", "..", "..", "Report Designer", "Examples")))
                });
        }

        /// <summary>
        /// Loads a reporting configuration from a specific JSON-based configuration file.
        /// </summary>
        /// <param name="environment"></param>
        /// <returns></returns>
        static IConfiguration ResolveSpecificReportingConfiguration(IHostingEnvironment environment)
        {
            // If a specific configuration needs to be passed to the reporting engine, add it through a new IConfiguration instance.
            var reportingConfigFileName = System.IO.Path.Combine(environment.ContentRootPath, "reportingAppSettings.json");
            return new ConfigurationBuilder()
                .AddJsonFile(reportingConfigFileName, true)
                .Build();
        }

With respect to the environment-specific configuration files, we rely entirely on the framework to decide which one will be used. The behavior is coming from the framework and that's why we haven't commented on this in our Documentation. With the default builder, there is no need for including code for resolving environment-specific configuration, the 'appsettings.[EnvironmentName].json' configuration files should be respected. In the case of other builders, you may need to include such logic.

Regards,
Todor
Progress Telerik