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
"MJ" <an*******@discussions.microsoft.com> wrote in message
news:75****************************@phx.gbl...
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.
