Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> ORMSupportClasses 5.3.4 requires System.Data.SqlClient 4.4.0 strict
 

Pages: 1
Bugs & Issues
ORMSupportClasses 5.3.4 requires System.Data.SqlClient 4.4.0 strict
Page:1/1 

  Print all messages in this thread  
Poster Message
Findev
User



Location:

Joined on:
08-Dec-2014 23:21:38
Posted:
78 posts
# Posted on: 22-Mar-2018 14:16:02.  
Hi,

Upgraded the LLBLGen to 5.3.4 and tried updating the dependency to System.Data.SqlClient 4.4.3, however, currently orm support classes require 4.4.0 strictly. Wasn't sure whether it is on purpose, so post is more of something that was noticed Regular Smiley

Thank you!
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37866 posts
# Posted on: 22-Mar-2018 14:50:48.  
That is likely an error in our nuget package file. We'll check it out.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37866 posts
# Posted on: 22-Mar-2018 15:06:50.  
Nuget package updated, please try 5.3.5 hotfix package for ormsupport classes and the DQE you're using.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
sparq
User



Location:

Joined on:
14-Mar-2010 22:56:10
Posted:
49 posts
# Posted on: 25-Mar-2018 21:49:28.  
Otis wrote:
Nuget package updated, please try 5.3.5 hotfix package for ormsupport classes and the DQE you're using.


Is the dependency itself a mistake? We use Oracle and it seems odd that the core package should depend on SQL Server.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37866 posts
# Posted on: 26-Mar-2018 10:22:26.  
sparq wrote:
Otis wrote:
Nuget package updated, please try 5.3.5 hotfix package for ormsupport classes and the DQE you're using.


Is the dependency itself a mistake? We use Oracle and it seems odd that the core package should depend on SQL Server.

No it's not a mistake, it's an unfortunate thing we can't avoid: the azure recovery strategy is located in the ORM Support Classes and it depends on the SQLClient due to the requirement of SqlException. This wasn't a problem on .NET full as SQLClient is part of that, but on .net core/standard it is a problem. There's no solution to this, other than moving the azure recovery strategy but to where? The sqlserver DQE is the only place where we can move it to but that doesn't make much sense and it would be a breaking change which would break the code of everyone using it.

We could have removed the azure strategy and offer it as sourcecode (it's not a big class) in the documentation but then migrating to .netstandard would be less ideal and we didn't want that either. So all in all, there were only bad solutions to a crappy problem so in the end we opted for this one which is the least problematic: nuget will simply pull in the package and nothing breaks and you don't have to worry about anything.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
sparq
User



Location:

Joined on:
14-Mar-2010 22:56:10
Posted:
49 posts
# Posted on: 26-Mar-2018 21:58:16.  
Otis wrote:
sparq wrote:
Otis wrote:
Nuget package updated, please try 5.3.5 hotfix package for ormsupport classes and the DQE you're using.


Is the dependency itself a mistake? We use Oracle and it seems odd that the core package should depend on SQL Server.

No it's not a mistake, it's an unfortunate thing we can't avoid: the azure recovery strategy is located in the ORM Support Classes and it depends on the SQLClient due to the requirement of SqlException. This wasn't a problem on .NET full as SQLClient is part of that, but on .net core/standard it is a problem. There's no solution to this, other than moving the azure recovery strategy but to where? The sqlserver DQE is the only place where we can move it to but that doesn't make much sense and it would be a breaking change which would break the code of everyone using it.

We could have removed the azure strategy and offer it as sourcecode (it's not a big class) in the documentation but then migrating to .netstandard would be less ideal and we didn't want that either. So all in all, there were only bad solutions to a crappy problem so in the end we opted for this one which is the least problematic: nuget will simply pull in the package and nothing breaks and you don't have to worry about anything.


Thanks.. That's disappointing as we've been trying to slim down the size of our deployed .NET Framework application and dragging an unused .NET Standard DLL is frustrating.


  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.