Devart Forums

We are trying to reuse an existing connection inside of a new scope, in order for the transaction in the parent scope to work. We tried updating to the latest version 9.13.1127. We have the same code working correctly with mssql and postgresql.

The code we have is somewhat equivalent to the following: * It is the first time UseOracle is executed in the child scope.

We get the following exception: I think this may be the same issue as what we've encountered.
https://github.com/abpframework/abp/issues/4473

Thank you for your report. We have reproduced the issue and are investigating it.

The bug with using another context's connection in DbContextOptionsBuilder.UseOracle(connection) in EF Core is fixed in v9.14.1150: viewtopic.php?f=1&t=44277.

Great, thanks.

I have tried to update to the latest version, but the changes you've made to the dependencies broke our solution.
We use .NET Core 3.1 and .NETStandard2.1 libraries, and do not want to upgrade to .NET 5.0.
Our solution is comprised from multiple projects, and manually adding an assembly reference to the "non-nuget" version of dotConnect in each and every one of them that requires it is completely impractical.
From the 30-40 or so other nugets we employ, we only have this problem with yours.
Up until this point, we had a single nuget reference to dotConnect up in the project hierarchy, and everything worked fine.
I have went over this topic viewtopic.php?f=1&t=39879 and I see that we are not the only ones who are unhappy with the recent changes.
It would be nice to perhaps have 2 different nugets to address this, or any other solution that would not force us to add assembly references to many of our projects.

TheCoolest wrote: ↑Sun 03 Jan 2021 09:03We use .NET Core 3.1 and .NETStandard2.1 libraries, and do not want to upgrade to .NET 5.0.

If you want to stay on Entity Framework Core 3, you need to switch the Target framework of your project to one of the following:
* .NET Core 2.x
* .NET Standard 2.0
* .NET Framework 4.6.1 or higher

After you downgrade the Target framework of your project, you should reload the project.

TheCoolest wrote: ↑Sun 03 Jan 2021 09:03I have went over this topic viewtopic.php?f=1&t=39879 and I see that we are not the only ones who are unhappy with the recent changes.

Actually, users in this thread required .NET Standard 2.0 assemblies for Entity Framework Core 3 (the current behavior).

We cannot downgrade to .NET Standard 2.0. Even when I add a separate project that is .NET Standard 2.0, and then reference it in a 2.1 project, the 2.1 project will still reference .NET 5.0 binaries and then fail to build.

There are several packages I have seen on the NuGet repository that offer 2 separate versions, one that works with .NET Core 3.1 and one that works with 5.0.
For example:
Most of Microsoft's packages.
Microsoft.EntityFrameworkCore.DynamicLinq. This is a good example. They have v3.2.7 for 3.1 and v5.2.7 for 5.0

Users in that thread had a different, but similar complaint, in the sense that the dependencies were changed, which made their projects incompatible with the new version of dotConnect.

Are there any updates on this matter?

We are looking for a solution and will notify you about the result.

Great, thank you.

Here is a workaround via editing the existing NuGet package:

1. Choose a directory we will store our NuGet package. If necessary, create it.
For example, let it be C:\NuGet.

2. Add this directory to the list of NuGet sources for Visual Studio.
2.1 To do this, go to the Tools menu -> NuGet Package Manager -> Package Manager Settings.
2.2 In the window that opens, go to the item below with the name "Package Sources".
2.3 Add a new source using the [+] button using any name.
2.4 Set the path to the folder as Source (in our example, it is C:\NuGet).
2.5 Click [Update].
2.6 We close the dialogue.

3. Go to nuget.org to the NuGet package page https://www.nuget.org/packages/Devart.D ... le.EFCore/ and download it by clicking "Download package", place it in the desired directory (in our example, it's C:\NuGet).

4. The current version of the package is 9.14.1180, so we will edit the devart.data.oracle.efcore.9.14.1180.nupkg file.
We will describe how to unpack and pack the package with the built-in Windows 10 tools, although you can do that with another more convenient tool (e.g.: 7-zip).
4.1 Rename the file, changing the extension to zip and, for example, increasing the build by one from 1180 to 1181 (such an increase is safe and will not lead to conflicts in the future, since we never release public NuGet packages that differ in the build number only by one, but always by a larger value; well, you can also, for example, not increment by one, but change to some specific build number, for example, to 9999) => then we get devart.data.oracle.efcore.9.14.1181.zip.
4.2 Call the context menu on the file, the Extract All item. It will be unpacked into the C:\NuGet\devart.data.oracle.efcore.9.14.1181 subfolder.
4.3 Go to this folder and open the text file Devart.Data.Oracle.EFCore.nuspec for editing.
4.4 Change the version value. If it was <version>9.14.1180</version>, change to <version>9.14.1181</version>.
4.5 Delete lines 4.6 Save the Devart.Data.Oracle.EFCore.nuspec file.
4.7 Go to the lib subdirectory and delete the netstandard2.1 subdirectory in it, i.e. you need to delete the folder C:\NuGet\devart.data.oracle.efcore.9.14.1181\lib\netstandard2.1\.
4.8 Navigate to the C:\NuGet\devart.data.oracle.efcore.9.14.1181\ folder, select all files including subdirectories, call the context menu: "Send to" -> "Compressed (zipped) folder".
4.9 Rename the resulting archive to devart.data.oracle.efcore.9.14.1181.nupkg
4.10 We move this file from this directory one level up, i.e. in C:\NuGet\.
4.11 In the C:\NuGet\ directory, delete the already unnecessary file devart.data.oracle.efcore.9.14.1181.zip and the subdirectory devart.data.oracle.efcore.9.14.1181

5. Open Visual Studio project and install devart.data.oracle.efcore package with version 9.14.1181 to the project. Do not forget that if we do this through the NuGet Package Manager, then the Package source for it must be set not to nuget.org, but to All (or local source).

Note that if at some stage something was done incorrectly, this wrong package was connected to a project in Visual Studio at least once, then before fixing it, you need to delete it from the NuGet package cache (delete directory C:\Users\%Your_User_Name%\.nuget\packages\devart.data.oracle.efcore\9.14.1181) or just clear the cache completely, for example in VS via Tools menu -> NuGet Package Manager -> Package Manager Settings, "Clear All NuGet cache (s)" button.

EF Core version in Model Settings is limited to EF Core 5 for .NET Core 3.1 VS project in the current public build. We will remove this limitation in the next public build to allow setting EF Core 3 as well. You can get the internal build with the fix, please contact us. Or use a standalone version of Entity Developer shipped with dotConnect for Oracle.

Thank you, good to hear that there will be an official release with EF Core 3.1 support.

Your how-to worked, and it's good enough for developer-side testing, sadly it's not really suitable for our build environment.
Looks like the original problem was also fixed, so that's great.

We will be waiting for the next official release in order to be able to more easily switch to the most up-to-date version.

TheCoolest wrote: ↑Mon 18 Jan 2021 15:02good to hear that there will be an official release with EF Core 3.1 support

EF Core version=EF Core 3 in Model Settings of Entity Developer will fix code generation, but manual editing of the package will still be required.

The behavior is changed in Entity Developer embedded into Visual Studio: lower versions in the EF Core version property of Model Settings are not hidden anymore. Refer to viewtopic.php?f=1&t=44490.