.NET Framework 4.6.2(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
.NET Framework 4.6.2
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
160 comments
More background on the long paths: 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-...
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).
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).
> - Allow paths that are greater than 260 character (MAX_PATH).
That's surprising.
That's surprising.
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.
Java always suffered from Sun not being serious about it for OS development.
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.
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.
How much OS development is there to be done?
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.
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.
Having the capability for doing OS development implies having a whole stack language, which Java never achieved.
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?
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?
> 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.
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.
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.
> Nowadays there are hardly any applications done on the desktop, full stop.
The guys paying us didn't got the memo apparently.
Nor did the ones targeting Android, iOS and IoT LCD displays.
The guys paying us didn't got the memo apparently.
Nor did the ones targeting Android, iOS and IoT LCD displays.
> targeting Android, iOS and IoT LCD display
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
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
It is just what I remembered to type to mean any kind of screen being used in IoT scenarios, from car displays, factory control units, plane dashboards, cranes, ATMs, entertainment systems, biology cell screeners ...
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.
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.
You can't port Java code cross platform, Java Card for example is not 'Java'. It's more their developers are somewhat cross platform.
Different sense of "platform". The point is that Java SE runs on many different OSes and architectures in write-once-run-anywhere fashion, including GUI applications. We've yet to see whether .net can deliver that.
Even Java SE needs testing and often dev work on a new platform. It's possible to write C or Java code that's cross platform, but that's not the default.
It's a lot closer to the default with Java SE. I've seen a fair few Java programs work first time on platforms they weren't tested on - as long as it doesn't access the native filesystem with windows-style paths it tends to be fine.
Amazing that companies that spy on you like Google and nowadays also Microsoft enjoy such a good reputation basically by giving away technology for free.
Meanwhile Oracle could just as well rebrand themselves to Satan.
Meanwhile Oracle could just as well rebrand themselves to Satan.
Oracle is not consumer facing. But, they are arguably far worse to their customers.
The force is strong in this one... Come... Come to the dark side. We have cake.
the IE team used to exchange cakes with Mozilla team on shipping versions.
http://www.theverge.com/2012/10/27/3563892/internet-explorer...
But then Mozilla started releasing versions every couple of months
But then Mozilla started releasing versions every couple of months
Cake = Mac + VS Code + .Net Core
actually quite literally cake: https://github.com/cake-build/cake (C# Make)
Interesting. You can have the cake and eat it too.
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.
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.
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.
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.
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.
I agree that the early versions of EF were very buggy (v1-3). It would work fine and then you would hit a show-stopping bug with no fix. However, the recent releases of EF have solved those problems and works great. I can't imagine not using an ORM at this point, and after witnessing NHibernate's stagnation I would recommend using something officially supported by Microsoft.
I hate it with a passion. I use Dapper whenever I can and couldn't be happier about it.
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?
Every large team I've seen use it (EF) ends up with slow horrible queries generated that DBAs see hitting the database thinking WTF?
Like a lot of Microsoft's data access technologies, it demos well in front of an audience. :-/ (from someone who still has their ODBC 5-1/4" floppies)
It depends on the application.. you can try running your assemblies through MoMA (mono's migration tool) to see what gets flagged. A lot of the enterprise classes that are tied to windows obviously don't work... There's also no support for WPF iirc, though there is some Silverlight/Moonlight support, but that's another story.
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.
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.
If you have .NET 4.x app and you want to convert it to .NET Core you're going to have a bad time.
However making things from scratch works totally awesome.
However making things from scratch works totally awesome.
What do you write in .Net Core on a mac? I'm guessing you get paid to do this, and it sounds like an interesting niche.
Replace VS Code with Rider and I'm here.
And for once the cake is pretty decent.
Will there ever be a dotNetFramework 5 ?? Version 4 is from 2012 which was already a minor update from v3 from 2007.
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.
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.
> All mayor features were available since v3. Though then the development stagnated and little new outstanding new featured were included in newer releases.
Are you serious? LINQ (okay, that was 3.5 IIRC), the TPL and async await fundamentally changed how I write C#.
Are you serious? LINQ (okay, that was 3.5 IIRC), the TPL and async await fundamentally changed how I write C#.
Java might be source compatible, but sometimes it is quite fun to make libraries work across versions.
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.
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.
The shithole Google has dug itself and its developers is pretty deep, yet they keep digging instead of partnering with either MS (for C#) or Oracle (for real Java) to get a sane modern language.
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
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
When you see their Google IO presentations or interviews, they re-iterate that Java is the only true way on Android, with the NDK just for games and implementation of Java native methods.
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?
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 supports Java 8: https://developer.android.com/preview/j8-jack.html
That is not 100% accurate.
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?
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?
Note that .NET Core is, more or less by necessity, much smaller than the full .NET framework. The latter isn't going anywhere or being deprecated. Think of Core as just another subset of APIs that happen to also work really well on other platforms. We had that already with Silverlight, Client Profile, and other things.
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.)
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.)
Java 1.5 is also twelve years old. A big chunk of that time is the stagnation after 1.6 when Sun was on the ropes and Oracle hadn't stepped up to make any improvements yet.
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.
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.
I really like what Microsoft is doing with the CLR and .NET but I'm not sure I agree Oracle is sitting on Java and doing nothing. Java 8 was a big deal and Java 9 and 10 are going to have large improvements.
Now if Sun still owned Java that would be a fair assessment. They couldn't figure out what to do with the language.
Now if Sun still owned Java that would be a fair assessment. They couldn't figure out what to do with the language.
I half jokingly suspect Oracle only bought Sun so they could sue Google
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:
Does anyone have any more context for this?
// the following is on ln:30
thing.NestedThing.NestedOtherThing.Property.NestedProperty
Does anyone have any more context for this?
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?
more info on this issue - https://github.com/dotnet/coreclr/issues/25
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.
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.
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!
Nice to see that stuff on UserVoice does get acted on for sure!
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.
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).
With .Net core, is C# "write once run anywhere" like Java?
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.)
Eventually, Microsoft is making a common base that is supposed to be available in all .NET implementations.
https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
Think of it as the Compact Profiles introduced in Java 8.
https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
Think of it as the Compact Profiles introduced in Java 8.
Yea, you also need .NET Core runtime, not Mono. So it's kind of lightweight.
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).
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'.
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'.
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!
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!
So happy for per monitor dpi scaling in wpf
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.
It's what's installed on the VMs so will run on 4.6.2 if you install it on them.
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.
4.6 and 4.6.2 are still not available on a stock VM Image on Azure. Ridiculousness.
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..
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.
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.
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.
[deleted]
> so many feature's
.NET is huge, this release is tiny.
.NET is huge, this release is tiny.
Huh? There are like 2 features that affect everyone. Both minor.
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.
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.
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.
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.
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...
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...
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.
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.
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.
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.
I tried learning Java on several occasions. I'm glad I threw in the towel. Living in Asia, pay is so much lower than .NET.
Here in the US they seem to be about on par... though I find the Java devs I've dealt with have tended more arrogant and closed minded, ironically enough.
Interesting. In the UK Java gets a slight premium and there's still the impression that .net devs are more siloed and don't keep up with things so much but that is changing. Not sure what proportion of Java devs know Scala vs .Net/F# but seems like .Net is catching up on that front and C# is more functional friendly and ahead of Java on that front.
I don't get it. I work on OSX with .NET Core using nothing but open-source tools.
Are you from 2006?
Are you from 2006?
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!
They really need to switch these defaults, I don't know why they don't have the newer versions enabled!
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/...
[0] - http://referencesource.microsoft.com/#System/net/System/Net/...
This tripped me up very recently too. Its opt in for framework <4.5.2 I think
Interesting to see any improvements for WPF. I thought it is dead for good.
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?
>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.
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.
Not sure about WPF, but DLR was pretty much left to die on the vine, which is somewhat sad.
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.)
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.)
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.
I haven't had the chance to play with Roslyn yet, though. Seems promising.
Nice to hear that IronPython is still seeing some love... I was sad to see (whatever the DLR JavaScript runtime was called) go away when IronRuby and IronPython were picked up.
[deleted]
The UWP XAML stack should be considered the successor to WPF (and for old die hards, Silverlight for that matter as well).
[deleted]
I would like to understand where all the hate comes from. I haven't done any .Net work in about 6 years, but I loved WPF. It's the only UI framework I thought was _okay_.
What hate?
WPF may not be the best thing ever, but it certainly isn't totally broken either.
WPF may not be the best thing ever, but it certainly isn't totally broken either.
WPF is a complex beast. It works pretty differently from every other GUI framework out there¹ and has a steep learning curve. While you can program WPF and pretend it's Windows Forms, all that gets you is not very idiomatic code and confusion why you would even put up with that when WinForms is so much easier (except maybe XAML for building the GUI). Now, there's the other extreme as well: people who pretend XAML to be a programming language and try to bash at everything with templates and styles, trying to never have to write a single line of C#. In my experience people scoffing at or hating WPF come from one of those two camps.
I use WPF every day and it is a powerful framework. That said there are definitely aspects that are very poorly designed. It desperately needs a fork to catch up with the modern framework (no support for generic types, async Task-based commands, etc.). Not to mention that the slow measure/layout pass means that we still have UIs that 'hang' even when absolutely all programmatic work is done on a background thread.
I'm the opposite, I really don't like it at all.
It never really went away.
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.
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.
Even if nothing else (sorry, UWP), Xamarin uses WPF as its view language and MSFTs recent critical acquisition I think keeps WPF alive for at least another 5 years.
Are you sure you're not thinking that Xamarin uses XAML and not WPF? XAML is used by WPF, UWP, & Xamarin Forms, but I don't recall WPF being on anything other than Windows.
Oh, damn, you're right. I only just now realized I've erroneously used those interchangeably for years. /humbly skitter away
Note that XAML is nothing more than a way of serializing object graphs to XML. WPF uses XAML (as do a bunch of others), but the objects created when parsing the XAML can be pretty much anything and all that is not tied to WPF in any way. Case in point: Our main product is a graph display and editing component, using GraphML as its native file format. We serialize visualization and business data attached to the graph as XAML, and while that particular code portion originated in the WPF branch, the format is the same, even in the Java product.
Thought the same of WCF. Could've sworn Web API was going to replace WCF.
I think Web API was just intended to be a lightweight replacement for RESTful API in WCF. WCF does so much more, the most popular probably being SOAP, but I believe it does much more in the messaging, queue, workflow space as well.
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.
That being said, better late than never.
+1 for this. The null conditional is also pretty nice thing for the chained method calls. In C# you can write like this:
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.
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.
Slight aside: please don't abuse the Elvis operator like that (by using it on every single nullable reference), it could easily grow into a widespread anti-pattern that makes debugging harder.
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.
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.
Generally agreed, and out of curiosity I just looked through some fairly new code I have that's pretty heavy on C# 6, and only found a single instance of two null conditionals being used:
Invoke Action<> or Func<> that may be null or unassigned (this works for Events as well):
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.
It's the null propagation operator.
Look, if you want to be pedantic it's the null conditional operator[1]. But it is widely called the "Elvis operator"[2].
[1] - https://msdn.microsoft.com/en-us/library/dn986595.aspx
[2] - https://www.google.com/#q=c%23+elvis+operator
[1] - https://msdn.microsoft.com/en-us/library/dn986595.aspx
[2] - https://www.google.com/#q=c%23+elvis+operator
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?
I'd imagine that with the rise of the 'fluent' API style of foo.bar().baz().doThis().doThat(toThis).doAnother(toThat); the number of potential null-references per line has gone up from the days when we were all writing code with mutator methods that returned void.
The Fluent API styles is to return "this" so setter methods can be chained, that style doesn't produce nulls.
Yes, but any of the passed-in arguments can be null if they are de-referenced without checking, or you can muck up your context by doing something weird.
I'm not justifying buggy code, but these days we do handle more objects-per-debug-line-number than we used to.
I'm not justifying buggy code, but these days we do handle more objects-per-debug-line-number than we used to.
Especially in lambda expressions for LINQ methods...
But you can already debug inside lambda expressions. E.g. for
new string[] { "1", null }.Select(s => s.Length).ToList();
But you can't always debug code that's out in the wild with the same exact scenario that caused the NRE.
It's helpful to have the actual thing that's null for post-error troubleshooting.
It's helpful to have the actual thing that's null for post-error troubleshooting.
The whole discussion is about a debugger feature, or at least, the runtime groundwork required for said debugger feature. It will not result in the exception message telling you the null reference's name. It enables an attached debugger to query the runtime for additional information to determine that.
It does when it has a bug in it...
> return this
Not necessarily. Take a look at LINQ, for example.
Not necessarily. Take a look at LINQ, for example.
LINQ is not a fluent programming style, LINQ is standard functional programming with higher order functions. Chaining calls back to back isn't what fluent is, chaining calls to the same object back to back is fluent whereas with LINQ each call returns a whole new object or set of objects; these are entirely different things. The fluent style is an attempt to emulate Smalltalk's cascade operator in languages that lack it by returning "this" from setters enabling a chain of setters to be called on the same object: that's all it is. This style has been idiomatic to Smalltalk since the 70's and doesn't require faking it because there's actually a cascade operator.
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,
[...]
};
}
public Result MapResult(IntermediateType src)
=> new Result
{
Property1 = src.Property1,
Property2 = src.Indirection.Property,
[...]
};
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
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
Good point, thank you. We're still rather conservative, so except for nameof I haven't yet used any C# 6 features, and the code we write often doesn't look like that, so I tend to forget a few problematic styles sometimes.
In optimized code, in object initializers, or even within lambda expressions, the line number is effectively useless. So troubleshooting production exceptions is usually a game of guess-and-check. As a result, many teams are heavy handed with null checks and ArgumentExceptions if only to make debugging easier in crappy code.
Yup, can confirm. Release builds usually have nearly all useful stack information stripped out, so if you get a NRE, you're kind of left playing pin-the-tail-on-the-donkey guessing at what might have been null, without null-checks and asserts.
Once you're experienced and writing better code, this isn't a crucial feature. It does help when you've got coworkers who write classes with 20,000 lines however (not an exaggeration, I've actually seen this).
It was constant, especially in older code bases or anything involving SOAP responses with crappy WSDLs.
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".
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".
These days I actually cannot recall when that happened to me the last time, hence my curiosity. I remember null pointer dereferences in C++ on Android being impossible to debug, but honestly cannot recall the same for C# in VS. Might be that we simply don't write code that's susceptible to that problem (writing libraries ideas of applications makes you kinda defensive sometimes), or maybe that our code is often a bit conservative out of necessity, so no C# 6 features yet (others have pointed out that certain constructs are prone to let you guess on which line it happened).
It's funny, but with JS I write pretty defensively to prevent null references...
function frob(foo) {
return (foo && foo.ary || [])
.map(...)
}
That ends up worse than null because the actual error will happen even further away when some value is surprisingly []. You want to fail fast in cases where your state no longer makes sense. (This is why naive use of options can end up worse than null).
If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it.
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.
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.
> If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it.
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").
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").
"in more severe cases just check the tool tips of expressions."
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.
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.
But you don't have a Visual Studio debugger in log files either. This change is about runtime improvements that would enable a debugger to tell you the offending null reference. This won't change the exception message or anything about the exception itself.
For me, anything that produces a stack trace should use that information. IIS can be configured to do that.
You could use that argument with any slightly-better debugging feature. It's not groundbreaking but will save a few seconds/minutes each time from darting around. It adds up after a while and I bet after the next release of VS has it it looks backwards not having it.
The code your debugging isn't always line for line compatible with the code where/when the exception was thrown.
Anybody knows if/when Java will have this feature?
SAP's JVM implementation has NullPointerExceptions that tell you where the null originated from, which is neat.
See slide 17 of https://oracleus.activeevents.com/2014/connect/fileDownload/...
See slide 17 of https://oracleus.activeevents.com/2014/connect/fileDownload/...
I doubt believe it will ever or at least not anytime soon. I don't think the JVM preserves identifier names in the bytecode in a way that it can be accessed easily.
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.
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.
Sadly (as one developing a lot in Java) i think it won't happen anytime soon, and the community will ideologize it as "it is even better that we don't have it". :(
I hope I will be wrong.
ps: a language where non-nullable references are the thing would be the best.
I hope I will be wrong.
ps: a language where non-nullable references are the thing would be the best.
Java has finally got options, so at least it's theoretically possible to start a migration path to non-nullable. It will take decades though.
I tried to use the java Optional<T>, but the API has some points, which make it inconvenient for some usecases. (Some of these are addressed in Java 9)
As I see: unfortunately without algebraic types you cannot solve this properly, even if you address the lacking points in Optional<T>
As I see: unfortunately without algebraic types you cannot solve this properly, even if you address the lacking points in Optional<T>
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.
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.
Interview with the person removing filename limitations here, it's an interesting discussion about a horrible, hard problem.
https://www.dotnetrocks.com/?show=1320
https://www.dotnetrocks.com/?show=1320
One niggle, you still may have issues with Windows explorer, so if it's a path you need to navigate to, be careful... That said, I still don't get why .Net 1.0 didn't do this, I also don't get why they haven't fixed Windows explorer's long file/directory name support.
Looks like the Windows 10 update recently corrected a lot of the Path issues, so will have to see if this works now...
I don't see why people obsess about the MAXPATH as it's quite possible to get 32,768 characters, just use UNC paths with .NET which has been supported since I don't know when; you just need some DLL imports. https://ingehenriksen.wordpress.com/2015/05/23/how-to-work-w...
This does the DLL imports for you now and supports it across the board for everything that for everything that uses System.IO, which means once your app opts in you can use just about anything in the .NET ecosystem you want and trust it will work (say, a .NET 2 logging library that your company mandates). (It still needs UNC-like paths in some cases, but that's Windows back compat for you.)
This is just for the .NET wrappers. Other code might still have issues. Doesn't seem like recompiling is needed; as you mention there's a config switch.
(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.)
(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.)
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...
"A while ago"? That was at least back in NT 3.5
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.
Minor nitpick, but why would you name your XML example files .cs (C#) files :P
https://gist.githubusercontent.com/staceyhaffner/8bad9c0895b...