Settings Results in 4 milliseconds

[HTTP Error 500.30]: Failed to load coreclr.Except ...
Category: Servers

Question How do you solve for error that says "HTTP Error 500.30-ASP.NET Core a ...


Views: 0 Likes: 37
 The .NET Stacks #18: RC1 is here, the fate of .NET Standard, and F# with Isaac Abraham
The .NET Stacks #18 RC1 is here, the fate of .NE ...

.NET 5 RC1 is hereThis week, Microsoft pushed out the RC1 release for .NET 5, which is scheduled to officially “go live” in early November. RC1 comes with a “go live” license, which means you get production support for it. With that, RC1 versions were released for ASP.NET Core and EF Core as well.I’ve dug deep on a variety of new features in the last few months or so—I won’t  rehash them here. However, the links are worth checking out. For example, Richard Lander goes in-depth on C# 9 records and System.Text.Json.The fate of .NET StandardWhile there are many great updates to the upcoming .NET 5 release, a big selling point is at a higher level the promise of a unified SDK experience for all of .NET. The idea is that you’ll be able to use one platform regardless of your needs—whether it’s Windows, Linux, macOS, Android, WebAssembly, and more. (Because of internal resourcing constraints, Xamarin will join the party in 2021, with .NET 6.)Microsoft has definitely struggled in communicating a clear direction for .NET the last several years, so when you pair a unified experience with predictable releases and roadmaps, it’s music to our ears.You’ve probably wondered what does this mean for .NET Standard? The unified experience is great, but what about when you have .NET Framework apps to support? (If you’re new to .NET Standard, it’s more-or-less a specification where you can target a version of Standard, and all .NET implementations that target it are guaranteed to support all its .NET APIs.)Immo Landwerth shed some light on the subject this week. .NET Standard is being thrown to the .NET purgatory with .NET Framework it’ll still technically be around, and .NET 5 will support it—but the current version, 2.1, will be its last.As a result, we have some new target framework names net5.0, for apps that run anywhere, combines and replaces netcoreapp and netstandard. There’s also net5.0-windows (with Android and iOS flavors to come) for Windows-specific use cases, like UWP.OK, so .NET Standard is still around but we have new target framework names. What should you do? With .NET Standard 2.0 being the last version to support .NET Framework, use netstandard2.0 for code sharing between .NET Framework and other platforms. You can use netstandard2.1 to share between Mono, Xamarin, and .NET Core 3.x, and then net5.0 for anything else (and especially when you want to use .NET 5 improvements and new language features). You’ll definitely want to check out the post for all the details.What a mess .NET Standard promised API uniformity and now we’re even having to choose between that and a new way of doing things. The post lays out why .NET Standard is problematic, and it makes sense. But when you’re trying to innovate at a feverish pace but still support customers on .NET Framework, the cost is complexity—and the irony is that with uniformity with .NET 5, that won’t apply when you have legacy apps to support.Dev Discussions Isaac AbrahamAs much as we all love C#, there’s something that needs reminding from time to time C# is not .NET. It is a large and important part of .NET, for sure, but .NET also supports two other languages Visual Basic and F#. As for F#, it’s been gaining quite a bit of popularity over the last several years, and for good reason it’s approachable, concise, and allows you to embrace a functional-first language while leveraging the power of the .NET ecosystem.I caught up with Isaac Abraham to learn more about F#. After spending a decade as a C# developer, Isaac embraced the power of F# and founded Compositional IT, a functional-first consultancy. He’s also the author of Get Programming with F# A Guide for .NET Developers.I know it’s more nuanced than this but if you could sell F# to C# developers in a sentence or two, how would you do it?F# really does bring the fun back into software development. You’ll feel more productive, more confident and more empowered to deliver high-quality software for your customers.Functional programming is getting a lot of attention in the C# world, as the language is adopting much of its concepts (especially with C# 9). It’s a weird balance trying to have functional concepts in an OO language. How do you feel the balance is going?I have mixed opinions on this. On the one hand, for the C# dev it’s great—they have a more powerful toolkit at their disposal. But I would hate to be a new developer starting in C# for the first time. There are so many ways to do things now, and the feature (and custom operator!) count is going through the roof. More than that, I worry that we’ll end up with a kind of bifurcated C# ecosystem—those that adopt the new features and those that won’t, and worse still the risk of losing the identity of what C# really is.I’m interested to see how it works out. Introducing things like records into C# is going to lead to some new and different design patterns being used that will have to naturally evolve over time.I won’t ask if C# will replace F#—you’ve eloquently written about why the answer is no. I will ask you this, though is there a dividing line of when you should use C# (OO with functional concepts) or straight to F#?I’m not really sure the idea of “OO with functional concepts” really gels, to be honest. Some of the core ideas of FP—immutability and expressions—are kind of the opposite of OO, which is all centered around mutable data structures, statements and side effects. By all means use the features C# provides that come from the FP world and use them where it helps—LINQ, higher order functions, pattern matching, immutable data structures—but the more you try out those features to try what they can do without using OO constructs, the more you’ll find C# pulls you “back.” It’s a little like driving an Audi on the German motorway but never getting out of third gear.My view is that 80% of the C# population today—maybe more—would be more productive and happier in F#. If you’re using LINQ, you favour composition over inheritance, and you’re excited by some of the new features in C# like records, switch expressions, tuples, and so on, F# will probably be a natural fit for you. All of those features are optimised as first-class citizens of the language, whilst things like mutability and classes are possible, but are somewhat atypical.This also feeds back to your other question—I do fear that people will try these features out within the context of OO patterns, find them somehow limited, and leave thinking that FP isn’t worthwhile.Let’s say I’m a C# programmer and want to get into F#. Is there any C# knowledge that will help me understand the concepts, or is it best to clear my mind of any preconceived notions before learning?Probably the closest concept would be to imagine your whole program was a single LINQ query. Or, from a web app—imagine every controller method was a LINQ query. In reality it’s not like that, but that’s the closest I can think of. The fact that you’ll know .NET inside and out is also a massive help. The things to forget are basically the OO and imperative parts of the language classes, inheritance, mutable variables, while loops, and statements. You don’t really use any of those in everyday F# (and believe me, you don’t need any of them to write standard line of business apps).As an OO programmer, it’s so painful always having to worry about “the billion dollar mistake” nulls. We can’t assume anything since we’re mutating objects all over the place and often throw up our hands and do null checks everywhere (although the language has improved in the last few versions). How does F# handle nulls? Is it less painful?For F# types that you create, the language simply says null isn’t allowed, and there’s no such thing as null. So in a sense, the problem goes away by simply removing it from the type system. Of course, you still have to handle business cases of “absence of a value,” so you create optional values—basically a value that can either have something or nothing. The compiler won’t let you access the “something” unless you first “check” that the value isn’t nothing.So, you spend more time upfront thinking about how you model your domain rather than simply saying that everything and anything is nullable. The good thing is, you totally lose that fear of “can this value be null when I dot into it” because it’s simply not part of the type system. It’s kind of like the flow analysis that C# 8 introduced for nullability checks—but instead of flow analysis, it’s much simpler. It’s just a built-in type in the language. There’s nothing magical about it.However, when it comes to interoperating with C# (and therefore the whole BCL), F# doesn’t have any special compiler support for null checks, so developers will often create a kind of “anti-corruption” layer between the “unsafe outside world” and the safe F# layer, which simply doesn’t have nulls. There’s also work going on to bring in support for the nullability surface in the BCL but I suspect that this will be in F# 6.F#, and functional programming in general, emphasizes purity no side effects. Does F# enforce this, or is it just designed with it in mind?No, it doesn’t enforce it. There’s some parts of the language which make it obvious when you’re doing a side effect, but it’s nothing like what Haskell does. For starters, the CLR and BCL don’t have any notion of a side effect, so I think that this would difficult to introduce. It’s a good example of some of the design decisions that F# took when running on .NET—you get all the goodness of .NET and the ecosystem, but some things like this would be challenging to do. In fact, F# has a lot of escape hatches like this. It strongly guides you down a certain path, but it usually has ways that you can do your own thing if you really need to.You still can (and people do) write entire systems that are functionally pure, and the benefits of pure functions are certainly something that most F# folks are aware of (it’s much easier to reason about and test, for example). It just means that the language won’t force you to do it.What is your one piece of programming advice?Great question. I think one thing I try to keep in mind is to avoid premature optimisation and design. Design systems for what you know is going to be needed, with extension points for what will most likely be required. You can never design for every eventuality, and you’ll sometimes get it wrong, that’s life—optimise for what is the most likely outcome.To read the entire interview, head on over to my site.?? Last week in the .NET world?? The Top 3.NET 5 RC 1 is out Richard Lander has the announcement, Jeremy Likness talks about EF updates, and Daniel Roth discusses what’s new for ASP.NET.Immo Landwerth speaks about the future of .NET Standard.Steve Gordon walks through performance optimizations.?? AnnouncementsThere’s a new Learn module for deploying a cloud-native ASP.NET microservice with GitHub Actions.Mark Downie talks about disassembly improvements for optimized managed debugging.Microsoft Edge announces source order viewer in their DevTools.Tara Overfield provides September cumulative updates for the .NET Framework.?? Community and eventsMicrosoft Ignite occurs this Tuesday through Thursday.The .NET Docs Show talks about the dot.net site with Maíra Wenzel.Three .NET community standups this week .NET Tooling finds latent bugs in .NET 5, Entity Framework talks EF Core 5 migrations, and ASP.NET discusses new features for .NET API developers.?? ASP .NET / BlazorShaun Curtis launches a series on building a database application in Blazor.Patrick Smacchia walks through the architecture of a C# game rendered with Blazor, Xamarin, UWP, WPF, and Winforms.David Ramel writes about increased Blazor performance in .NET 5 RC1.Rick Strahl warns about missing await calls for async code in ASP.NET Code middleware.Dominique St-Amand secures an ASP.NET Core Web API with an API key.Vladimir Pecanac discusses how to secure sensitive data locally with ASP.NET Core.David Grace explores why you app might not be working in IIS.?? .NET CoreKay Ewbank discusses the latent bug discovery feature coming with .NET 5.Michal Bialecki executes raw SQL with EF 5.Fredrik Rudberg serves images stored in a database through static URLs using .NET Core 3.1.Shawn Wildermuth talks about hosting Vue in .NET Core.? The cloudVladimir Pecanac configures the Azure Key Vault in ASP.NET Core.Richard Seroter compares the CLI experience between Azure, AWS, and GCP.Jon Gallant walks though the September updates to the Azure SDKs.Christopher Scott introduces the new Azure Tables client libraries.Daniel Krzyczkowski extracts Excel file content with Azure Logic Apps and Azure Functions.Kevin Griffin touts the great performance for Azure Static Web Apps and Azure Functions.Matt Small finds a gotcha you can’t use an Azure Key Vault firewall if you’re in a situation where you’re using App Gateway along with a Key Vault certificate for SSL termination.Gunnar Peipman hosts applications on Azure B-series virtual machines.?? C#Jeremy Clark shows how to see all the exceptions when calling “await Task.WhenAll.”.Jerome Laban uses MSBuild items and properties in C# 9 source generators.?? F#A nice rundown of 10 ways to try F# in the browser.Daniel Bykat talks about the PORK framework and its use with F#.Alican Demirtas discusses string interpolation in F#.Paul Biggar talks about his async adventures.?? ToolsDerek Comartin does a review of MediatR.Tom Deseyn uses OpenAPI with .NET Core.John Juback builds cross-platform desktop apps with Electron.NET.Andrew Lock continues his k8s series by deploying applications with Helm.You can now debug Linux core dumps on the Windows Subsystem for Linux (WSL) or a remote Linux system directly from Visual Studio.Adam Storr uses Project Tye to run .NET worker services.?? XamarinJoe Meyer wires up a fullscreen video background.Khalid Abuhakmeh animates a mic drop.Denys Fiediaiev uses MvvmCross to log with Xamarin.?? PodcastsThe .NET Rocks podcast talks about ML with Zoiner Tejada.Software Engineering Radio talks with Philip Kiely about writing for software developers.The Merge Conflict podcast discusses the new Half type.The Coding Blocks podcast asks is Kubernetes programming?The Azure DevOps Podcast talks with Steve Sanderson about Blazor.?? VideosThe ON .NET Show talks about Steeltoe configuration.Azure Friday talks about Azure landing zones.Scott Hanselman gives us a primer on the cloud.The ASP.NET Monsters send dates from JavaScript to .NET.


