Does Asp.NET identity still use a Guid for primary key? I remember it being hell trying to convert to int a few years ago which left a sour taste.
[1] https://docs.microsoft.com/en-us/aspnet/core/security/authen...
131–140 of 466 posts
Does Asp.NET identity still use a Guid for primary key? I remember it being hell trying to convert to int a few years ago which left a sour taste.
[1] https://docs.microsoft.com/en-us/aspnet/core/security/authen...
is this an in-place update to the netcore3.1 runtime or does it install side by side for net5.0? just want to know what kind of risk it is to install. i got bit by the netfx48 in place update.
Side-by-side. It’s effectively .Net Core 4.0, but they removed the “core” and versioned it 5.0 to make it more obvious that it supersedes and obsoletes .Net Framework 4.8 which lots of organizations are still clinging to.
the highlights are great. 2 lowlights: - HttpClient/WebRequest ReadWriteTimeout is silently ignored which can result in infinitely hung sockets when doing synchronous network i/o - System.Speech is unsupported
Refusing to support System.Speech is why my project will remain locked to .NET Framework. Apparently the Microsoft Speech team is part of Azure now, and has decided nobody needs local speech synthesis that doesn't require a subscription to a cloud service.
Earlier quoted context omitted.
It won't be. .NET Framework is an embedded component of Windows. .NET Core is something apps have to package along with them. (Due to this, .NET Core apps are larger than .NET Framework apps, but tend to have less compatibility issues in theory, since they bring everything they need with them.)
Are you sure it will not be distributed with Windows? Is 4.8 the last version being distributed with Windows, requiring all future .NET framework versions to be packaged with the apps?
Visual Studio 2019 running as x86 32bits application can't see the local machine as a target for aarch64 applications. When I asked microsoft, the response was to use a x86-64 machine to develop on the same LAN as the aarch64 machine and use remote debugging. So you need two machines to ship a desktop application.
This is bad, and part of the reason there are so few app running natively on the Surface Pro X.
Earlier quoted context omitted.
You can do that just with different config files or env vars too. No need to complicate code for stuff that can be done easily differently as well.
And then you realize that it's 2020 and you don't want configuration files, you want environment variables. Or, now that you've hardstuck yourself on environment variables and built all this stuff around them to set and re-set them properly between tests (now running either in multi-process, which good luck in most environments, or are just running in serial ), you're using k8s and the voluming of secrets rather than…
Personally, I would rephrase that as, "DI is a pattern that is designed to mitigate certain kinds of complexity when done correctly."
That leaves room for two ways in which it can backfire. Doing it wrong, like you say, but also doing it in situations where you don't actually have one of the problems it's trying to solve. Cost/benefit ratios always get out of whack when there's no benefit to offset the cost.
Earlier quoted context omitted.
Side-by-side. It’s effectively .Net Core 4.0, but they removed the “core” and versioned it 5.0 to make it more obvious that it supersedes and obsoletes .Net Framework 4.8 which lots of organizations are still clinging to.
to be clear- you are saying it is side by side with netcore31?
I’ve been hot-swapping 3.1 and 5.0-rc2 for projects, preparing for the final 5.0 release.
With Linux support AOT compliation and other goodies I wonder how many people will prefer writing backends in .NET over Java.
I think that Java ecosystem is more diverse. There are multiple JDK implementations. There are a lot of OpenJDK builds from different vendors, including paid support options. There is an extremely mature library and tooling ecosystem. While I don't think that JVM is superior to .NET VM, it's not inferior either. .NET supports value types while JVM support some very advanced garbage collectors. And, of course, JVM dev…
.NET could get a huge boost if there was an ability to use Java libraries. There was KVM.NET but that looks pretty dead.
People who think this is actually cross-platform need to consider these points: * Debian can't package F# because it is built using MSBuild, and MSBuild is built using MSBuild. How can it be Microsoft doesn't have the resources to get it into a major distribution? * Microsoft won't commit to maintaining any cross-platform GUI libraries. You will be relying on some random community project. Compare this with e.g. Pyth…
Since dotnet core became a thing, I've been building cross-platform apps with great success - mostly Windows and Linux, occasionally MacOS too, and mostly x64, but also ARM too.
So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…
Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?
Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.