Could not load file or assembly 'file:///C:\Program Files (x86)\SAP ... win\dotnet1\crdb_adoplus.dll'

[Former Member]

I have seen a few solutions for this problem, (i.e. ) but I suspect they are for Windows Forms Applications. I'm writing User control libraries, and none of the solutions, which usually use modifications to the app.config file to fix it, work for me.

I hopefully uninstalled everything from SAP this morning and reinstalled CRforVS_13_0_5.exe. I'm still getting the error.

The 'dotnet1' folder does not exist on my system.

I'm using VB.NET (VS 2012 with Update 4,) SQL 2014 Developer for a back end, and operating in the Windows 7 pro (x64) environment. I've set all of my apps and referenced libraries I wrote to target the 64 bit platform, and to target .Net 4.5. When that didn't work I tried .Net 4.0.

All of my apps and reports were originally written in VB 2005 (.Net 2.0) and are converted when I first open the solutions in VB 2012.

I tried creating the missing folder (dotnet1), and copied the file referenced there only to get another message saying I was using a mixed mode application. Apparently something in my assembly was using .NET 2.0. I could not find it.

I have been chasing this problem all week but nothing I do works.

I would like to target 4.5, because we are moving everything into the cloud and the other app we use, Microsoft Dynamics NAV, I think uses that framework. But I am not that particular. I  have options in that regard. However, I do want it to be a 64 bit solution.

Any help or suggestions will be appreciated.

[Former Member · Accepted solution]

New information.

We have 2 types of reports in our system. Embedded, and standalone. The embedded reports are the ones I have a problem with. These reports are included as part of the project.

All of the reports that are standalone are running ok. These reports are called by passing the filename to the CRViewer and opening using the zoom method.

I still have not figured out why the embedded reports don't run when they have a connection to a database or to a dataset.

Marshall

---Edit

Also, I don't know if I mentioned it but I'm trying to do everything in 64 bit mode.th e original VB2005 projects were 32 bit. Most of the post about this problem are for 32 bit apps.

I'm also not convinced the problem is with the data connections, since the problem disappeared when I called a standalone report. Even when data connections are used. The only difference is that the standalone reports have never been put through the conversion process. I'm not sure the embedded reports get converted, because every time I open one and save it, I get a warning saying the report w  ill be saved in the 'new' format.

I've been developing in VB using CR since 1996. I'm not new to this and I am really disappointed that I'm having so much trouble with the installation and with finding answers from the one place I thought I'd get a good, quick answer.

I am hard-headed and am fighting returning to a 32 bit model, but I may try that. It involves recompiling a dozen other DLL's but by the end of today, I just may. Please help me resolve this! Should I submit a support ticket? I need to do something and a week and a half without any production is unacceptable.

Message was edited by: Marshall Youngblood

app.config for Forms.zip

[former_member183750 · Accepted solution]

Managed or unmanaged report should really not make any difference - I almost think this is a red herring...

I would proceed as follows:

1) Save out one of the embedded reports

2) Create a new simple test app. Pseudo-code:

Add a CR viewer to a form

Load report (e.g.; do not embed)

Pass the dataset to the report

set the report to the viewer

Code would be close to this:

'create dataset

Dim crReportDocument As New CrystalDecisions.CrystalReports.Engine.ReportDocument

crReportDocument.Load("C:\WindowsApplication5\test.rpt")

crReportDocument.SetDataSource(dataSet)

CrystalReportViewer1.ReportSource = crReportDocument

What happens when you do the above?

If that works, you can now change the code to:

'create dataset

crReportDocument = New test

crReportDocument.SetDataSource(dataSet)

CrystalReportViewer1.ReportSource = crReportDocument

The behavior should be identical in those apps.

- Ludek

[former_member11696 · Accepted solution]

Hi Marshall,

The absolute ONLY reason you will ever get this error: Could not load file or assembly 'file:///C:\Program Files (x86)\SAP ... win\dotnet1\crdb_adoplus.dll...

Is because the ADO.NET driver requires legacy mode to work so it must have this in the start up section of your app.config file:

<startup useLegacyV2RuntimeActivationPolicy="true">

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

</startup>

Framework is adjustable.

If you do that then possibly there is another dependency you are missing. Process Monitor may tell you what that may be... Look for Access Denied errors also, could be a registry issue....

