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:
public void ConfigureServices(IServiceCollection services)
ReportingEngineConfiguration = sp.GetService<IConfiguration>(),
HostAppId = "Html5DemoAppCore",
Storage = new FileStorage(),
ReportResolver = new ReportTypeResolver()
Path.Combine(sp.GetService<IHostingEnvironment>().ContentRootPath, "..", "..", "..", "Report Designer", "Examples")))
static IConfiguration ResolveSpecificReportingConfiguration(IHostingEnvironment environment)
var reportingConfigFileName = System.IO.Path.Combine(environment.ContentRootPath, "reportingAppSettings.json");
return new ConfigurationBuilder()
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.
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Feedback Portal
and vote to affect the priority of the items