Slow load of Crystal WPF dll's

Question

I am trying to use the new WPF interface of Crystal Report using VS 2010. I have a 64bit Win 7 machine with 8gb of memory.
I have reduced a test application to do nothing more than instantiate the ReportDocument object then load a simple report.
the statement
Private _crpt As New CrystalDecisions.CrystalReports.Engine.ReportDocument
takes over 60 seconds to complete in or out of the VS 2010 designer.
The Crystal Report refererences are all versioned to 13.xxx
Subsequent instantiations of _crpt even after .close & .dispose are in the subsecond to 2 second range.
Why does the initial instantiation of the object take so long??
Is this normal?? or can it be speeded up somehow??

Answer 1

I have tried many approaches using the WPF threading model and Crystal with no success. The code snippets I provided is all that you should need to reproduce the problem in a wpf environment. An attempt to repeat it in the lab would be appreciated. A bit of additional info: the error message generated above is not captureable, its coming out as a "system error" associated with a vshost.exe program while loading in the developer mode of vs 2010.
A couple FYI's
Too Ludek, There have been a number of reported problems with slow "report load" times. My problem is not with loading a report - I haven't yet gotten that far in the code. I'm just trying to instantiate and load the .dlls associated with your ReportDocument object. So while i appreciate your good information regarding report creation in general (which I can assure you I will reference since we've had many report authors and I'm sure that many of our reports can be better written), its the load of the object that is problem and it may be just associated with the WPF developemnt environment. I have not used 13. modules in win forms but we do have examples here of 12. Crystal modules in winform apps and the instantiation time is 30 secs or less.
These slow load times (60 sec+)  appear to be a significant problem, based on the forum message counts. If some simple threading code can be created and made to work to run the dll load in the background, I'm sure many of the complaints about slow load times would go away.
On my application. I was not clear. I'm not trying to recreate RAS. What we are trying to do is to basically provide a dll that any of our applications might use to call out to Crystal to run any of our SQL data described 400+ reports. The SQL tables will provide descriptions of the reports, their location and the parameters that are associated with each of them, etc.. The idea being that once described once to the database (via an admin program) any application can request that report by name or id. The application can then look up the report and its attributes and make the call to the CRViewer to do the actual report.
Some people run one application all day - in that case a one minute wait time can be lived with. However, many people be-bop around applications all day, to make them wait an extra minute on each app at startup for example, especially if they don't do reports, is problemmatic.
Thanks for your continuuing attention.