I have a project built in .net framework v4.8 and I have to add support for Cosmos DB to perform CRUD operations. How to achieve that as Microsoft.Azure.DocumentDB package is deprecated now?
Yes, the Nuget package Microsoft.Azure.DocumentDB is deprecated and the Alternate for this is Microsoft.Azure.Cosmos
Please refer Generic CRUD Operations For CosmosDB for more information
There are lots of public guides about creating applications, including the scenario you are describing: https://learn.microsoft.com/azure/cosmos-db/sql/sql-api-dotnet-application
If you already have an application using the V2 SDK (Microsoft.Azure.DocumentDB), you can use the migration guide to migrate it to V3 (Microsoft.Azure.Cosmos): https://learn.microsoft.com/azure/cosmos-db/sql/migrate-dotnet-v3
Related
I wonder if there is implemented ConfigurationProvider for ASP.NET Core which loads options from Database. EF or Dapper.
It's fairly easy to implement ourselves, but I wonder if there is ready solution, and if this really a good idea.
According to your description, I suggest you could try to use EfConfigurationProvider, you could directly use by installing through nuget package.
Install-Package EfConfigurationProvider -Version 0.2.1
More details about how to use it ,you could refer to this article.
If this doesn't match your requirement, I suggest you could create the custom provider by yourself, like this blog shows.
I am a little bit lost. I am reading Microsoft documentation for ASP.NET Core caching using Redis.
And the documentation suggests to use Microsoft.Extensions.Caching.StackExchangeRedis which is an open source third party library.
But I've seen some other tutorials are using Microsoft.Extensions.Caching.Redis, which is a more native asp.net core.
And at the end they both use the same interface IDistributedCache.
Why do I need Microsoft.Extensions.Caching.StackExchangeRedis?
What advantages it has over Microsoft.Extensions.Caching.Redis?
A look at the dependency graph for Microsoft.Extensions.Caching.Redis and Microsoft.Extensions.Caching.StackExchangeRedis reveals it.
Microsoft.Extensions.Caching.Redis is based on StackExchange redis 1.x library, whereas Microsoft.Extensions.Caching.StackExchangeRedis is based on 2.x of the same library.
Also Microsoft.Extensions.Caching.Redis doesn't seem to target the 3.1 extension libraries (Microsoft.Extensions.Options/Caching.Abstractions) where the other does.
So for .NET Core 3.x and newer use Microsoft.Extensions.Caching.StackExchangeRedis as the previous one may not be maintained as long as the new one.
My previous project which is written on .NET Framework is using NLog.Redis to log information and visualize it on Kibana through Logstash. Is NLog.Redis supported on .NET Core to use in my new project?
Currently there there is no .NET Standard (and so .NET Core) version released.
There is an open pull request for it, see https://github.com/richclement/NLog.Redis/pull/7
Does CockroachDB work with Microsoft Entity Framework? If not which ORM would work?
Yes, it should work with an external driver and we suggest using http://www.npgsql.org/.
Specifically their Entity Framework nuget package:
https://www.nuget.org/packages/EntityFramework6.Npgsql/
If you encounter any issues, please open issue on either
https://github.com/npgsql/npgsql or https://github.com/cockroachdb/cockroach
In my solution I have an ASP.NET Core 2 MVC app using Razor pages, a Web API 2 app and a .NET 4.7.1 class library containing services and their definitions that use Azure Table Storage from the Azure Storage NuGet (v8.7.0). I'm using autofac for dependency injection.
I have hooked up both my web apps to use classes from my library using Autofac's dependency injection. The Web API app works fine but the Core app doesn't. When I build without installing the Azure Storage NuGet package into the Core app I get the following error:
X.Library' with identity 'X.Library, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' uses 'Microsoft.WindowsAzure.Storage,
Version=8.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
which has a higher version than referenced assembly
'Microsoft.WindowsAzure.Storage' with identity
'Microsoft.WindowsAzure.Storage, Version=8.1.4.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
Which leads me to believe that ASP.NET Core 2 apps have Azure Storage pre-installed - I can't find any reference to it in the project though! Weird.
So I have tried to fixed this by installing the Azure Storage (v8.7.0) package which matches the version installed in the library I am using into my Core app. The app now builds and my dependencies are injected but when I try to use them I get MissingMethodExceptions for the methods CreateIfNotExists and CreateQuery. While my Web API app can query Azure Table Service my Core app can't use the same methods to do so.
After some research it seems that the ASP.NET Core implementation of the Azure Storage library has removed some synchronous methods and at runtime it uses this version rather than the .NET Framework compatible version my library references.
Is there any way to remove Azure Storage from the ASP.NET Core 2 app? Is it preinstalled, as I suspect?
I guess the easiest way to fix it is to use methods that are present in the Framework and Core implementations, is this how you'd fix it?
I found a solution to this problem with the help of this blog post: https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20
The post talks you through the process of porting a .Net Library to a .Net Standard library that targets multiple runtime versions. This turns out to be exactly what I needed to do.
I took my service that I had written in .Net framework 4.5.1 and copied the files to a new .Net Standard library I created. I then changed the target frameworks to support multiple runtime versions manually (you can't do this using the Visual Studio UI at time of writing). For my purposes I used the following to support .Net Core 2, .Net Standard and .Net 4.7.0:
<PropertyGroup>
<TargetFrameworks>netcoreapp2.0;netstandard2.0;net47</TargetFrameworks>
</PropertyGroup>
The framework you write first is the one that is targeted but I found that Visual Studio gave me errors for methods that weren't available in all versions of the Azure Storage library so I was able to write a service which worked on all three without writing any runtime-specific code.