ASP Conflict between older installed dotConnect & newer ver.

ASP Conflict between older installed dotConnect & newer ver.

Postby PangoChris » Wed 21 Oct 2009 23:04

Our production web server has dotConnect for Oracle 5.25.42 installed and is being used by several ASP .NET applications for its LINQ to SQL features. These apps are finished and in production. That version of dotConnect was the newest at the time these apps were put into production.

Since then, a new ASP .NET application has been written and uses the latest version of dotConnect, yesterday's 5.25.49. This application depends on bugfixes from the last two dotConnect versions. This application is also using dotConnect for its LINQ to SQL features.

We are unable to run the new application, using the new dotConnect, on the production server, which has the old dotConnect installed. Obviously there's a lot of potential for conflict there, but I believe we have things setup correctly for such a situation and I'll go into detail there. The nature of the resulting exceptions makes me suspect a dotConnect problem, though I'm hoping there's just something we've forgotten to do.

First, here's details on the setup:

- dotConnect 5.25.42 was installed on the server using the installer, so all its DLLs are in the GAC. The ASP .NET apps that were written against this version expect these in the GAC, and they are working fine.

- dotConnect 5.25.49 (and .44 prior to it, with the same results) was used to write the new ASP .NET app. That app is configured to deploy this new dotConnect version to its bin directory so that it doesn't depend on which dotConnect version is in the GAC on the server. We did this by including the file licenses.licx in the project as an Embeddable Resource with the contents "Devart.Data.Oracle.OracleConnection, Devart.Data.Oracle". The project references Devart.Data, Devart.Data.Linq, Davart.Data.Oracle, and Devart.Data.Oracle.Linq, and each reference has Copy Local set to True.

Once deployed, the new application throws an exception on *almost* every attempted database query. Different queries result in different exceptions, but they all come from within the dotConnect libaries. I've isolated the problem by creating a fresh ASP .NET 3.5 web app that just does one query. This app uses the new dotConnect and deploys it to its bin dir and has the license file setup just as I described for the full app. I also get the same results when running a sample Console app on the server using these same LINQ queries.

This code will work:

Code: Select all
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
   Dim dc As New DataContext1.DataContext1()
   Dim ws = (From w In dc.Webschedules).FirstOrDefault()
   Label1.Text = ws.Id.ToString() & " " & ws.Codevalue
End Sub


This code throws System.InvalidCastException: Unable to cast object of type 'Devart.Data.Oracle.OracleParameter' to type 'Devart.Data.Oracle.OracleParameter':

Code: Select all
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
   Dim dc As New DataContext1.DataContext1()
   Dim ws = (From w In dc.Webschedules Where w.ID = 1).FirstOrDefault()
   Label1.Text = ws.Id.ToString() & " " & ws.Codevalue
End Sub


Stack Trace:

[InvalidCastException: Unable to cast object of type 'Devart.Data.Oracle.OracleParameter' to type 'Devart.Data.Oracle.OracleParameter'.]
Devart.Data.Oracle.Linq.Provider.OracleDataProvider.ApplyParameter(DbParameter parameter, String name, ParameterDirection direction, Boolean sourceColumnNullMapping, ProviderType providerType, Type clrType, Object parameterValue) +154
Devart.Data.Linq.Provider.DataProvider.a(c A_0, f A_1, Object[] A_2, Object[] A_3, Object A_4) +297

[LinqCommandExecutionException: Error on executing DbCommand.]
Devart.Data.Linq.LinqCommandExecutionException.CanThrowLinqCommandExecutionException(String message, Exception e) +60
Devart.Data.Linq.Provider.DataProvider.a(c A_0, f A_1, Object[] A_2, Object[] A_3, Object A_4) +1597
Devart.Data.Linq.Provider.DataProvider.a(c A_0, Object[] A_1) +64
Devart.Data.Linq.Provider.DataProvider.h(Expression A_0) +81
Devart.Data.Linq.DataQuery`1.System.Linq.IQueryProvider.Execute(Expression expression) +51
System.Linq.Queryable.FirstOrDefault(IQueryable`1 source) +269
DevartTestSite._Default.Page_Load(Object sender, EventArgs e) in C:\DevartTestSite\Default.aspx.vb:6
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +50
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +627


