What is the OracleCoherence library for .Net Core? - oracle

There is OracleCoherence.dll v12.2.1.3 for .Net Framework.
What is the equivalent OracleCoherence package for target framework .Net Core 3.1

This has been taken into consideration by the team.
https://github.com/oracle/coherence-dotnet-extend-client/issues/1

Related

AuthorizationFactory.GetAuthorizationProvider in .NET Core / Net standard

I'm trying to migrate a C# enterprise library-dependent project (.Net framework 4.8) into .NET Standard. I see there are EnterpriseLibrary NuGet package versions available for .Net Core
e.g.
EnterpriseLibrary.Caching.Cryptography.NetCore
EnterpriseLibrary.ExceptionHandling.NetCore
EnterpriseLibrary.Common.NetCore
However, I'm unable to find matching NuGet packages for some packages.
e.g.
Enterpriselibrary.Security I don't find an equivalent version in .NET Core
I have one of the methods AuthorizationFactory.GetAuthorizationProvider in .NET4.8 is there any equivalent replacement in .NET Core/Net Standard?

how to resolve target .NET Framework with Xamarin

i am new to development with Xamarian platform.Now i just want to run application to targetFramework 4.5. but there diff targetframework listed as below. how i resolve that please help me out.
See https://learn.microsoft.com/en-us/dotnet/standard/net-standard - in the table, note that .Net Framework 4.5 supports the newer net-standard up to 1.1. So choose .NET Standard 1.1. Or if you can require .Net Framework 4.5.1 and newer, choose .NET Standard 1.2.
Or better, whatever dependency is forcing you to use Framework 4.5, talk to the vendor, get them to rebuild for .NET Core 3.1 or the new .NET 6.
If you really must support .Net "Framework" APIs, see https://learn.microsoft.com/en-us/archive/msdn-magazine/2017/connect/net-introducing-the-windows-compatibility-pack-for-net-core, for a (no longer being updated) solution that allows your newer code to be "Net Core", yet work with legacy .net APIs.
Be aware all this is "legacy" - Microsoft's goal is to move everyone to .NET 6.

How do I convert a project from targeting .net core to target framework to a .net standard?

I created a new .net core 3.1 project and built it using VS2019 16.4.4
Now I want to change it to .Net Standard.
I know to go to the project properties and select the Target framework combo.
However no Standard framework options appear.
If I select Install other frameworks then I am taken to The download .Net SDKs for Visual Studio page
However the SDK I want is already installed on my machine.
Why am I not seeing what I want in the combo box.?
.NET Standard, like .NET Core and .NET Framework, is separate framework, so you can't switch that easily. You would need to create separate project targeting .NET Standard. Once you do it, you will see other options in 'Target framework'.
Worth to mention, you can't reference .NET Core and .NET Framework projects from your .NET Standard library, since .NET Standard is just an abstraction which is built differently depending on the executing environment (.NET Core or Framework)

.NET Core and IIS

We currently have a web api targeting .NET 4 framework which is hosted within IIS using an application pool which is using .NET 4 CLR.
We are investigating migrating the web api from .NET 4 to .NET Core 2.1 (for performance improvements). The web api has other DLL references which have been built using .NET 4 framework. I have a simple proof of concept up and running using .NET Core 2.1 and the references which had been built using .NET 4 framework appear to have imported fine as I can reference them and the project builds.
If I have the new .NET Core 2.1 web api referencing the 3rd party DLLs using .NET framework 4 which is then going to be hosted in IIS using the CLR 4... how would we see any performance increase? If everything is being run using the CLR 4, is that not the bottleneck for performance? Or is it the binaries that the CLR reads being more performant where you will see better performance?
Any guidance would be greatly appreciated as I'm very confused at the moment!
Thanks
It depends on how you're handling things. .NET Core 2.0+ fully supports .NET Standard 2.0, which has an API footprint large enough to cover most .NET Framework functionality. As a result, the compiler will let you add a .NET Framework library reference to a project that's actually targeting .NET Core 2.0+. There's no guarantee that the library will actually work (and you get a warning to that effect), but unless it's using Windows-specific APIs, there's a very good chance it will function fine.
Assuming this is the case with your .NET Framework libraries and you're actually targeting something like .NET Core 2.1, then you are not in fact using .NET Framework, and you don't even need .NET Framework installed on the server you're deploying to. All the requisite framework dependencies will come from the .NET Core runtime, or can even be packaged along with your app if you opt for a self-contained deployment. In that case, once compiled, it's virtually inconsequential that the libraries you referenced actually targeted .NET Framework.
If however the libraries do not work without full .NET Framework, you can still build a .NET Core app, but you'll be forced to continue to target .NET Framework, rather than .NET Core. In that case, you will of course be reliant on the .NET Framework CLR, with the performance drain that entails. That said, an ASP.NET Core app, for example, is still generally more performant than something like an ASP.NET MVC app, so you will get some gains - just not as much as if you were actually targeting .NET Core.
Regardless of what you ultimately end up targeting, your app is actually served via Kestrel. IIS acts merely as a reverse proxy.

ninject .net 4.0

Can you use Ninject 2.0 with VS2010 RC1?
I had similar issue... try targetting the full .NET 4 Framework, not the Client Profile.
From my understanding System.Web is in .NET 4, but not the .NET 4 Client Profile. So for your assemblies, in which you are taking advantage of full Ninject compiled against 3.5 sp1, you will need to ensure they are not targeting the .NET 4 Client Profile but the full .NET 4 profile in order for the dependency on System.Web to be satisfied.
Even if it is compiled for .NET 3.5, the assembly should be able to run in .NET 4. Here's a nice picture.

Resources