- Added the project EFCore.FSharp.FunctionalTests
- Created a fixture for the Northwind database
- Implemented a sample test analogous to the Visual Basic tests
Fixes#14572
* Our previous config used to run multiple TFMs as part of a single
benchmark run. Removed this - a single run is now on a single TFM.
It is still possible run older TFMs via the commandline.
* Running different versions of EF Core is now possible via build
configs, rather than different projects. This simplifies things.
* Code common to the two EF Core projects - and to the EF6 project -
is now in Shared.EFCore and Shared respectively.
* Integrated the new benchmark projects into EFCore.sln and removed the
older ones.
* Other various cleanup and update tasks
* Rename EnableRichDataErrorHandling to EnableDetailedErrors
* Rename TagWith to WithTag (controversial!)
* Make FinalizeModel return the finalized IModel
* Rename DeepComparer to StructuralCompaper
* Move CancellationTokenParameter to internal type
* Rename GenerateLiteralExpression to GenerateCodeLiteral
* Rename Cosmos.Sql to Cosmos
* Remove URI overload in UseCosmos
* Rename SqlQuerySpec to CosmosSqlQuery and make public
* Rename Cosmos annotation CollectionName to ContainerName
* Rename IndexExtras to IndexOptions
* Implement IPrintable on DiscriminatorPredicateExpression explicitly
* Rename SingleLineComment to SingleLineCommentToken
* Refactor RelationalGeometryTypeMapping.AsText
* Rename AddCustomConversion to CustomizeDataReaderExpression
* Move IsSpatialiteType to internal type
* Use NetTopologySuite rather than NTS
* Rename SetInclude "value" parameter to "properties"
* Make SqlServerSpatialReader real internal
There's still a lot to do (e.g. support mapping to GEOGRAPHY), bit it's at a point where we can start gathering feedback while we continue iterating on it.
To get started, install the `Microsoft.EntityFrameworkCore.SqlServer.NetTopologySuite` package, call `.UseSqlServer(..., x => x.UseNetTopologySuite())`, and add `Geometry` properties to your model.
Part of #1100
A new EF Core Analyzer that detects some common potential SQL injection patterns. Currently looks at FromSql, ExecuteSqlCommand/Async and DbCommand.CommandText APIs.
Works by inspecting the SQL argument expression (either passed directly, or by walking up any local variable chain), and pattern matching the expression for:
- Calls to String.Format, Concat, '+', Insert, Replace, Join involving any local variable or parameter data.
- Uses of interpolated strings that use local variable or parameter data in places that don't end up resolving to an overload that accepts FormattableString.
See unit tests for examples of patterns.
Part of #10509, #3797.
This change adds a new package--Microsoft.EntityFrameworkCore.Proxies--that contains a lazy-loading proxy implementation making use of the EF lazy-loading infrastructure and the Castle.Core proxies package. Current plan is for this to ship on NuGet as an optional package for use with EF.
To use in a normal application, just add a call to `UseLazyLoadingProxies()` on the DbContext options builder.
There are also `context.CreateProxy()` methods for creating stand-alone proxy instances if needed.
Entity types must be public and navigation properties must be virtual. Also, the entity type and constructor must be "visible" to the castle proxies assembly, which usually means public, but could mean internal if "InternalsVisibleTo" is used. Exceptions are thrown if these requirements are not met--you don't just not get a proxy like in EF6.
Note that this is an optional package for EF that we chose to create because the infrastructure in place made it easy to do so. It does not preclude a Roslyn-based rewriting solution in the future.
Remove SqlServer.Design.Tests
Introduce IAnnotationRenderer interface for provider writers to provide us how to interpret annotations
Flow annotations from DatabaseModel to IModel so that provider can generate provider specific fluent API
Remove special processing inside of SqlServerScaffoldingFactory. All processing should happen while generating database
- Sets up the product/test projects and enables simple AI dependency forwarding of EF generated ADO events including EF correlation ids.
TBD:
- DbContext correlation? NB: ASP.NET AI integration already correlates everything at the Request level.
- Forward other events? NB. ASP.NET AI integration already forwards all logging events as AI Events and all errors as AI Errors, so it is unclear what we should do here.