Crystal Reports/.Net question

  • Thread starter Thread starter MJ
  • Start date Start date
M

MJ

Does anyone know if an app written in vb.net utilizing
Crystal reports engine
(CrystalDecisions.CrystalReports.Engine)will cause any
sort of conflict with other applications that utilize CR
8.5? We have had problems in the past with dll conflicts
with different versions of CR.
 
The .NET one uses .NET assemblies... so by definition of .NET assemblies...
no.

We had the same problems with Crystal 8.5/9 ActiveX controls... .NET took
care of that...

deployment is a pain though...just fair warning.
 
CJ Taylor said:
The .NET one uses .NET assemblies... so by definition of .NET assemblies...
no.
Click to expand...


This is not 100% true, you can STILL have version conflicts, even under .NET
(which is so lame). I spoke with Crystal tech support, and this is still a
common problem.

IMHO, in terms of software design, crystal is the bigest piece of crap ever
made. As far as reports go, Crystal does some really great things, but you
better have the extra hair to pull out when it drives you crazy.
 
BTW: the version issues I mensioned are not caused from v8.0, they are from
having multiple .NET versions.
 
Jeremy Cowles said:
This is not 100% true, you can STILL have version conflicts, even under ..NET
(which is so lame). I spoke with Crystal tech support, and this is still a
common problem.
Click to expand...

Kinda confused on how this is possible. I can understand various version
conflicts, but if packaged right you wouldn't get them (unless depending on
the GAC, even then...)

But if Crystal says so, then... well they would know =)
IMHO, in terms of software design, crystal is the bigest piece of crap ever
made. As far as reports go, Crystal does some really great things, but you
better have the extra hair to pull out when it drives you crazy.
Click to expand...

I wholeheartadly agree. I love Crystal, but it is a headache a lot of the
times especially trying to deploy and getting certain things to work on it.
Incredibly versitle solution but I think its time they rewrite the whole
thing (v10 was just released, apparently with added features of a whole new
color scheme!) to get rid of some of the kinks. BO definatly has market
dominance over other reporting packages so they could wait a year between
this and their next release to redevelop it.

However, Crystal's web reporting sucks...

=)
 
In addition to what everyone else said:

Crystal at its core, while there are DotNet components, is still COM. A tech
support guy told me that they kept it this way because they "invested so much
time" in that technology that they would not just "throw it away". The result:
DotNet Crystal still wallows in DLL hell, particularly from its use of System32
libraries (comcat.dll, atl.dll, etc).

Our standard procedure for deploying any Crystal applications is to run
cr9netredist.msi, which can be found at the Crystal website
http://www.businessobjects.com. This takes care of all the non-DotNet stuff so
that any application with Crystal can be deployed without an installer.
cr9netredist also makes potential problems easier to spot such as core Crystal
DLL registration failures. Fixing these can be involved but fairly
straightforward if you use ocxdllreg.reg and Dependency Walker (depends.exe).

Bob
 
Back
Top