Strongly-Typed

When you create a report, .NET automatically creates a report class within the current project. Just like all the other classes in a project, the report is instantiated by its class name. Reports that are referenced by their class name are called Strongly-Typed reports. These reports are compiled into the applications executable file.

Untyped

When you save a .NET project, each report in the project is saved as a separate “.rpt” file. Although these files are saved in the same folder in your .NET application, they are independent of the project. In other words, you can copy these .rpt files to another folder and use them in another project. You could also copy them to a reporting library to be shared among many applications. Report files are separate from the current project have to be referenced by their filename and path. Reports that are referenced by their filename, rather than their class name, are called Untyped Reports. When you build your application, these reports will not be part of the application.

Each report type has its own benefits and drawbacks. Untyped reports are useful for applications that let the user choose from a dynamic list of reports. An example of this is when the user browses to a directory location and selects which report to print. You can also use Untyped reports to share reports between different applications. This lets you create a reporting library that is shared on the network. Another benefit is that if you distribute an application and later find that you have to modify a report, you can change the report without rebuilding the application. A drawback of using Untyped reports is that when deploying your application you have to remember to include each report file in the deployment project (unless its stored on the network). If you are writing an ASP.NET application, you also have to make sure that the security settings let you access the report.

Strongly-Typed reports are the easiest to work with in your application. Since the class is already part of your project, it is pretty simple to reference it by name. You also get the benefit of having the report compiled within the application’s executable and you don’t have to distribute the report file. There are two limitations however to using Strongly-Typed reports. First is that you can’t reference reports designed by other applications or by the Crystal Reports stand-alone application. Second is that if you modify a report, you have to recompile and redistribute the application’s executable.

Report types are not mutually exclusive within an application. For example, choosing to open a report as a Strongly-Typed report doesn’t mean you can’t open other reports as Untyped reports. The purpose of classifying reports into types is for determining the best way to write your application. Each report can be opened in the way that is best suited for it.

That’s it! Now that you’ve read about the various options you have for integrating reports into your application. Look at table 3-2 for a summary of each option.

Table 3-2. Summary of report integration options.

The next two sections take each option and show you the exact steps for implementing each one in your application. The first section is specific to Windows applications and the second section is for writing ASP.NET applications.