I am curious if creating new test app like Ludek suggested works... Start from the basics and then start adding your dependencies....

Also, can you confirm this is what you see in Programs and Features, I am using a current build of SP 15, what you should see is 13.0.14.1720 for the versions:

Both Ludek and I have support Crystal for the same time as you. He's 19 years and I'm 18 years here...

Don

[former_member183750]

I'll key in on this:

All of my apps and reports were originally written in VB 2005 

Don't know if the below will apply as the info is not here to tell so it's all on a suspicion:

Make sure that CR 10.2 (bundled with VS 2005) is uninstalled on the dev computer. CR 10.2 and CRVS (13.x) do not work well on the same dev box. Typically, no matter what, the version 10.2 assemblies will keep on insinuating themselves into your project causing all kinds of issues. So, if cr 10.2 is there, uninstall it. Check that all the CR references in your project are 13.0.2000.x. Recompile. Now try that project on the runtime box.

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Follow me on Twitter

[former_member11696]

Please search, this has been answered 100's of time.

Add this to your app.config file:

<startup useLegacyV2RuntimeActivationPolicy="true">

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>

</startup>

And upgrade to SP 14, we only support the latest 3 patches.

Delete the folder you created, not needed.

Don

[Former Member]

Your assumption that I haven't searched for an answer first is incorrect.

I've found a lot of posts about this, but I haven't found a 100 different answers. 99% of what I found said to do what you said. One suggested I change the connection provider but the alterntive always prompts the user for a  username and password.  I searched 3 days for an answer that worked, but I am still unable to get it to work.

I even created new report with just 1 data table, and it failed as well. Same error.

This system was not my design, but I've inherited it and have been working with it for 6 years now. The projects are 99% DLL's consisting of complex user controls. (BTW, the app.config files do not get included in production, so I don't think modifying them is the answer I need.) All were written with VB2005 for the framework 2.0.

I'm trying to convert all the projects to VB 2012 (using VS 2012 pro) and changing the framework to 4.5 and target to x64 architecture. Since I've had so much trouble I switched to the 4.0 framework. But it made no difference.

Most of the answers have to with finding a file in the win32_x86 folder, where I'm having an issue with the win64_x64 folder, if that makes any difference.

I don't want to  but I am considering changing the 32 bit architecture.

If you know of an answer I would appreciated it. Maybe I'm doing something wrong. I assumed you were talking about the app.config file that resides in the source code folder? (Note that it doesn't get copied to the debug or release folder when I run the project from the IDE. I've triedmanually  copying it - no luck)

I'll keep searching, but I was hoping for a better  answer than the same one I've found over and over.

[Former Member]

Don,

I started thinking about one of the solutions I saw that said to change my ADO provider.

So I tried both the SQL Server Native Client 11.0 and the MS OLE DB Provider for SQL Server.

Neither worked.

I also looked for every service pack for .Net I could find. They didn't help either.

However, I created a test report that had only a bit or text - no data connections. That one ran.

I also had a Windows Forms Application project that I use to test the DLL we use to load reports. That one would run with the data connection. But not without some major additions to the app.config file, mostly assemblyBinding directives. Since my browser locks up every time I try to paste anything to your site, I put it in a file and attached it. The bit of code you suggested I ad was already there, though it produces so informational messages stating a lack of schema information for 'sku', 'version', and 'supportedRuntime'.

Apparently the connections are causing the issue in the DLL. Any idea why? I'll try these other changes from the attachment in my DLL app.config, but I still feel this is a waste of time since that file never gets deployed to production.

I plan on researching the connection issue some more when I get back to lunch, but any help would be unbelievably appreciated!

Thanks,

Marshall

Message was edited by: Marshall Youngblood

app.config for Forms.zip

[former_member11696]

Hi Marshall,

Ah, you found the cause:

"If you know of an answer I would appreciated it. Maybe I'm doing something wrong. I assumed you were talking about the app.config file that resides in the source code folder? (Note that it doesn't get copied to the debug or release folder when I run the project from the IDE. I've tried manually  copying it - no luck)"

For some odd reason the app is not using it. Use ProcessMonitor to see if it's getting loaded, if not put it in a place it can and MAKE SURE the legacy section in startup is in there.

And your test confirms if you don't use a data source it works...

Don