Trying out MongoDB with EF Core using Testcontainers
Trying out MongoDB with EF Core using Testcontaine ...

Helping developers use both relational and non-relational databases effectively was one of the original tenets of EF Core. To this end, there has been an EF Core database provider for Azure Cosmos DB document databases for many years now. Recently, the EF Core team has been collaborating with engineers from MongoDB to bring support for MongoDB to EF Core. The initial result of this collaboration is the first preview release of the MongoDB provider for EF Core. In this post, we will try out the MongoDB provider for EF Core by using it to Map a C# object model to documents in a MongoDB database Use EF to save some documents to the database Write LINQ queries to retrieve documents from the database Make changes to a document and use EF’s change tracking to update the document The code shown in this post can be found on GitHub. Testcontainers It’s very easy to get a MongoDB database in the cloud that you can use to try things out. However, Testcontainers is another way to test code with different database systems which is particularly suited to Running automated tests against the database Creating standalone reproductions when reporting issues Trying out new things with minimal setup Testcontainers are distributed as NuGet packages that take care of running a container containing a configured ready-to-use database system. The containers use Docker or a Docker-alternative to run, so this may need to be installed on your machine if you don’t already have it. See Welcome to Testcontainers for .NET! for more details. Other than starting Docker, you don’t need to do anything else except import the NuGet package. The C# project We’ll use a simple console application to try out MongoDB with EF Core. This project needs two package references MongoDB.EntityFrameworkCore to install the EF Core provider. This package also transitives installs the common EF Core packages and the MongoDB.Driver package which is used by the EF Provider to access the MongoDB database. Testcontainers.MongoDb to install the pre-defined Testcontainer for MongoDB. The full csproj file looks like this <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net7.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <RootNamespace /> </PropertyGroup> <ItemGroup> <PackageReference Include="Testcontainers.MongoDB" Version="3.5.0" /> <PackageReference Include="MongoDB.EntityFrameworkCore" Version="7.0.0-preview.1" /> </ItemGroup> </Project> Remember, the full project is available to download from GitHUb. The object model We’ll map a simple object model of customers and their addresses public class Customer { public Guid Id { get; set; } public required string Name { get; set; } public required Species Species { get; set; } public required ContactInfo ContactInfo { get; set; } } public class ContactInfo { public required Address ShippingAddress { get; set; } public Address? BillingAddress { get; set; } public required PhoneNumbers Phones { get; set; } } public class PhoneNumbers { public PhoneNumber? HomePhone { get; set; } public PhoneNumber? WorkPhone { get; set; } public PhoneNumber? MobilePhone { get; set; } } public class PhoneNumber { public required int CountryCode { get; set; } public required string Number { get; set; } } public class Address { public required string Line1 { get; set; } public string? Line2 { get; set; } public string? Line3 { get; set; } public required string City { get; set; } public required string Country { get; set; } public required string PostalCode { get; set; } } public enum Species { Human, Dog, Cat } Since MongoDB works with documents, we’re going to map this model to a top level Customer document, with the addresses and phone numbers embedded in this document. We’ll see how to do this in the next section. Creating the EF model EF works by building a model of the mapped CLR types, such as those for Customer, etc. in the previous section. This model defines the relationships between types in the model, as well as how each type maps to the database. Luckily there is not much to do here, since EF uses a set of model building conventions that generate a model based on input from both the model types and the database provider. This means that for relational databases, each type gets mapped to a different table by convention. For document databases like Azure CosmosDB and now MongoDB, only the top-level type (Customer in our example) is mapped to its own document. Other types referenced from the top-level types are, by-convention, included in the main document. This means that the only thing EF needs to know to build a model is the top-level type, and that the MongoDB provider should be used. We do this by defining a type that extends from DbContext. For example public class CustomersContext DbContext { private readonly MongoClient _client; public CustomersContext(MongoClient client) { _client = client; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) => optionsBuilder.UseMongoDB(_client, "efsample"); public DbSet<Customer> Customers => Set<Customer>(); } In this DbContext class UseMongoDB is called, passing in the client driver and the database name. This tells EF Core to use the MongoDB provider when building the model and accessing the database. A DbSet<Customer> property that defines the top-level type for which documents should be modeled. We’ll see later how to create the MongoClient instance and use the DbContext. When we do, examining the model DebugView shows this Model EntityType ContactInfo Owned Properties CustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow Navigations BillingAddress (Address) ToDependent ContactInfo.BillingAddress#Address (Address) Phones (PhoneNumbers) ToDependent PhoneNumbers ShippingAddress (Address) ToDependent ContactInfo.ShippingAddress#Address (Address) Keys CustomerId PK Foreign keys ContactInfo {'CustomerId'} -> Customer {'Id'} Unique Ownership ToDependent ContactInfo Cascade EntityType ContactInfo.BillingAddress#Address (Address) CLR Type Address Owned Properties ContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow City (string) Required Country (string) Required Line1 (string) Required Line2 (string) Line3 (string) PostalCode (string) Required Keys ContactInfoCustomerId PK Foreign keys ContactInfo.BillingAddress#Address (Address) {'ContactInfoCustomerId'} -> ContactInfo {'CustomerId'} Unique Ownership ToDependent BillingAddress Cascade EntityType ContactInfo.ShippingAddress#Address (Address) CLR Type Address Owned Properties ContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow City (string) Required Country (string) Required Line1 (string) Required Line2 (string) Line3 (string) PostalCode (string) Required Keys ContactInfoCustomerId PK Foreign keys ContactInfo.ShippingAddress#Address (Address) {'ContactInfoCustomerId'} -> ContactInfo {'CustomerId'} Unique Ownership ToDependent ShippingAddress Cascade EntityType Customer Properties Id (Guid) Required PK AfterSaveThrow ValueGenerated.OnAdd Name (string) Required Species (Species) Required Navigations ContactInfo (ContactInfo) ToDependent ContactInfo Keys Id PK EntityType PhoneNumbers Owned Properties ContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow Navigations HomePhone (PhoneNumber) ToDependent PhoneNumbers.HomePhone#PhoneNumber (PhoneNumber) MobilePhone (PhoneNumber) ToDependent PhoneNumbers.MobilePhone#PhoneNumber (PhoneNumber) WorkPhone (PhoneNumber) ToDependent PhoneNumbers.WorkPhone#PhoneNumber (PhoneNumber) Keys ContactInfoCustomerId PK Foreign keys PhoneNumbers {'ContactInfoCustomerId'} -> ContactInfo {'CustomerId'} Unique Ownership ToDependent Phones Cascade EntityType PhoneNumbers.HomePhone#PhoneNumber (PhoneNumber) CLR Type PhoneNumber Owned Properties PhoneNumbersContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow CountryCode (int) Required Number (string) Required Keys PhoneNumbersContactInfoCustomerId PK Foreign keys PhoneNumbers.HomePhone#PhoneNumber (PhoneNumber) {'PhoneNumbersContactInfoCustomerId'} -> PhoneNumbers {'ContactInfoCustomerId'} Unique Ownership ToDependent HomePhone Cascade EntityType PhoneNumbers.MobilePhone#PhoneNumber (PhoneNumber) CLR Type PhoneNumber Owned Properties PhoneNumbersContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow CountryCode (int) Required Number (string) Required Keys PhoneNumbersContactInfoCustomerId PK Foreign keys PhoneNumbers.MobilePhone#PhoneNumber (PhoneNumber) {'PhoneNumbersContactInfoCustomerId'} -> PhoneNumbers {'ContactInfoCustomerId'} Unique Ownership ToDependent MobilePhone Cascade EntityType PhoneNumbers.WorkPhone#PhoneNumber (PhoneNumber) CLR Type PhoneNumber Owned Properties PhoneNumbersContactInfoCustomerId (no field, Guid) Shadow Required PK FK AfterSaveThrow CountryCode (int) Required Number (string) Required Keys PhoneNumbersContactInfoCustomerId PK Foreign keys PhoneNumbers.WorkPhone#PhoneNumber (PhoneNumber) {'PhoneNumbersContactInfoCustomerId'} -> PhoneNumbers {'ContactInfoCustomerId'} Unique Ownership ToDependent WorkPhone Cascade Looking at this model, it can be seen that EF created owned entity types for the ContactInfo, Address, PhoneNumber and PhoneNumbers types, even though only the Customer type was referenced directly from the DbContext. These other types were discovered and configured by the model-building conventions. Create the MongoDB test container We now have a model and a DbContext. Next we need an actual MongoDB database, and this is where Testcontainers come in. There are Testcontainers available for many different types of database, and they all work in a very similar way. That is, a container is created using the appropriate DbBuilder, and then that container is started. For example await using var mongoContainer = new MongoDbBuilder() .WithImage("mongo6.0") .Build(); await mongoContainer.StartAsync(); And that’s it! We now have a configured, clean MongoDB instance running locally with which we can do what we wish, before just throwing it away. Save data to MongoDB Let’s use EF Core to write some data to the MongoDB database. To do this, we’ll need to create a DbContext instance, and for this we need a MongoClient instance from the underlying MongoDB driver. Often, in a real app, the MongoClient instance and the DbContext instance will be obtained using dependency injection. For the sake of simplicity, we’ll just new them up here var mongoClient = new MongoClient(mongoContainer.GetConnectionString()); await using (var context = new CustomersContext(mongoClient)) { // ... } Notice that the Testcontainer instance provides the connection string we need to connect to our MongoDB test database. To save a new Customer document, we’ll use Add to start tracking the document, and then call SaveChangesAsync to insert it into the database. await using (var context = new CustomersContext(mongoClient)) { var customer = new Customer { Name = "Willow", Species = Species.Dog, ContactInfo = new() { ShippingAddress = new() { Line1 = "Barking Gate", Line2 = "Chalk Road", City = "Walpole St Peter", Country = "UK", PostalCode = "PE14 7QQ" }, BillingAddress = new() { Line1 = "15a Main St", City = "Ailsworth", Country = "UK", PostalCode = "PE5 7AF" }, Phones = new() { HomePhone = new() { CountryCode = 44, Number = "7877 555 555" }, MobilePhone = new() { CountryCode = 1, Number = "(555) 2345-678" }, WorkPhone = new() { CountryCode = 1, Number = "(555) 2345-678" } } } }; context.Add(customer); await context.SaveChangesAsync(); } If we look at the JSON (actually, BSON, which is a more efficient binary representation for JSON documents) document created in the database, we can see it contains nested documents for all the contact information. This is different from what EF Core would do for a relational database, where each type would have been mapped to its own top-level table. { "_id" "CSUUID(\"9a97fd67-515f-4586-a024-cf82336fc64f\")", "Name" "Willow", "Species" 1, "ContactInfo" { "BillingAddress" { "City" "Ailsworth", "Country" "UK", "Line1" "15a Main St", "Line2" null, "Line3" null, "PostalCode" "PE5 7AF" }, "Phones" { "HomePhone" { "CountryCode" 44, "Number" "7877 555 555" }, "MobilePhone" { "CountryCode" 1, "Number" "(555) 2345-678" }, "WorkPhone" { "CountryCode" 1, "Number" "(555) 2345-678" } }, "ShippingAddress" { "City" "Walpole St Peter", "Country" "UK", "Line1" "Barking Gate", "Line2" "Chalk Road", "Line3" null, "PostalCode" "PE14 7QQ" } } } Using LINQ queries EF Core supports LINQ for querying data. For example, to query a single customer using (var context = new CustomersContext(mongoClient)) { var customer = await context.Customers.SingleAsync(c => c.Name == "Willow"); var address = customer.ContactInfo.ShippingAddress; var mobile = customer.ContactInfo.Phones.MobilePhone; Console.WriteLine($"{customer.Id} {customer.Name}"); Console.WriteLine($" Shipping to {address.City}, {address.Country} (+{mobile.CountryCode} {mobile.Number})"); } Running this code results in the following output 336d4936-d048-469e-84c8-d5ebc17754ff Willow Shipping to Walpole St Peter, UK (+1 (555) 2345-678) Notice that the query pulled back the entire document, not just the Customer object, so we are able to access and print out the customer’s contact info without going back to the database. Other LINQ operators can be used to perform filtering, etc. For example, to bring back all customers where the Species is Dog var customers = await context.Customers .Where(e => e.Species == Species.Dog) .ToListAsync(); Updating a document By default, EF tracks the object graphs returned from queries. Then, when SaveChanges or SaveChangesAsync is called, EF detects any changes that have been made to the document and sends an update to MongoDB to update that document. For example using (var context = new CustomersContext(mongoClient)) { var baxter = (await context.Customers.FindAsync(baxterId))!; baxter.ContactInfo.ShippingAddress = new() { Line1 = "Via Giovanni Miani", City = "Rome", Country = "IT", PostalCode = "00154" }; await context.SaveChangesAsync(); } In this case, we’re using FindAsync to query a customer by primary key–a LINQ query would work just as well. After that, we change the shipping address to Rome, and call SaveChangesAsync. EF detects that only the shipping address for a single document has been changed, and so sends a partial update to patch the updated address into the document stored in the MongoDB database. Going forward So far, the MongoDB provider for EF Core is only in its first preview. Full CRUD (creating, reading, updating, and deleting documents) is supported by this preview, but there are some limitations. See the readme on GitHub for more information, and for places to ask questions and file bugs. Learn more To learn more about EF Core and MongoDB See the EF Core documentation to learn more about using EF Core to access all kinds of databases. See the MongoDB documentation to learn more about using MongoDB from any platform. Watch Introducing the MongoDB provider for EF Core on the .NET Data Community Standup. Watch the upcoming Announcing MongoDB Provider for Entity Framework Core on the MongoDB livestream. Summary We used Testcontainers to try out the first preview release of the MongoDB provider for EF Core. Testcontainers allowed us to test MongoDB with very minimal setup, and we were able to create, query, and update documents in the MongoDB database using EF Core. The post Trying out MongoDB with EF Core using Testcontainers appeared first on .NET Blog.


Login to Continue, We will bring you back to this content 0



For peering opportunity Autonomouse System Number: AS401345 Custom Software Development at ErnesTech Email Address[email protected]