As soon as we uninstall dotConnect 5.25.42 from the server the sample applications work correctly. Installing 5.25.42 back makes them crash.

I've verified that this occurs on three different servers, all Win 2003 / IIS with dotConnect 5.25.42 installed. Deploying the sample app using 5.25.44 also results in the same crash.

Obviously a workaround is to uninstall 5.25.42 from the server and change the existing apps to use local copies, or upgrade them to use the latest dotConnect version, but those apps are already tested and in production and we don't want to be changing them and risk regressions.

Our biggest concern is that simply having dotConnect installed on a server prevents us from deploying applications using newer versions, and we don't want to be in the game of upgrading / redeploying all production apps every time one new app needs to upgrade.

Yikes, that was much much more typing than I hoped to do =)

Thanks,
Chris
PangoChris
 
Posts: 12
Joined: Mon 14 Sep 2009 20:11

Postby Shalex » Fri 23 Oct 2009 14:12

I cannot reproduce this problem. It seems like some old assemblies are loaded to the process of your application that uses 5.25.49.
1. Can you debug your application in production environment to see the versions of assemblies loaded to the process of your application?
2. Please try precompiling (the Publish Web Site item in the context menu of your project in Solution Explorer) your web application and deploying it in this way. Make sure that the Local Copy property of our assemblies is set to true. Does the problem persist in this case?
Shalex
Devart Team
 
Posts: 7654
Joined: Thu 14 Aug 2008 12:44

Postby PangoChris » Fri 23 Oct 2009 18:04

I've got a better handle on what's going on now, as I can reproduce this with a console app on my XP workstation, removing ASP and the production server from the equation, and a lot of unnecessary details from the above post =)

You're right, old assemblies are indeed getting loaded into the process, but alongside new assemblies. And yes, I have Local Copy set to true for all references.

At the time of the exception, the app has two different versions of Devart.Data.dll and Devart.Data.Oracle.dll loaded. I used Sysinternals' Process Explorer to see their locations, and these second copies are the older ones located in the GAC.

Stepping through with the debugger while watching Process Explorer, I can see that the app immediately loads the four Devart DLLs that are in its bin directory, as it should. Once the LINQ query is executed though, the two older DLLs from the GAC get loaded. This suggests to me that at least one of the references within one of the Devart DLLs to Devart.Data.dll or Devart.Data.Oracle.dll is choosing whatever is in the GAC over what's sitting alongside it, even though what's sitting alongside it has the correct version number and what's in the GAC doesn't.

On my XP Pro SP3 workstation I currently have 5.25.44.0 installed (so in the GAC) and my console app compiled against 5.25.49.0 DLLs which reside in the exe's directory. All the references have SpecificVersion set to true. When the app starts, these are the Devart DLLs & versions it has loaded, all from the exe's directory:

Devart.Data.dll 5.0.11.0
Devart.Data.Linq.dll 1.0.22.0
Devart.Data.Oracle.dll 5.25.49.0
Devart.Data.Oracle.Linq.dll 1.0.22.0

and when the LINQ query runs, these guys from the GAC join the party:

Devart.Data.dll 5.0.8.0
Devart.Data.Oracle.dll 5.25.44.0

and then the exception is thrown, as you'd expect from the interaction between older and newer assemblies.

As soon as I remove the Devart DLLs from the GAC the application runs.

As you can see, I have 5.25.44.0 installed on my workstation as opposed to 5.25.42.0 on our servers, and with the same results. It really does seem to be as simple as a reference preferring GAC over what's in its own directory and ignoring the version numbers.

(Even though I'm using a console app now to simplify the situation, I've gone back and verified that everything I just said applies to the ASP app on the server too.)


Thank you for looking into this! I really appreciate your responsiveness. Let me know if you need any more info.
PangoChris
 
