Class not registered - CrystalPrintControl - havent seen an answer

[Former Member]

Hello,

I'm still working on my issue from this thread

I want to thank Ludek for starting me on the right track.

I've since updated the project to a .NET 4.0 project using Visual Studio 2010. I've installed the SP1 for VS2010 and installed Crystal Reports 2010 for VS 2010 as well as the Service Pack for that. I'm not running Crystal Version 13.0.1.220

I've rewritten the print code to use RAS, that is the PrintOutputController.PrintReport method.

The change prints on my development machine - although I have not yet gotten to test whether it actually prints to the default tray of the printer setup, which was my original problem.

The issue now - moving to the client's server, is that I receive the Class not registered error mentioned in the following threads.

There does not seem to be a resolution other than this solution provided by a user crystaladvice:

http://www.crystaladvice.com/crystalreports/fix-class-not-registered-crystalprintcontrol

Unfortunatly I am receiving an error with regards to the attempt to regsvr32 the printcontrol.dll.

It seems this is a problem happening to more than one person - so I imagine it's an issue related to installing the Crystal runtimes for a 64 bit machine on Windows 2008 Server. I know Ludek mentioned he would test it in this thread

Ludek mentioned he was going to check the MSI on a clean install. From what I can see it looks like whatever you install for Crystal Reports for your development machine works fine, but the MSI runtime install has an issue with a 64 bit 2008 server.

In the thread mentioned above Ludek had not yet posted the results, just wondering if this is an outstanding issue.

The current project we are working on is in a standstill - in the meantime I'll explore issues with not being able to regsvr32 the printcontroll.dll.

Thanks for any help.

[Former Member · Accepted solution]

Just a thought - the solution at http://www.crystaladvice.com/crystalreports/fix-class-not-registered-crystalprintcontrol

from his filepath location - it looks like he is providing the 32 bit runtime files. I'm wondering if that is the reason I can not regsrv32 the dll on the 64 bit windows 2008 server.

If that is a problem, does anyone have the 64 bit dll?

[Former Member · Accepted solution]

Also - just wanted to give the full error I'm getting:

System.Runtime.InteropServices.COMException (0x80040154): Class not registered - CrystalPrintControl at CrystalDecisions.ReportAppServer.Controllers.PrintOutputControllerClass.PrintReport

[Former Member · Accepted solution]

Just comparing the server to my dev machine.

I changed the GAC so I could view them in windows by editing the registry, adding a dword value of DisableCacheViewer with a value of 1 to HKLM/Softare/Microsoft/Fusion

Found for example that CyrstalDecisions.ReportAppServer.Clientdoc folder had a 13.0.2000.folder on my dev machine, but nothing on the server machine.

I'm thinking it has to be something in the 64 bit redestributable runtime MSI file. Which is what I think was the problem in the previous threads as well.

[former_member11696 · Accepted solution]

Hi K,

Most of those posts are for 32 bit deployments so they don't count... Including regsvr32.exe, there are 2 versions, one in

C:\Windows\SysWOW64 for 32 bit COM dll's and and another one in C:\Windows\System32 for 64 bit dll's, I think.... Confusing why MS did not rename their various 64 bit versions to *64.exe...

Also, please clarify, you said: "I'm not running Crystal Version 13.0.1.220" why not? You are using the SP 1 patch to build your app but using the 99 build ( SP 0 ) to deploy? make sure both are the same version.

We have found a few missing dependencies in the both the 32 and 64 bit MSI's and SP 2 should have the ones that have been reported.

A few issues here, Run Process Monitor on your DEV PC. But first, set your project to x64 Release Mode. And rebuild it...

Then from Explorer go to the \bin\Release folder and double click your EXE. It is now running in pure 64 bit mode, as you know the .NET IDE is 32 bit ONLY, running in 64 bit debug mode in .NET is confusing, you'll see both 32 and 64 bit runtime loading.

Do you get the same error? If yes then the Printer Driver you are using, does it support or does it have a 64 Driver available? And have you installed it and done a test app, no CR components, to verify it does actually support 64 bit applications?

Process Monitor will verify all parts being used....

So if the above works then it likely is either the dependencies for printing in 64 bit are not installed on the deployment PC or CR 64 MSI is missing something which Process Monitor can verify....

Don

[Former Member · Accepted solution]

Thanks for the reply - just wanted to clear a few things up.

I am running 13.0.1.220, that was a typo.

Also this is a web application - so I don't have the ability to run an exe or build it with a release mode. I'm using the publish option in Visual Studio 2010.

I'm currently working on installing the 32 bit runtimes on the Windows 2008 server, and setting the application's pool as 32 bit to see if that works.

[Former Member · Accepted solution]

Well no luck with installing the 32 bit runtime on the server and changing the application's pool to 32 bit.

Printtoprinter method does work - but it ignores the default print tray set on the printer through the server, which is why I went to this method.

With the 32 bit runtime though - it appears the dll's are registered - at least when I go through the windows/assembly folder.

[Former Member · Accepted solution]

It looks like the guy in this thread ran into the same problem, this time running his web application on a windows 7 64 bit machine

[Former Member · Accepted solution]

Ok - I think I was able to get printcontrol.dll registered using CrystalAdvice method here

http://www.crystaladvice.com/crystalreports/fix-class-not-registered-crystalprintcontrol

As Don mentioned - windows 2008 64 bit may have a different way to register dll's

so I had to go into windows\syswow64 to register the 32 bit dll used by CrystalAdvice

so I started cmd as administrator, went to windows\syswow64, then ran this command

regsvr32 "C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\Crystal Reports 2011\crystalreportviewers\ActiveXControls\PrintControl.dll"

with his download of the activexcontrols folder in that location of course.

it registered the printcontrol.dll successfully - and now when I print I just get the printer not found - which is my fault, I'll get the printer on the server and test it properly and I think it should work.

[former_member11696 · Accepted solution]

Hi K,

Something else is going with permissions on that PC if the installer could not register that print control dll....

Process Monitor may help or fiddler to debug the WEB app also.

Don

[Former Member · Accepted solution]

I'm pretty sure it was not related to the rights as I was logged in as administrator on both windows 2008 machines I tested on, neither one of them registered the printcontrol.dll

Ludek had mentioned he was going to test the runtime distribution on a clean machine in one of the threads listed above - I'm anxious to see the results (it was from March however) - but from what i've seen there have been multiple users with the issue in a variety of setups, and the solution I mentioned above provided by CrstyalAdvice seems to fix the issue.

Where I did run into a problem with his solution - was attempting to register the dll using the wrong regsvr which you pointed out above, after that I was able to register it fine, and I did successfully print.

I'm going to fix up the clients server today and see if the tray issue is fixed, and that the default tray of the printer on the server is used when printing a crystalreport.

[Former Member · Accepted solution]

Well I was able to get the client server to print - so registering the dll by hand did work. Crystal printing however is still printing to only 1 tray despite whatever presets are set on the servers printer. This marks a departure from my experience with Crystal Reports for Visual Studio 2003.

I suspect it also may have to do with a few other things. Client machines are all 32 bit and the server is a 64 bit server, perhaps there is something not functioning within that connection and the printer drivers. I don't know - I'm going to also start going through some of the solutions mentioned in other threads here, I believe Don had some code to try out to pull printer tray settings out so that you could use those in printing.