The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
This is NOT a programming question. Just something you might want to be aware of.
So I migrated my project and fixed that various things in Startup that broke. Stupid things, like apparent env.IsDevelopment() doesn't exist anymore, and IHostingEnvironment has to be changed to IWebHostEnvironment or something like that, and app.UseMvc(); is wrong now and you have to use:
// endpoints.MapRazorPages(); //Routes for pages
endpoints.MapControllers(); //Routes for my API controllers
instead, and I don't have Razor pages anyways.
And I do wish that the whole NuGet package manager / Visual Studio would figure out that when I change the target framework, yes, please go and get the appropriate packages for the new framework, and now I need to specifically install the System.Data.SqlClient framework? And we're no longer using Microsoft.AspNetCore.App but instead need Microsoft.EntityFrameworkCore and Microsoft.EntityFrameworkCore.SqlServer?
Sigh. Fine, relatively easy fixes, and all that was an aside, relatively easy to fix, but annoying.
So, once I got it to compile, fired it up and tried a very simple API call that returns an access token.
Now, in .NET Core 2.2, the response at the client contains the key "access_token"
In .NET Core 3.1, the response at the client contains the key "token"
has to be changed to:
On the C# side, the return from the API call is the same:
And that breaking change isn't discovered until runtime! (Like the serialization issue when the client tries to parse out the token.)
So how many places in the code base break at runtime and you won't know until you've executed all the possible code path queries?
Now, while I had tried .NET Core 3.1 because there were posts about multi-part content being broken in .NET 2.2 and it was fixed in .NET Core 3.0, it turns out that that wasn't the reason my file uploads weren't working.
But that's a whole other story. Involving pretty much 8 hours of try this, google that, and getting so pissed off (which is rare for me) that I really wanted to just go on a rampage. Because, at the end of the day, it's quite simple, but nobody actually tells you the important things you need to make sure you do correctly. That will become an article, so that somewhere in the cloud there will be a concise example explaining why and not just glossing over the critical, key, pertinent, essential, vital niggly little things you need to do to post FormData up to a .NET Core application. Grrr.
Sounds like they did it on purpose because they couldn't support the old api going from 2.x to 3.x. Force you to update your code if you update your libs.
The one I remember (between "libs") was in one case you can use a single char for a string split separator, while the other version will (still) insist on an array. You think it's neat and change your code, then find your lib is no longer compatible with your other libs. I also ran into problems thinking all libs should serialize / compress the same ... not. They may actually read and write but the file sizes will be off.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
I can't see how any version of Entity Framework would be able to translate a query using your computed property to a SQL query. It's quite likely that EF Core 2.x was loading the entire table into memory and evaluating the condition as a LINQ-to-objects query instead. One of the breaking changes in 3.x is that it won't do that any more.
Before 3.0, when EF Core couldn't convert an expression that was part of a query to either SQL or a parameter, it automatically evaluated the expression on the client. By default, client evaluation of potentially expensive expressions only triggered a warning.
Starting with 3.0, EF Core only allows expressions in the top-level projection (the last Select() call in the query) to be evaluated on the client. When expressions in any other part of the query can't be converted to either SQL or a parameter, an exception is thrown.
What I have noticed is that the code runs much faster if I set the font in my IDE to DokChampa Regular, but you've really got to avoid handwriting fonts. Some people swear by Comic Sans, but a remarkable percentage of people swear at it.
If you want to look like a real hero, at work, compile the code in something like Algerian, so it runs really slowly, then recompile it in DokChampa just before a customer demo, and pretend to have fixed loads of other people's bugs.
I wanna be a eunuchs developer! Pass me a bread knife!
So I met a road side accident like a week ago and since then been ignoring the obvious signs of injury and trying to continue with my daily life. Now that I couldn't get myself to walk properly, I had no other choice but to visit the doctor. Apart from various muscle ruptures, turns out I have broken toe fingers.
I've been strictly suggested to rest since I've already made my injuries worse by ignoring them. But that's the thing, I had an upcoming squash tournament to play by the end of this month which I won't be able to play now and that's making me real sad.
But ... even if you had gone to the quack straight away, you still wouldn't be fixed by the end of next month, let alone this!
Accidents always happen at the least convenient time, that's Einstein's third law of relatives.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!