.NET Framework 4.6.2
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
- Allow paths that are greater than 260 character (MAX_PATH).
- Enable extended path syntax and file namespaces (\\?\, \\.\).
- X509 Certificates Now Support FIPS 186-3 Digital Signature Algorithm (Keys > 1024 bits)
- SignedXml Support for SHA-2 Hashing
- Groundwork for more informative NullRefrence Exceptions
- ClickOnce TLS 1.1, 1.2 and client certificate support
- ASP.NET DataAnnotation Localization
- System.Data.SqlClient Always Encrypted Modus
- WCF removed support for SSL 3
- Per monitor DPI support for WPF
- Show/Hide soft keyboard from WPF code
https://gist.githubusercontent.com/staceyhaffner/8bad9c0895b...
There's some nice small Async enhancements in this patch too, such as improvements to Output Caching (which isn't available in ASP.NET Core, although Response Caching to set headers for proxies is).
It's good to see MS are still updating .NET Framework as I think .NET Core needs a bit more time before it's suitable for enterprise style applications.
Patches are coming soon though: https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-...
edit:
More info on Response Caching: https://docs.asp.net/en/latest/performance/caching/response....
Shameless plug: I've written about Response Caching in my book on ASP.NET Core (https://unop.uk/book).
That's surprising.
Years ago I thought people working in mono on Linux were just asking for trouble. Now it seems genuinely feasible to be running .Net on a non-Windows platform.
The short is: if you're going to do Mono, make sure that you're always having at least one person on the team doing Mono, otherwise there's a moderate chance that you'll lose the ability to run on Mono.
Also, stay away from entity framework. Some people might disagree, but we had problems with it and I hate that framework.
Every large team I've seen use it (EF) ends up with slow horrible queries generated that DBAs see hitting the database thinking WTF?
If you're doing web/api services, then mono/.net core are serviceable. Though I would recommend that you have CI/CD setup to use linux/mono if you are going to target that platform... for the most part if it works in linux its' going to work in windows, not so much the other way around.
Take this with a grain of salt, as I've been mostly node.js for a couple years now, though the progress with .Net core and VS Code have my interest.
However making things from scratch works totally awesome.
But then Mozilla started releasing versions every couple of months
Now if Sun still owned Java that would be a fair assessment. They couldn't figure out what to do with the language.
The new dotNetCoreFramework 1.0 just got released. It wouldn't sense to add mayor new features to dotNetFramework 4.6x, legacy is written on the wall.
dotNetFramework 1x from 2002 to 2005 is unsupported for many years and APIs and code ate incompatible with dotNetFramework 2+. Basically dotNetFramework rebooted with v2 and got really popular starting in 2005. All mayor features were available since v3. Though then the development stagnated and little new outstanding new featured were included in newer releases. Plus several APIs turned out to vanish pretty quickly and are dragged along as legacy like WinForms, Silverlight, WPF, Managed C++, ManagedDirectX and its next incompatible iteration, SharePoint APIs, WinFS, etc. Plus the incompatible different API WinRT aka WinRunTime aka UniversalRuntime with various incompatibilities in WinPhone8, Win8 & 10.
So Microsoft now has to maintain Win32 API and its subsystem (the reason why people are still using Windows, dating back to 1995 and source code compatible to Win16 API dating back to Win1 (1985) and Win16 is still supported on 32bit OS (technically it could also run on 64bit, if MS would want that). And UniversalRuntime (former WinRT) based on Win32 subsystem and still a lot less featurefull and little developer support and little apps - MS wants to push it, many hate it and almost all Windows applications continue as Win32 x84/64 applications even most games (Steam is big, the hate on WinStore is rightful). And dotNetFramework 2x+ the legacy big soup infested with dream buildings full of XML. And now dotNetCoreFramework in v1 still pretty rough and unfinished and the usual v1 were you want to wait for service pack 1 or v2.
In comparison Java is source compatible to at least v1.4, but in reality often back to Java 1.1 or 1.2. Sure there are some crufty APIs that got a better alternative that is recommend and several third party frameworks come and are now enterprise/legacy tools and newer things are now popular. While Java stagnated a bit with Oracle at times, it's still a nicer experience than the quickly vanishing and legacy API that Microsoft releases out en mass. And also Google is supporting Java on Android as its main API.
Specially if they rely on APIs that did break, like JDBC interfaces.
Also Android Java isn't 100% Java as Google cherry picks APIs, which with the increase of Java 8's adoption is increasing the effort to write portable libraries that compile against Java and Android Java.
Also Android Java runtimes don't understand the bytecodes introduced in Java 7 and 8. So you cannot use libraries that make use of them.
This will only get worse with Java 9 modularity and with the value types, reiffed generics and new FFI planned for Java 10.
But we'll end up with one of the following suboptimal solutions: - half-assedly backported Java 8 features (with buggy bytecode transformers for libraries that are included in binary form) - either Dart, Go or (why not go full retard) JS
Then the usual answer to standard Java support is "What features matter to you? Get in touch with us".
Is it so hard to see that who usually asks that question cares about 100% of the language or at very least the compatibility profiles?
Android N has partial support for Java 8, it doesn't support all the new Java 8 APIs nor new bytecodes.
Additionally, given that Android M is around 10% after one year, how long do you think Android developers can fully target Android N?
Are you serious? LINQ (okay, that was 3.5 IIRC), the TPL and async await fundamentally changed how I write C#.
Since .NET 4 introduced a new runtime (just as .NET 2 did; due to that I'd also say that 4 was not just a minor upgrade) all subsequent versions so far run on the same runtime and just change the libraries. MS got a bit of complaints for a confusing versioning scheme: .NET 2, 3, 3.5 that all used the same .NET 2 runtime, but had different library capabilities. It seems to me that they are doing this better with .NET 4: Every 4.x version runs on the .NET 4 runtime. .NET 5 will likely do the same again, once it is released.
They also changed another part: All .NET 4.x versions are drop-in replacements for .NET 4.0. That's why, when you look in the C:\Windows\Microsoft.NET\Framework directory, you see v1.0, v1.1, v2.0, v3.0, v3.5, but only a single v4.0, which on my machine is actually 4.6.(probably 1).
All this doesn't mean they cannot iterate on the runtime itself, though. Recently we got a new JIT for example, and I think the GC also got some upgrades. And keep in mind, this is the release announcement for .NET 4.6.2 – a minor upgrade over 4.6.1. Naturally you won't see major new features added.
____________________________
> Plus several APIs turned out to vanish pretty quickly and are dragged along as legacy like WinForms, Silverlight, WPF, Managed C++, ManagedDirectX and its next incompatible iteration, SharePoint APIs, WinFS, etc. Plus the incompatible different API WinRT aka WinRunTime aka UniversalRuntime with various incompatibilities in WinPhone8, Win8 & 10.
Most of those are completely separate products and are not part of the .NET Framework. You can argue that Microsoft is happy to create new APIs and let them die, but the vast majority of those are not in the actual framework.
____________________________
> In comparison Java is source compatible to at least v1.4,but in reality often back to Java 1.1 or 1.2.
Uhm, that very much depends on the features you use. Sure, if you eschew generics, auto-boxing, annotations, enums, foreach loops, and a lot of other language features. Especially 1.5 brought a lot of things that permeate many Java codebases. In 1.1 you'd have to live without collections, XML, regex, and a few other things. I don't doubt Java codebases exist that could meaningfully go back to that compatibility, but I'm not convinced they're that prevalent. (I know, especially in Enterprise, Java version uptake is slow. In my observation this currently amounts to Java 6 being the version usually used. Back when 6 was current, it was usually 1.4 and earlier.)
I was using the same cutting-edge version of Java for my high school AP classes as I was using in my senior year of college, which is sort of unheard of among the other actively supported and developed programming languages.
While .NET was pushed by Microsoft for everything else that didn't necessarily require the features of C++ and as such got a good focus in the whole stack and OS integration.
Sun like any other UNIX company, never understood the desktop, and the only OS stack they pushed Java was the network computer failed attempt and later on J2ME.
It was JEE (J2EE back then) that made it relevant again.
Oracle has always invested a lot in Java, they already quite a few Java based products in the early 2000. They were the first DBMS to support stored procedures in Java.
They also kept the Sun research labs going and will be integrating the Java JIT Graal into the standard JDK.
The Java Language Summit is taking place this week.
https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI...
The problem is that Oracle designs languages for suits not jeans.
Sun was serious about write once run anywhere; Java is remarkably successful in that regard. Part of that was not including OS-specific functionality. We'll see how well MS does on that front.
Java is failure on the desktop, nowadays besides IDEs and a few FOSS tools there are hardly any applications done in Java on the desktop.
If Google hadn't forked it for Android, it would be yet another server language.
Besides Android, we only get RFPs for JEE projects nowadays.
Also all the features that should bring Java up to speed with the new generation of compiled languages in value types, generics and AOT compilation as standard toolchain feature are planned for Java 10 or later.
Why do you think Scala guys are exploring Scala Native?
Nowadays there are hardly any applications done on the desktop, full stop.
I agree that the JVM would benefit from being usable for a) command-line utilities that are lightweight enough to use in pipelines, and perhaps also b) decent native GUI applications (if you believe that niche is still important). But you don't need the capability for OS development to do those things. I mean, Python does those things. I don't think Scala Native is or should be serious about OS development.
The guys paying us didn't got the memo apparently.
Nor did the ones targeting Android, iOS and IoT LCD displays.
What is an IoT LCD Display and who is targeting them in the same way they target Android and iOS? Sounds like some class of hardware, but only thing I can find by searching is toy projects hooking up an LCD to a RaspberryPi or Arduino
They are targeting them the same way as iOS and Android in the sense that those type of applications are native to the underlying platform without any kind of browser playing the role of an OS.
Meanwhile Oracle could just as well rebrand themselves to Satan.
Does that mean what I think, and we're now free to have things deeply nested with arbitrarily long names? ~32768 characters according to the docs. I frequently hit this problem, especially with a git repository inside of a solution with a huge name.
This is great and I wonder if this will incentivize vendors to finally recompile some of their old applications or if the *.config file change will be good enough.
(You wouldn't have to recompile anyways; the targeting is just some metadata, so you could just change the already-compiled code unless they do their own binary verification.)
// the following is on ln:30
thing.NestedThing.NestedOtherThing.Property.NestedProperty
Does anyone have any more context for this?
That being said, better late than never.
Though I do recall a long time ago reading about some JVM switches that allow that data to be accessed but with performance issues. Can't recall where I read that.
Would love to know how to do that.
I hope I will be wrong.
ps: a language where non-nullable references are the thing would be the best.
As I see: unfortunately without algebraic types you cannot solve this properly, even if you address the lacking points in Optional<T>
See slide 17 of https://oracleus.activeevents.com/2014/connect/fileDownload/...
I'm not justifying buggy code, but these days we do handle more objects-per-debug-line-number than we used to.
new string[] { "1", null }.Select(s => s.Length).ToList();
It's helpful to have the actual thing that's null for post-error troubleshooting.
Not necessarily. Take a look at LINQ, for example.
I'm surprised you've honestly never opened an error call stack and gone "I wish I knew which one it was that is null".
function frob(foo) {
return (foo && foo.ary || [])
.map(...)
}
I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage.
Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
It's best to make it impossible to call your function with the wrong kind of thing, but Javascript doesn't have a type system. Still though, if their code has gotten into a nonsense state, better to throw an exception (or whatever the language-standard way of handling errors is) than silently carry on. Otherwise they can spend up hours debugging their filtering logic wondering why it's started filtering everything out, when in fact the server they were calling into has started sending 1-element responses as not an array which your code then silently changes into an empty array.
> I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage.
If you propagate garbage you're part of the problem. Defensiveness goes hand-in-hand with fail-fast.
> Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
Right but if your query was malformed you should get a 4xx, not a 200 with no results. (This is one reason I think it's actually a bad idea to use 404 for when there's no item with that ID - it makes it hard for the client to tell the difference between "I called the API wrong" and "I called the API correctly but there are no results").
public Result MapResult(IntermediateType src)
{
return new Result
{
Property1 = src.Property1,
Property2 = src.Indirection.Property,
[...]
};
}
public Result MapResult(IntermediateType src)
=> new Result
{
Property1 = src.Property1,
Property2 = src.Indirection.Property,
[...]
};
I imagine there is a reason why it's hard, but it seems like it should be easy and incredibly valuable to know which property assignment caused the exception.
Regardless, I agree that this is a major source of NREs
There are no such tool tips when looking at log files. If this problem happens rarely or only in production, that oftentimes is the only thing you have.
Even if there are just two potential null references on the offending line, one of which seems unlikely, knowing for sure that it is the other one will speed up finding the root cause.
int? count = customers?[0]?.Orders?.Count();
Pragmatic features like this are one reason why I love C#. I get the feeling that language designers are actually looking at real world code and thinking what kind of features would be it better.
My rule of thumb is that ?. is OK to use when
1) The reference is expected to occasionally be null in the course of normal operations
2) You legitimately don't care if the reference is unexpectedly null, as you wouldn't or couldn't fix it even if you knew about it
Otherwise it's better to discover and fix the NullReferenceException ASAP.
[1] - https://msdn.microsoft.com/en-us/library/dn986595.aspx
Assert.That(r.Exception?.InnerException?.Message, Is.EqualTo("Exception result"));
config?.OutputName ?? DefaultConfig.OutputName
Invoke Action<> or Func<> that may be null or unassigned (this works for Events as well):
actionHandler?.Invoke(value);
items.First()?.Data
items.FirstOrDefault(item => item.Data != null)?.Data items.First()?.Data
The rest of your samples look fine to me though.
WCF gets a big fix.
This is some good stuff. It feels like Microsoft are listening again. I suppose they never really stopped, but this is good.
Nice to see that stuff on UserVoice does get acted on for sure!
https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
Think of it as the Compact Profiles introduced in Java 8.
There are a few other async/await constructs that are glaringly missing in .NET. My most useful is a function 'await TaskEx.EnsureNoContext()' which conditionally yields to the threadpool if not already on it. With this function I rarely need to use 'Task.Run'.
with .net and visual studio, Microsoft seems to think and plan way ahead, and even when it missed the boat, they are able to quickly turn things in the right way
example: .net got a little fat, so we now have .net core, with open source and genuine cross platform intentions thrown in for free
with a little more effort and care :) .net might even become fashionable!
Because it was at some point IIRC,they didn't have a team for it internaly. This was back in the silverlight shutdown, html5/winrt win8 drama. Silverlight actually died, WPF got revived. This is just going on memory, and I wasn't really paying attention to it anyway.
IronPython and IronRuby are still useful for doing .NET things in a REPL or scripting, though Roslyn's support for C# (and VB) REPL/scripting and F# have lessened the amount of time I spend with IronPython.
(I did recently hear IronPython rebooted and is trying to build out a full CPython 3.5+ compatible version, which was exciting to hear.)
I haven't had the chance to play with Roslyn yet, though. Seems promising.
WPF may not be the best thing ever, but it certainly isn't totally broken either.
Its foundation XAML + .NET API has always been around in different forms.
The only issue is the implementation isn't 1:1 compatible across all its variants.
.NET is huge, this release is tiny.
We're doing fine: deployed on centos6, devs on OSX and win 7.
Intellij licenses are the least of our problems, compared to the clusterfuck that we dumped.
So tell me MS:
What do you give me that Spring Boot, Scala, etc.
Ability to write SIMD code.
Real value types and ability to write almost C++ like code with structs and pointers, in case performance requires ask for it.
No JNI, rather developer friendly P/Invoke, RCW and C++/CLI for interoperating with native code.
No need to go fetch a VM plugin from somewhere, just to be able to debug the quality of machine code being generated.
Powerful desktop stack that is actually used.
F# is much better than Scala for those that enjoy ML languages and is available by default. No need to ask for permission to install it.
Ability to target the HoloLens, XBox, iOS and Android.
I'd also say that MVC/Razor, etc is much nicer than the Java counterparts I've seen... though I tend to not be too idiomatic with it when I've used it, very nice. Razor is probably my all time favorite view engine, though harder to use outside a web context (emails).
The much less terse syntax for generics is another big one over Java... with Java, it feels like all you save by having generics is lost with the extra syntax and typing you have to do... for example the LINQ functions (I actually don't care for the syntax) in C# are great, and the lamda expression syntax is awesome too.
I haven't used F#, but every time I see an article, I think about how awesome it looks, and seems to be more approachable than some other FP languages. Although I took a diagonal step and do a lot of mostly functional JS these days (I like and work a lot in node's good use cases).
Oh, another one, the .Net docker containers are MUCH smaller than Java...
It surely feels strange to argue for .NET given how it started and how I also bashed it back in the early days, specially since my employer had access to early versions of it pre-1.0.
But nowadays is just feels better.
However Oracle is actually making the effort to improve the whole generics/JNI/AOT compilation story, but those improvements are only targeted for Java 10 and beyond, while .NET has those features today.
And Android developers are not going to get them anyway.
I don't agree with everything they've done, and it continues to improve. I've been reaching for node.js far more often the past couple years than I have for .Net though. Being able to deploy on Linux has been a pretty significant requirement for a lot of things, and node allows really quick ramp-up, though there are too many "expert" JS devs that aren't.
I'm hoping to find an excuse to play around with VS Code and .Net core bits pretty soon... then again, I've been saying the same for rust and go for a while as well.
Are you from 2006?
They really need to switch these defaults, I don't know why they don't have the newer versions enabled!
[0] - http://referencesource.microsoft.com/#System/net/System/Net/...