Installing trial breaks our application

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Installing trial breaks our application

Post by tomharris » Fri 09 Dec 2011 14:25

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

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Mon 12 Dec 2011 07:13

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

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Mon 12 Dec 2011 17:33

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

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Mon 12 Dec 2011 18:13

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

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Tue 13 Dec 2011 16:39

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?

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Wed 14 Dec 2011 18:27

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

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Wed 14 Dec 2011 18:31

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

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Thu 15 Dec 2011 17:35

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

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Thu 15 Dec 2011 18:06

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?

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Fri 16 Dec 2011 11:17

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

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Mon 19 Dec 2011 14:33

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

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Tue 20 Dec 2011 10:51

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

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Wed 21 Dec 2011 11:17

Many thanks, that's great news

Shalex
Site Admin
Posts: 9543
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Thu 22 Dec 2011 17:57

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 .

tomharris
Posts: 18
Joined: Tue 27 Jul 2010 12:22

Post by tomharris » Wed 15 Feb 2012 17:57

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

Post Reply