
.NET Framework 4.6.2 - Avalaxy
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
======
NKCSS
Update summary (some smaller fixes/improvements omitted):

    
    
        - 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
    

Minor nitpick, but why would you name your XML example files .cs (C#) files :P

[https://gist.githubusercontent.com/staceyhaffner/8bad9c0895b...](https://gist.githubusercontent.com/staceyhaffner/8bad9c0895b647703784db65237c5b5f/raw/7384c36d9cd668bc6988d4da6c4fce28737d2616/longpathsample1.cs)

~~~
jsingleton
More background on the long paths:
[https://blogs.msdn.microsoft.com/jeremykuhne](https://blogs.msdn.microsoft.com/jeremykuhne)

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-...](https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap)

 _edit:_

More info on Response Caching:
[https://docs.asp.net/en/latest/performance/caching/response....](https://docs.asp.net/en/latest/performance/caching/response.html)

Shameless plug: I've written about Response Caching in my book on ASP.NET Core
([https://unop.uk/book](https://unop.uk/book)).

------
agentgt
As a Java developer I am always so envious of how attentive Microsoft is with
.NET. Maybe it is the grass is greener but it feels like oracle just sits on
its ass and ignores most of the Java community.

~~~
wernercd
The force is strong in this one... Come... Come to the dark side. We have
cake.

~~~
perseusprime11
Cake = Mac + VS Code + .Net Core

~~~
abrookewood
Can I ask how you find working in this environment - genuinely curious. DId
you have to refactor your applications much, or did you start off targetting
.Net core?

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.

~~~
ktRolster
I spent some time with Mono/.NET last year. It worked fine, but not everything
was implemented. Specifically, we had some members on the team (the architect
being one of them) who liked to include cutting edge features from .NET, that
didn't work on Mono (he also had decided to write a large chunk of code in
Silverlight, but that's a different story).

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.

~~~
codingmyway
There's plenty of hate for entity framework among full .Net devs too. It's one
of Microsoft's quick to get started but crap to enhance and maintain tools.

~~~
kidmenot
I hate it with a passion. I use Dapper whenever I can and couldn't be happier
about it.

~~~
codingmyway
Yep. Dapper is far simpler. All the relationship navigation and deferred
loading of related entities is clever but takes effort to optimize and is too
easily abused.

Every large team I've seen use it (EF) ends up with slow horrible queries
generated that DBAs see hitting the database thinking WTF?

------
backslash_16
In the release notes it says the MAXPATH file name limitation is fixed.

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.

~~~
dogma1138
Yes it was originally the same as the UNC path limit which was 260 chars.
Microsoft (a while ago) has updated WinAPI to support unicode and under
extended-length paths has lifted the limit up to 32,767 chars it seems that
now .NET matched this also. [https://msdn.microsoft.com/en-
us/library/aa365247(VS.85).asp...](https://msdn.microsoft.com/en-
us/library/aa365247\(VS.85\).aspx)

~~~
poizan42
"A while ago"? That was at least back in NT 3.5

~~~
dogma1138
IIRC the MAX_PATH limit was lifted from Win32 with one of the Windows 10
builds. But it's true that unicode support was there for a "while" ;) the
limit however was still enforced, so I should've been more clear that only the
restriction lifting was more recent than 2 decades past.

------
FLGMwt
FYI, I just installed 4.6.2 Dev, started a new project, made some sample code
that I hoped would exhibit improvements to the NRE messaging, but it seems
that the messaging is the same. For example, if you have the following:

    
    
        // the following is on ln:30
        thing.NestedThing.NestedOtherThing.Property.NestedProperty
    

And you get a NRE on ln:30, you'll only get "NRE on line 30". Reading between
the lines, the release notes imply that the _support_ for additional context
has been provided in the debugger APIs, but may not yet be consumed by Visual
Studio. This is also supported by the fact that I didn't need a Visual Studio
update to target 4.6.2.

Does anyone have any more context for this?

~~~
joshschreuder
That's the way I took it too - the framework is laying groundwork for better
debugging support for NRE in VS v15 which is yet to be released. Perhaps
they'll target it for VS 2015 update 4 as well?

------
dimgl
I can't believe it took this long to show the name of null references.
NullReferenceException is actually the first exception I ever encountered when
I started learning how to use C#.

That being said, better late than never.

~~~
ygra
Is that really such a sorely missed feature? I tend to need just a quick
glance at the offending line to isolate potential null references and in more
severe cases just check the tool tips of expressions. Or are others writing
code that's unusually dereference-heavy?

~~~
moogly
Common, popular, coding styles with a lot of inlined code instead of
temporaries will have this issue:

    
    
      public Result MapResult(IntermediateType src)
      {
          return new Result
          {
              Property1 = src.Property1,
              Property2 = src.Indirection.Property,
              [...]
          };
      }
    

or, in C# 6

    
    
      public Result MapResult(IntermediateType src)
          => new Result
          {
              Property1 = src.Property1,
              Property2 = src.Indirection.Property,
              [...]
          };
    
         

if _Indirection_ is null here (or indeed _anything_ that can throw an NRE
within the initializer), the NRE will reference the line starting with
_return_ / _= >_

~~~
kmc059000
This is usually where I get NREs too and is the most frustrating. When using
object initializers, the line number is the same for the entire initializer,
so you don't get much help in determining exactly which line the exception was
on.

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

------
watmough
Wow MAX_PATH is going away ...

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.

~~~
ayuvar
I can't wait for the tools side of things to pick up on the MAX_PATH fixes.
msbuild path limits have been a thorn in my side at a few jobs now and it will
be nice to finally kiss them goodbye.

Nice to see that stuff on UserVoice does get acted on for sure!

~~~
tracker1
I'm hoping that via CoreCLR's use of libuv, that these changes will make it in
there, and by extension node... would make a lot of windows + node.js users
very happy, to say the least.

------
tracker1
Holy crap, they fixed the abstraction for long file paths!!! I never
understood why they didn't transparently use the long path support for longer
paths in .Net from the beginning. I'm still hoping to see libuv do the same
(which would be great for node.js).

------
namelezz
With .Net core, is C# "write once run anywhere" like Java?

~~~
kodfodrasz
If you have a .Net Core runtime on your platform, then yes. You cannot run
.Net Core apps on traditional .Net Framework. (There are differences in the
base types as .Net Core was redesigned to eventually support AOT, among many
other things, which results in incompatibilities.)

------
jackcosgrove
I know this is a breaking change, but I sure wish async methods called
ConfigureAwait(false) by default. That's a majority of use cases in my
experience. I've come across .NET libraries with asynchronous methods that
deadlock because some internal asynchronous call does not invoke
ConfigureAwait(false).

~~~
achr2
I definitely agree. Not using '.ConfigrueAwait(false)' is the exception rather
than the rule. That said, I use an extension method '.NoSync()' to replace it
which at least is more succinct and explicit.

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'.

------
dagaci
the .Net framework project is an insightful reminder that MS can build and
execute on a project well, visual studio is great, .net/c# is great I often
hear that f# is something special and worthy

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!

------
Citrus2fizz
So happy for per monitor dpi scaling in wpf

------
tener
Interesting to see any improvements for WPF. I thought it is dead for good.

~~~
crispyambulance
I hear that a lot, but why do folks say that? It has just become a mature and
stable UI platform suitable for long-term development. What's the alternative?

~~~
rubber_duck
>but why do folks say that?

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.

~~~
tracker1
Not sure about WPF, but DLR was pretty much left to die on the vine, which is
somewhat sad.

~~~
WorldMaker
Arguably the DLR accomplished what it set out to do and it is very usable.
I've used C#'s dynamic in a number of production project and even a deeper use
of DLR constructs (IDynamicObject expression generation) in a few particular
sets of circumstances. You can kind of see how Microsoft felt the DLR was
"finished" because they solved a lot of the hard problems and made them seem
simple and easy.

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.)

~~~
kidmenot
Happy to hear about IronPython trying to get up to speed, I'm using it a lot
and it's pretty awesome.

I haven't had the chance to play with Roslyn yet, though. Seems promising.

------
aashishkoirala
Nice. But I wonder when they will get around to updating the Service Fabric
with the new version. I think SF is still on 4.5 or 4.5.1.

~~~
benaadams
It's what's installed on the VMs so will run on 4.6.2 if you install it on
them.

~~~
aashishkoirala
Yes, but I don't want to have to go in and manage the VMs individually - then
I'm almost doing IaaS. Besides, that would not work with the new VM scale sets
that spin up new VMs on the fly.

------
rjbwork
4.6 and 4.6.2 are still not available on a stock VM Image on Azure.
Ridiculousness.

------
merb
Why the hell did they call it 4.6.2. I mean so many feature's for a x.x.2?
microsoft naming schemes are a whole lot of mess..

~~~
daigoba66
It's actually reasonably consistent with how .NET has been versioned for the
past 4-5 years. They've never pretended to follow "semver", but their
versioning system works.

~~~
josephcooney
From a version number point of view maybe, but to say 'it works' is pretty
charitable. CLR versions vs framework version confusion - "oh, you've got a
.NET 3.5 app, you need CLR version 2.0". ASP.NET version vs framework
versions. ASP.NET 5 vs ASP.NET 4.6 (ASP.NET 5 was re-named to ASP.NET Core
1.0). I guess CLR versioning "works" but in the broader .net ecosystem it is
still a problem.

~~~
adamconroy
i don't agree that CLR vs .NET versions are confusing. .NET is the CLR plus a
pile of libraries. The CLR moves slowly, the non-clr parts of .NET iterate
faster. I rarely even think about the CLR version at all. It was a minor
consideration 10 years ago when CLR 1->2, but even then it was somewhat of a
theoretical point that was basically handled by the version of .NET you
targeted.

------
hiram112
As another java dev who is glad I didn't get stuck with .Net seven years ago,
why do I want it not?

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.

~~~
pjmlp
AOT compilation for free instead of having to buy Excelsior JET, J9, Atego,
....

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.

~~~
tracker1
Second on the sane P/Invoke and interop in general... main reason why I jumped
to .Net _very_ early on. By comparison, every time I touch Java it feels like
an exercise in frustration, though seems better since Maven.

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...

~~~
pjmlp
I work across Java, .NET and C++.

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.

~~~
tracker1
Yeah, interop was one of the things that .Net/C# got very right, very early
on, of course the framework libraries themselves leveraged windows internals
quite a bit early on, so it was very important. When .Net 3.5 came out is
when, imho C# was pretty much done, in terms of language features, I mean
there's been a few things since, but it was a joy to work with compared to
anything else at 3.5.

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.

------
velox_io
The .Net Framework still only supports TLS 1.0 for out-going connections by
default.

They really need to switch these defaults, I don't know why they don't have
the newer versions enabled!

~~~
dsp1234
This is incorrect. As of .net 4.6 it defaults to "tls12 | tls11 | tls" unless
you specifically set a registry setting to do otherwise. You can see this in
the reference source[0]

[0] -
[http://referencesource.microsoft.com/#System/net/System/Net/...](http://referencesource.microsoft.com/#System/net/System/Net/ServicePointManager.cs,686)

