Devart Forums

Hi there,

we develop 3rd party Oracle tools in .NET and use dotConnect in all our tools. dotConnect is correctly licensed at build time, and all the tools work fine.

However, a customer has now reported that none of our tools are working on his machine. After considerable time spent investigating, we discovered that he had also installed a trial of dotConnect. Installing the trial broke all of our tools as the dotConnect .NET dlls that we use are now being loaded from a different location on his machine.

This is not good!

Can you provide an update on how this problem is being addressed?

Kind regards, Tom

If your customer installed a trial version of dotConnect for Oracle, please ask him to remove all policy.*.Devart.* files from his GAC.

Hi,

Thanks for your speedy response. That said, this is unacceptable for us. You are basically saying that is fine for your trial to stop any products working that are correctly licensing your software. This completely goes against the spirit of .NET programming and it's goal of eliminating dll hell. Why don't you explain why you need to introduce policy files to override the default assembly loading process? We have not had these problems with any other 3rd party components that we use and licence. For example, I understand that we both use 3rd party controls from Dev Express. Would you be happy if someone installing a Dev Express trial stopped your Oracle IDE from working? I don't think you would.

I look forward to hearing back from you.

Kind regards, Tom

In addition, we asked the customer to follow your instructions. IT DID NOT WORK. We spent an hour on a remote session and the devart dll's are still being loaded from the GAC and not from our install directory.

Please advise?

-Tom

tomharris wrote:Why don't you explain why you need to introduce policy files to override the default assembly loading process? We have not had these problems with any other 3rd party components that we use and licence.

Just put the attribute for the Devart.* assemblies to your application's *.config file: http://msdn.microsoft.com/en-us/library/cf9025zt.aspx.

Shalex wrote:remove all policy.*.Devart.* files from his GAC

tomharris wrote:IT DID NOT WORK ... the devart dll's are still being loaded from the GAC and not from our install directory

1. Please specify the exact (x.xx.xxx) versions of dotConnect for Oracle which are:
- used by your application (licensed)
- installed on your customer's workstation (trial)
2. Which versions of the Devart.* assemblies are referenced in your program?

Hi,

thanks for your swift response. We use

Devart.Data.Oracle.dll 6.50.244.0 and Devart.Data.dll 5.0.343.0. The customer has a trial with exactly the same version numbers. On his machine the dll's get loaded from the GAC and your licensing checks cause a failure. I will look into ignoring the policy via our config file

Regards, Tom

Hi, I have just checked and we already have the policy in place that you suggest. here is a snippet.








Do you have any other suggestions?

-Tom

Hi, here is the error text from your licensing

Assembly that contains embedded dotConnect for Oracle license cannot be used with this application: SchemaCompareforOracle. Please correct license information.

-Tom

tomharris wrote:The customer has a trial with exactly the same version numbers. On his machine the dll's get loaded from the GAC and your licensing checks cause a failure.

CLR looks for Devart.Data.Oracle.dll (v 6.50.244) in GAC first (designed behaviour of CLR) and finds the trial version and fails: http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx. As a solution, install another version of dotConnect for Oracle Trial on this workstation (the latest version is 6.60.258).

tomharris wrote:Assembly that contains embedded dotConnect for Oracle license cannot be used with this application: SchemaCompareforOracle. Please correct license information.

Please give us the following information:
1. Where exactly are you getting this error?
2. Which Devart products (and their versions x.xx.xxx) are installed on your workstation?
3. Which steps should we follow to reproduce the issue in our environment?

Hi,

thanks for the response. I agree that loading the dll from the GAC is indeed the correct CLR behaviour. The questions remains, why does your licensing check fail in this case?? The dll in the GAC is identical to the one that we build our product against. It seems to me that you have a design fault with the way your licesning is implemented. Our product should work correclty regardless of where the dll's are loaded from. This is how all other 3rd party .NET components work. You need to find out why yours is different.

Kind regards, Tom

We will investigate this behaviour and post here about the results.

We have fixed the issue: licensed (with non-trial version) application can use trial assemblies starting from the next build of dotConnect for Oracle.

Many thanks, that's great news

New build of dotConnect for Oracle 6.60.268 is available for download now!
It can be downloaded from http://www.devart.com/dotconnect/oracle/download.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=22977 .

Hi there,

I'm sorry to say that we have run into this problem again. Our tool is built against a licensed copy of devart 6.70. At runtime the devart dll's are loaded from the local installtion path of our product, and all works fine.

Then, somone installs devart dotConnect on the machine (I have tried this with both the trial and Pro versions). This breaks our tool as the devart dll's are loaded from the gac and we get the error message 'Assembly that contains embedded dotConnect for Oracle license cannot be used with this application.

In both cases the version numbers of the dlls are the same Devart.Data.Oracle.dll 6.70.302.0

We need this to be fixed

Kind regards, Tom