Installing trial breaks our application
Installing trial breaks our application
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
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
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
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
Just put the attribute for the Devart.* assemblies to your application's *.config file: http://msdn.microsoft.com/en-us/library/cf9025zt.aspx.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.
Shalex wrote:remove all policy.*.Devart.* files from his GAC
1. Please specify the exact (x.xx.xxx) versions of dotConnect for Oracle which are:tomharris wrote:IT DID NOT WORK ... the devart dll's are still being loaded from the GAC and not from our install directory
- 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
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
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: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.
Please give us the following information:tomharris wrote:Assembly that contains embedded dotConnect for Oracle license cannot be used with this application: SchemaCompareforOracle. Please correct license 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
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
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 .
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
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