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
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
[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