Thank you .Net Core for finally moving from XML to JSON. As a json lover the xml within .Net always bothered me. But the config is now stored in json, which makes it easier to maintain, and you need to map it to an actual class, which enables you to make use of the typing in C#. Now you are able to take advantage of intellisense even with the web.config, which is now called appsettings in .Net Core.
Now the appSettings look like
Create a cs class that correspond to the appsettings variables that you want to use in…
The controllers are easy to migrate but I’ll document it anyways just to clear out the unknowns.
This is how I used to return HttpResponseMessage in .Net
And now this is how it’s changed to
return new HttpResponseMessage(HttpStatusCode.OK);
However, the statement doesn’t contain a parameter to return a json response, so it’s used to return pure http status code. To include a json response, use IActionResult
[Authorize(Roles = "SomeRole")]
public IActionResult Get()
return new OkObjectResult(response);
// or return Ok(response);
You can also use BadRequest to return a 400 instead of creating a new HttpResponseMessage
So back in the days of .Net 4.7, I had these resx files that I created to store the translations for different languages and .Net was able to do the magic on its own. With .Net Core, it’s quite similar and changes are minimal.
var supportedCultures = new List<CultureInfo>
new RequestCulture(culture: "en-US", uiCulture: "en-US");
options.SupportedCultures = supportedCultures;
options.SupportedUICultures = supportedCultures;
Ensure that the CultureInfo(“languageName”) matches the naming of…
In .Net I used ClaimsPrincipalPermission and ClaimsAuthorizationManager with the help of Autofac.Owin and Owin for authentication and authorization. The Owin framework helped generate the oAuth token for me and it integrated perfectly with the claims manager. However the same setup no long works in .Net 4.7 and I have decided to move to a more framework independent approach — generating and verifying the JWT token myself for authentication and make use of the Authorize attribute for authorization.
First add the below configuration in startup.cs’ Configure method
And the below in ConfigureServices method
Whenever you define one to many or many to many relationships, EF core internally needs to handle what to do when the relationship disappears. For example a student was enrolled in many course works but what happens when the student is deleted, what happens to the Foreign Key that the courses use to link to the student? I personally prefer the FK to go null (as it should be nullabe). For that you can configure the DeleteBehavior for relationships as below. And of course if you look up DeleteBehavior you can find many other possible configurations.
foreach (var relationship in…
The application that I worked on has two languages configured — English and Chinese (Traditional and Simplified).
I was able to use the VB library for .Net 4.7 to do the translation.
var simplified = Strings.StrConv(name, VbStrConv.SimplifiedChinese, 2052).ToLower();
var traditional = Strings.StrConv(name, VbStrConv.TraditionalChinese, 2052).ToLower();
And no that is no longer available in .Net Core.
I spent quite some time looking for a nuget package that would work and after tons of confusion, I found this
The above package will do the work!
public string ToSimplified(string value)
return ChineseConverter.Convert(value, ChineseConversionDirection.TraditionalToSimplified);
}public string ToTraditional(string value)
With .Net 4.7 I used to log my http request and response conditionally through the help of owin. However with .Net Core, they have a set of awesome middlewares that you can now override and make use of. All you need to do is create a middleware class and register it in the Configure method within the startup.cs
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
app.UseCors(builder => builder
.AllowAnyHeader()); app.UseHttpsRedirection(); app.UseMiddleware<HttpHandlerMiddleware>(); app.UseDefaultFiles();
So my middleware code looks like this:
The above code is constructed from the post below. …
This is what the code looked like in .Net. I used to quite liked fluent API and favored it over annotations, but after the migration I think annotation would save a lot of time if you had that in your old code base.
This is what it looks like in .Net Core. I believe the code looks much cleaner and easier to understand when annotations are used as much as possible. But if you still prefer to use fluent API for the configuration, you can refer to the one to many foreign key shown below.
And you can…
If you’re getting the below error then you’re probably at the right place for a solution.
A second operation started on this context before a previous operation completed
So back in the old days when I configured the DI for the DbContext I could do the following:
What the above means is whenever a http request comes in, a new instance will be instantiated. But according to the official Autofac documentation, things are now different with .Net Core
there’s no special “request level scope” anymore. …
In case you don’t know what soft delete is, it’s the strategy of adding a IsDeleted flag in all your tables. Instead of actually deleting the row, you’ll mark the IsDeleted flag as true. But this brings forth a question, whenever I query someone from the database, do I want to include the condition where(x => x.IsDeleted == false) in every Linq that I write? Of course not, this is why this soft delete handling is implemented so that whenever I query these records EF can handle these soft deleted records for me.
The way I impelmented soft delete in…
Just another developer who's into lazy tools that can make my life easier, and hopefully yours too.