Configuration error on production server

Question

0.00/5 (No votes)

See more:

I have a test server and a production server.

On both servers I have a test folder.

When I deploy new aspx pages to the test folder on the test server, I can display and run the report. I use a link from the menu page to open the page.

When I copy the SAME pages from the test server to the production server and copy the SAME link from the test server's menu page to the production server's menu page, I get this error:

Configuration Error 
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. 

Parser Error Message: Could not load file or assembly 'Microsoft.ReportViewer.WebForms, Version=11.0.0.0, Culture=neutral, ; or one of its dependencies. The system cannot find the file specified.

Source Error: 

An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Everything is the SAME on both of these servers. The DLLs are the same on both servers. All the pre-existing pages on the production server load and run without any issues or errors.

This just started this week. I haven't made any changes to the production server.

I searched for some possible solutions but haven't found anything to resolve this issue. I verified the ReportViewer dll is using version 11.0.0 and not version 10. My web.config files are the SAME on both servers.

Any ideas what is causing this error?

What I have tried:

I verified the ReportViewer dll is using version 11.0.0 and not version 10.

I verified the time/date stamps on my DLLs and config files on both servers - they are the same.

Posted 14-Sep-16 12:08pm

Member 10379103

Add a Solution

Comments

ZurdoDev 14-Sep-16 19:20pm

Put the ReportViewer dll in the bin folder of the site.

Member 10379103 15-Sep-16 8:47am

The ReportViewer dll is already in the bin folder of the site. There are several other pages that use this same viewer. If the ReportViewer.dll wasn't in the bin, the other pages would not load. Plus, the page on the test server would also display an error and not load.

ZurdoDev 15-Sep-16 17:07pm

Then you are using a different version or something. Something is clearly different and none of us have access so I'm not sure what you want from us.

Member 10379103 15-Sep-16 17:39pm

Having checked everything that is usually suggested and finding everything the same, I was reaching out in case anyone else had experienced the same issue and to see how they resolved it. I also wanted to be sure that I was not missing something that was basic. That is what I wanted from the group.

jgakenhe 14-Sep-16 22:05pm

Yes, you're missing something. You're missing the ReportViewer dll or the Report Viewer isn't installed on the PROD server. Stack has a good list of items to check: http://stackoverflow.com/questions/16493817/could-not-load-file-or-assembly-microsoft-reportviewer-webforms

Member 10379103 15-Sep-16 8:47am

The ReportViewer dll is already in the bin folder of the site and Report Viewer is installed on both servers. There are several other pages that use this same viewer. If the ReportViewer.dll wasn't in the bin, the other pages would not load. Plus, the page on the test server would also display an error and not load.

Member 10379103 15-Sep-16 8:51am

Thanks for the link, too. I verified everything that was there. Both servers are the same, the DLLs in the bin are the same, the web.configs are the same and reference the assemblies. If they didn't, I would see an error on the test server, too. A head-scratcher...

jgakenhe 15-Sep-16 9:12am

I had a similar problem about 4 years ago, that's why I replied. These can be a complete pain sometimes. I would also look to see if the dll is the same date and version on both test and prod. And I'd look to see if the test server and the prod server have the dll in the same place in the system 32 directory (I think). Something is missing somewhere.

Member 10379103 15-Sep-16 9:16am

It IS a pain! Both servers have the same date and version. IF the prod server had the dll in a different system 32 directory, wouldn't the other pages display the same error and not load?

Member 10379103 16-Sep-16 11:44am

jgakenhe - is it possible for a reference on my production server's test folder to be corrupt? As I stated before - all the time/date stamps for the DLLs and web.confit are the same on both servers. I push changes to the test server and put them in the test folder and the pages load. I put the same pages in the test folder on the prod server and get the error.

I copied the .aspx page on prod and put it in a DIFFERENT folder on prod and there was no error - so it seems like even though the DLLs and web.config files have the same dates and times, something is corrupt with the actual test folder on production. Is this even possible? I have never seen this happen before...

jgakenhe 16-Sep-16 12:08pm

I don't think the test folder is corrupt. I think your problem resides from something being different on the test server and the prod server. If IIS is the same and the frameworks are the same, I'd uninstall and the reinstall the Microsoft Report Viewer 2012 and go from there. You might have to do a restart, but something is missing related to the Report Viewer that is not on production.

Member 10379103 16-Sep-16 12:32pm

Thanks for your suggestions. I'm hesitant to uninstall and reinstall the ReportViewer on the prod server because all of the other pages are working. If I ever figure this out, I will post the solution in case anyone else ever faces this same issue.

Member 10379103 16-Sep-16 12:44pm

Ok I just checked the Assemblies folder on the server and I saw Reportviewer versions 8, 9, and 10. No version 11. All the pages currently on that server reference ReportViewer version 11 and the web.config file only references version 11. The DLL in the BIN folder references version 11 from the GAC_MSIL\Microsoft.ReportViewer.Webforms that was created when the solution was built.

So, could the test folder on production be looking for version 11 of the report viewer on the production server instead of the DLL in the bin while the test folder on the test server is referencing the DLL?

jgakenhe 16-Sep-16 13:07pm

Yes. It sounds like you are on the right track!

Member 10379103 16-Sep-16 13:55pm

Ugh. How did that even happen????? Or, perhaps it is good that it did happen in case the pages ever "decide" to ignore the ReportViewer assembly version referenced in the DLL in the BIN and tries to find it on the server...my challenge is explaining this to the higher ups. One last question - in you experience, could installing version 11 of the reportviewer on the server potentially make the other pages start displaying errors? Since this isn't happening on the test server (which, by the way, is just a different port on the same physical server), I really don't have a true test environment and would be installing this on the live port.

jgakenhe 16-Sep-16 14:22pm

I don't think it would not affect .aspx pages, but it is too risky for production unless you have a low time of day to do it and have a backout plan.

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)