As soon as I've solved one issue with IBM.EntityFrameworkCore, another one has arose. Everything is soooo hard and painful with DB2 and their .NET team...
The problem: I have several EntityFrameworkCore - based projects in the same VS solution, for example MyDb2EfModel, MyMsSqlEfModel, and MyNpgsqlEfModel. (It's kind of a complex data-integration scenario.) On top of that I have a CLI project which references all the three and performs actual data ops. When the CLI project references only MyDb2EfModel project - IBM.EntityFrameworkCore works as expected. But as soon as I add references to the remaining two projects - it simply stops working and throws some misleading exception. The exception happens because overridden DbContext.OnConfiguring and DbContext.OnModelCreating methods aren't called anymore. When there's only one reference (MyDb2EfModel) the methods get called as expected, and everything works. But with all three library projects referenced - they aren't called anymore.
Let's also note that the mentioned methods get called on DbContext instances from MyMsSqlEfModel and MyNpgsqlEfModel libraries. The only one that stops working is MyDb2EfModel (which is based on IBM.EntityFrameworkCore).
Thumbs down for IBM and their .NET team! It's ridiculous how these guys are making things be 100 times more complicated then with any other DB.
The question is obvious: Does anyone has any experience in a similar scenario, and hopefully any suggestion how to resolve the issue?
Thanks!
I've found the reason. It turned out that it's about Microsoft.EntityFrameworkCore version. Currently available version of IBM.EntityFrameworkCore is 1.1.1.101 (.NET Standard 1.6), and it uses Microsoft.EntityFrameworkCore version 1.1.1 or 1.1.2. It cannot be used with Microsoft.EntityFrameworkCore version 2.0.0 (.NET Standard 2.0) - it throws the exception I was getting.
In the other two libraries I've used Npgsql.EntityFrameworkCore.PostgreSQL version 2.0.0 and Microsoft.EntityFrameworkCore.SqlServer version 2.0.0, both depending on Microsoft.EntityFrameworkCore version 2.0.0 (all in .NET Standard 2.0).
So when I referenced only MyDb2EfModel in my CLI project everything was working because only Microsoft.EntityFrameworkCore version 1.1.2 is referenced and used. But as soon as I add reference to another projects CLI ends up with dependencies on both Microsoft.EntityFrameworkCore version 1.1.2 and 2.0.0 versions, and the newer (2.0.0) is loaded and used. And IBM.EntityFrameworkCore was failing because it cannot use it.
How to solve? Either wait for IBM.EntityFrameworkCore for .NET Standard 2.0, or downgrade other references to ensure that Microsoft.EntityFrameworkCore version 2.0.0 isn't used anywhere (which will cause other headaches).
So although it's not about a bug in IBM.EntityFrameworkCore, IBM DB2 .NET team is still to blame for not having .NET Standard 2.0 at least preview published, although .NET Standard 2.0 is available for almost a year now, recently reaching its "release" version. And there are more things to blame IBM DB2 .NET team for (unrelated to this particular issue).
Related
tl;dr:
I have a .NET Framework 4.7.2 project consuming a NuGet package which supports .NET Standard 2.0. That package, in turn, requires another package which supports .NET Standard 2.0. However, when run, the latter package uses net461 binaries rather than netstandard2.0.
How do I force a NuGet package & its dependencies to use .NET Standard 2.0?
Are there special steps required to consume a .NET Standard package from a .NET Framework 4.7.2 project?
Specifics:
I am trying to get the NuGet package for SparkplugNet (which uses the MQTTNet package) working in a .NET Framework 4.7.2 project - just the basic "How to use" SparkplugB example. Both projects support .NET Standard 2.0. After some debugging (details below), it appears MQTTNet is trying to use code paths specific to .NET Framework 4.6.1, rather than .NET Standard 2.0, and crashing with no feedback whatsoever.
To troubleshoot, I built SparkplugNet and MQTTNet from source. As far as I can tell, the crash comes from hitting .NET 4.5/4.6.1-specific code in CrossPlatformSocket.ConnectAsync(), specifically this line (in context):
await Task.Factory.FromAsync(_socket.BeginConnect, _socket.EndConnect, host, port, null).ConfigureAwait(false)
When I debug, _socket is a System.Net.Sockets.Socket which doesn't appears to have a BeginConnect() method, at least in the source file my debugger pulled. I am not sure why it branches to that code when .NET Standard 2.0 would be a better fit.
Back to a 4.7.2 project consuming SparkplugNet & MQTTNet via NuGet package.... If I look at the reference paths, SparkplugNet is properly pointed at the netstandard2.0 folder, but MQTTNet points to packages\MQTTnet.4.1.3.436\lib\net461\MQTTnet.dll. If I change the hint path manually in the project file, MSBuild appears to pull from the netstandard2.0 folder, but it still crashes. I assume it is the same cause, though I'm having trouble debugging using NuGet packages. Also, I'm hoping for a better solution than hacking hint paths.
I am using Steeltoe.CloudFoundry.Connector.EFCore with Npgsql.EntityFrameworkCore.PostgreSQL. I want to migrate the application to .NET 5.0. After updating Npgsql to 5.0.2 I am getting the error 'Unable to find DbContextOptionsBuilder, are you missing a PostgreSql EntityFramework Core assembly?' when adding DBContext.
I tried to look at the available versions of Steeltoe, but the highest NuGet I see is 2.5.2, which gives me this error as well as the older I had (2.4.4).
Is there any version combination of those libraries that works?
The name of that Steeltoe package changed in 3.0, you'll be needing Steeltoe.Connector.EFCore going forward.
The name of that particular type inside Npgsql.EntityFrameworkCore.PostgreSQL changed in 5.0, so that's what is preventing Steeltoe from finding it. The fix has also been applied to the 2.x branch and is included in version 2.5.3.
Check the Steeltoe Samples repo for both 2.x and 3.x versions
I have a multi-project solution that contains a data layer on .Net Standard 2.1 and a WebAPI on .Net Core 3.1. Currently, I have no plans to upgrade to .Net 5.x (Note: Core is removed in 5.x naming convention) because it is not LTS - that will be .Net 6.x. So, I will upgrade to 6.x when it comes out.
In one of my data layer solutions, the NuGet Package Manager is recommending that I upgrade Microsoft.AspNetCore.Identity.EntityFrameWorkCore from v3.1.8 to v5.0.2. It seems like the major version is moving in lockstep with the .Net major version (Note: 4.x is skipped in order to avoid confusion with the venerable .Net Framework 4.x). Should I follow the advice and upgrade?
Specifically, will this cause any problems with the .Net Core 3.1 WebAPI project? Generally, can I do this for other Microsoft.* packages that recommend upgrading to a 5.x version?
I bit the bullet and upgraded all of them. Everything works flawlessly and I am glad that I did it. There were a few breaking changes that needed to be dealt with. I recommend checking Microsoft's breaking change log here:
https://learn.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio
This scenario goes a bit against the whole way nuget works so what i might be asking for is a hack...
My problem:
I need to have Restsharp and Protobuf-net referred to in a .net assembly that going into SQL-CLR for Server 2008 (so max .net 3.5, framework 2.0).
Restsharp goes back to 3.5 as the lowest supported fwk version.
Protobuf-net 3.5 onwards has a lot of gunk referring to system.servicemodel (and WCF) which i don't need and use and actively want to remove because it causes issues with installing on SQL-CLR. Protobuf-net 2.0 doesn't have this :)
So i've built and tested my code with an assembly targeting .net 3.5 and i installed the restsharp nuget - which gave me the correct reference and i manually added a reference to the protobuf-net 2.0 distro.
This is where i'd like to know - can i (in any way) install the protobuf-net nuget package but still have it reference the .net20 DLL in my assembly which targets 3.5?
The static reference is not a huge deal since protobuf-net has been pretty stable, but i'd like to get the whole setup via nuget if possible.
In the end, this is a workaround as solution to:
protobuf-net version without system.servicemodel dependency?
If there's a better answer to that, i'd be very grateful :)
As far as I know, that is not possible. You could of course create your own custom build and host it on a local nuget drop, or as your own nuget package on the public feed. AFAIK, there's no way to do what you want inside a new nuget folder in the existing package.
We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post