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.
I replaced the SSD with a 2TB drive, to save having to carry external drives and/or have everything on bloody annoying memory sticks.
I don't really give a damn if a program loads a tenth of a second faster, or if windows boots in three seconds less. Once stuff is loaded, memory is faster than SSD (unless it isn't any more; I don't read all the tech press), so I just max out the memory on all my machines.
I wanna be a eunuchs developer! Pass me a bread knife!
I probably won't though unless prices fall a lot in the next 2 years (or QLC sweeps prosumer drives and a huge SLC cache is needed to keep performance up); since my 6 year old 1tb SSD (best $500 upgrade I've ever made) is still only ~56% full.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
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!