Posts: 12
Joined: Mon 14 Sep 2009 20:11

Postby PangoChris » Fri 23 Oct 2009 21:45

I have a few more clues.

I was wrong in the above post, if I manually uninstall the older Devart.Data.dll and Devart.Data.Oracle.dll from the GAC then I get an exception because .NET can't find the older version number (It's when I use the uninstaller that the app runs fine). I turned on assembly binding logging, and this shows that System.Data is the one who is looking for Devart.Data.Oracle.dll with the older version 5.25.44.0, which when found in turn loads Devart.Data.dll 5.0.8.0.

Here's what's thrown when I manually uninstall the two older DLLs from the GAC and run the app, showing that the newer Devart.Data.Linq.dll's calls into System.Data.dll result in System.Data.dll attempting to load the older Devart.Data.Oracle.dll:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701' ---> System.IO.FileLoadException: Could not load file or assembly 'Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701'

Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\LinqExistsTest\LinqExistsTest\bin\Debug\LinqExistsTest.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: DisplayName = Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701
(Fully-specified)
LOG: Appbase = file:///C:/LinqExistsTest/LinqExistsTest/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Publisher policy file is found at C:\WINDOWS\assembly\GAC_MSIL\policy.5.25.Devart.Data.Oracle\5.25.44.0__09af7300eec23701\policy.5.25.Devart.Data.Oracle.config.
LOG: Publisher policy file redirect is found: 5.25.44.0 redirected to 5.25.44.0.
LOG: ProcessorArchitecture is locked to MSIL.
LOG: Post-policy reference: Devart.Data.Oracle, Version=5.25.44.0, Culture=neutral, PublicKeyToken=09af7300eec23701, processorArchitecture=MSIL
LOG: Attempting download of new URL file:///C:/LinqExistsTest/LinqExistsTest/bin/Debug/Devart.Data.Oracle.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

at System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName)
at System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
at System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
at System.Type.GetType(String typeName)
at System.Data.Common.DbProviderFactories.GetFactory(DataRow providerRow)
at Devart.Data.Linq.Provider.DataProvider.get_ProviderFactory()
at Devart.Data.Linq.Provider.DataProvider.CreateConnection()
at Devart.Data.Oracle.Linq.Provider.OracleDataProvider.CreateConnection()
at Devart.Data.Linq.Provider.DataProvider.a(e A_0, Object A_1)
at Devart.Data.Linq.DataContext.a(Object A_0, MappingSource A_1, Type A_2)
at Devart.Data.Linq.DataContext..ctor(String connectionString, MappingSource mapping)
at CBP.Data.DataContext..ctor(String connection)
at LinqExistsTest.Module1.test()
at LinqExistsTest.Module1.Main()
PangoChris
 
Posts: 12
Joined: Mon 14 Sep 2009 20:11

Postby Shalex » Mon 26 Oct 2009 17:52

We think that the issue with loading old assemblies is caused by registration of our provider factory for old version in the machine.config file. This problem can be simply overcome by registration of the provider factory for the 5.25.49 version in the app.config file of your application that uses 5.25.49. I mean, just add the following entry to the *.config files of your applications that uses the 5.25.49 version and you can deploy them in the environment with installed dotConnect for Oracle 5.25.42:
Code: Select all

       
    
      
               description="Devart dotConnect for Oracle" type="Devart.Data.Oracle.OracleProviderFactory, Devart.Data.Oracle, Version=5.25.49.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
    

   


Please notify us about the results.
Shalex
Devart Team
 
Posts: 7654
Joined: Thu 14 Aug 2008 12:44

Postby PangoChris » Mon 26 Oct 2009 20:25

Yes!

That solves the problem, thank you very much. This was approaching show stopper for us. I just finished testing it on the sample console app and the actual web app, both are now working great on multiple machines with old dotConnect versions installed, and the old DLLs aren't being loaded.


Thanks again!
Chris
PangoChris
 
Posts: 12
Joined: Mon 14 Sep 2009 20:11


Return to dotConnect for Oracle