MarimerLLC / cslaforum

Discussion forum for CSLA .NET
https://cslanet.com
Other
31 stars 6 forks source link

CSLA.Data.ContextManager not found #910

Open schreindog20 opened 4 years ago

schreindog20 commented 4 years ago

Hi,

I am trying to upgrade from CSLA from 3.8.2 to the latest (4.11.2) CSLA-Core NuGet package.

We make use of CSLA.Data.ContextManager to assist our data access with System.Data.Linq.DataContext class. I see that in the repo there is a ContextManager class, but it does not show up when I try to access it in my code.

The only classes I can see in the CSLA.Data namespace are ConnectionManager, ConnectionManager<>, DataMap, DataMapper, ObjectAdapter, SafeDataReader, and TransactionManager<>.

Did the ContextManager class get removed or changed in a way I cannot see from the repo code? If not, do you know what else might be the issue why I can't see or access this class?

rockfordlhotka commented 4 years ago

There are now two competing SqlClient implementations from Microsoft, so we had to remove the SQL-related types from the main CSLA package and put them in two separate packages. You pick the Csla.Data.SqlClient (the new one) or Csla.Data.SqlClient.Fx (the old one) depending on which of the Microsoft SqlClient versions you are using.

schreindog20 commented 4 years ago

Okay, but I'm not using SqlClient. I'm just trying to use the CSLA.Data.ContextManager class. Did that get replaced by ConnectionManager? Or is it still in use? Because if it's still in use, I cannot find it within the CSLA.Data namespace. All I saw when I installed either CSLA.Data.SqlClient package was a ConnectionManager in those namespaces.

rockfordlhotka commented 4 years ago

Ahh, sorry, ContextManager supports EF. Same issue there - Right now there are packages for EF 4, 5, 6, and EF Core. You need to reference the NuGet package for the specific version of EF you are using.

Edit: Actually there's EF Core 2 and 3 - so lots of options for versions of EF...

schreindog20 commented 4 years ago

First off, I wanted to thank you and let you know I appreciate you taking an interest in my issue and for your prompt responses.

Ultimately I'm trying to work with the class below:


    /// <summary>
    /// Helper class to get default context manager.
    /// </summary>
    /// <typeparam name="T">Type of DataContext.</typeparam>
    public static class DefaultContextManager<T> where T : System.Data.Linq.DataContext
    {
        /// <summary>
        /// Gets instance of ContextManager.
        /// </summary>
        /// <returns>A new context manager instance.</returns>
        public static ContextManager<T> Get()
        {
            return ContextManager<T>.GetManager(
                DatabaseConfiguration.Name, true, typeof(T).Name);
        }
    }

From what I can tell, the System.Data.(whatever version of EF package I use).ContextManager only works with Entity Framework. Is there anything that would provide the functionality I need in the code above to work with System.Data.Linq.DataContext instead, or has that been depreciated?

schreindog20 commented 4 years ago

I probably should have just shared the code right away, my apologies for that :)

rockfordlhotka commented 4 years ago

Oh, wow, LINQ to SQL!

Microsoft deprecated that years ago, and I am not sure if it is still supported in .NET Core.

It is only compiled into CSLA for .NET Framework 4, 4.5 and 4.6.

schreindog20 commented 4 years ago

Ah ok I see. Yeah I know... It's an older codebase that hasn't been touched in a few years and so logical updates like that haven't been maintained. We're planning on moving away from LINQ to SQL soon as well. But I think I can figure out a workaround so we can first upgrade CSLA and then do that after. Right now we're just trying to be able to transition our Windows Services to .NET Core, but we can't do that without fist upgrading CSLA to configure them correctly. And no, LINQ to SQL is not supported by Core (and thus why we'll be moving on from it, among other reasons you mentioned lol), but we can at least write a Core service without having to transition from that yet. That's the only reason we were trying to upgrade CSLA before replacing LINQ to SQL.

But thank you for your help! It really helps a lot to know when I hit a dead end, otherwise I would have kept looking for something. I appreciate all your support. Thank you :)