cancel
Showing results for 
Search instead for 
Did you mean: 

CRVS2010 Beta - file not found error crdb_adoplus.dll

Former Member
0 Kudos

I am getting an error when running the product. I have installed CR 2010 beta.

{"Could not load file or assembly 'file:///C:
Program Files
SAP BusinessObjects
SAP BusinessObjects Enterprise XI 4.0
win32_x86
dotnet1
crdb_adoplus.dll' or one of its dependencies. The system cannot find the file specified.":"file:///C:
Program Files
SAP BusinessObjects
SAP BusinessObjects Enterprise XI 4.0
win32_x86
dotnet1
crdb_adoplus.dll"}

the whole dotnet1 folder is missing in my installation.

Is there a workaround?

thanks

Accepted Solutions (1)

Accepted Solutions (1)

timbaguley
Discoverer
0 Kudos

I get the same error when attempting to load a report.

former_member183750
Active Contributor
0 Kudos

Can you check if the file is in the Program Files\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86 directory?

Ludek

timbaguley
Discoverer
0 Kudos

Yes. The crdb_adoplus.dll file is in that directory. However, if you look at the file path specifed in the error message, it's attempting to access the file in C:\Program Files\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet1\. The files are not in "dotnet1" folder, they're in win32_x86.

Edited by: tb_unlv on Apr 21, 2010 1:17 AM

Edited by: tb_unlv on Apr 21, 2010 1:18 AM

Edited by: tb_unlv on Apr 21, 2010 1:19 AM

Answers (1)

Answers (1)

Former Member
0 Kudos

Yes, on my PC there is no dotnet1 folder. The dll is however existing in the win32_x86.

It is looking at the wrong location.

Former Member
0 Kudos

I got the same error.

and when attempted create this folder, other problem appear to me.. "mixed mode error".

former_member183750
Active Contributor
0 Kudos

As a work-around, see if copying the dll into your app directory will help. Also, I wonder if the path in the registry needs to be modified, but I'll let Mandeep or Coy answer that one.

Ludek

Former Member
0 Kudos

Hello! What has happened is that the 4.0 Framework has changed how it loads mixed-mode files compiled with a previous version of the Framework. If you do an online search for the error message

u201CAdditional information: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.u201D

, you will find a few articles on this issue. This seems to be the same issue as the error about the missing crdb_adoplus.dll.

Try adding the following section to your config file and it should resolve the issue.


<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>

former_member208657
Active Contributor
0 Kudos

Good find Mandeep. I found that adding useLegacyV2RuntimeActivationPolicy fixed the issue for me.

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>

Former Member
0 Kudos

this solved my problem as well.

thanks

0 Kudos

Hi Mandeep,

Is this something we can change in our install/configuration or should we create a Kbase article for this configuration when using Mixed modes?

Need to know the next step to handle this error?

Thank you

Don

timbaguley
Discoverer
0 Kudos

Yes, setting the useLegacyV2RuntimeActivationPolicy flag to True does "solve" the problem. However, that is a hack and not a true fix. In trying to create a purely .NET 4.0 application, the end user shouldn't have to add this flag to get an application to work. Hopefully someone at SAP will note this and fix it in the core Crystal Reports funtionality before the final version for VS 2010 is released.

Cleaned up your post.... Please See [Rules of Engagement|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] for more info.

Thank you

Don

Edited by: Don Williams on Apr 22, 2010 9:48 PM

Former Member
0 Kudos

Hi,

Is SAP fixed this issue.

It seems like crystal reports assemblies are compiled in runtime version 2.0, and whenever we run the code in VS2010 then we have to explicitly specify the useLegacyV2RuntimeActivationPolicy attribute.

Please let me know if is there any other way to resolve this issue.

Regards,

Jay

0 Kudos

Hi Jay,

Is this still regarding the crdb_adoplus.dll problem or is this something new?

It should all be fixed by the time we go GA.

I'm also curious if you manually create the folder:

C:\Program Files\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet1

and copy the dll into that lcoation from the x86 folder does the error go away?

Thank you

Don

Former Member
0 Kudos

Hi Jay! This issue seems to be specific to the crdb_adoplus.dll. The issue is with how the 4.0 .NET Framework changed it's loading behavoiur. Unfortunately, the attribute will be required to view reports based on ADO.NET objects.

Former Member
0 Kudos

Hi,

Adding startup element and setting "useLegacyV2RuntimeActivationPolicy" to true and setting "supportedRuntimeVersion" to 4.0, did fix the issue for me. It works even though the required file "crdb_adoplus.dll" is not copied in dotnet1 folder.

<startup useLegacyV2RuntimeActivationPolicy="true">

<supportedRuntime version="v4.0"/>

</startup>.

Qs. for SAP guys:

Can you please confirm that above mentioned solution of changing the config file is a temporary solution and the actual issue would be fixed by SAP when "Crystal Reports for VS 2010 Beta" is released in November,10 in RTM version.

Thanks,

Gulab.

0 Kudos

If you read the thread and searched on "Mixed mode assembly is built against version 'v2.0.50727'" you would see this reason why.

I doubt it will be fixed for legacy reasons and it's not a CR issue.

Thank you

Don

Former Member
0 Kudos

So what you're saying, basically, is that you think that your code will run just fine under .NET 4.0, but you're not sure enough to migrate to it. Instead you're hoping that the users of the assemblies should trust your assemblies compatibility and work around any potential problem that would arise?

Because using .Net 2.0 activation policy would just make your assemblies run under CLR 4.0 in an application targeting the .Net 4.0 framework.

Former Member
0 Kudos

That's quite not the issue. In order to support .NET 2.0 Framework scenarios, the runtime components are compiled for .NET 2.0 framework support. The .NET 3.5 and 4.0 Frameworks scenarios are tested and show full compatibility. This issue occurs because of how the .NET Framework 4.0 changed it's loading behavoiur for mixed-mode components; this issue does not exist with the .NET 3.5 Framework.