Last Updated: 2017/06/15
Today, we are announcing the general availability of the .NET Framework 4.7. The .NET Framework 4.7 was released as part of Windows 10 Creators Update a month ago. You can now install the .NET Framework 4.7 on other versions of Windows.
You can download the .NET Framework 4.7:
The .NET Framework 4.7 includes improvements in several areas:
- High DPI support for Windows Forms applications on Windows 10
- Touch support for WPF applications on Windows 10
- Enhanced cryptography support
- Support for C# 7 and VB 15, including ValueTuple
- Support for .NET Standard 1.6
- Performance and reliability improvements
Please see the Announcing the .NET Framework 4.7 blog post to learn more about each of these improvements.
You can see the complete list of improvements in the .NET Framework 4.7 release notes.
We recently released .NET Application Architecture Guidance. Read these guides to get practical advice, best practices, and sample applications for using .NET with microservices, Docker containers, Kubernetes, Xamarin, ASP.NET, Azure, Service Fabric, and more.
Supported Windows Versions
The .NET Framework 4.7 is supported on the following Windows versions:
- Windows 10 Creators Update (included in-box)
- Windows 10 Anniversary Update
- Windows 8.1
- Windows 7 SP1
The .NET Framework 4.7 is supported on the following Windows Server versions:
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
DirectX Dependency
The .NET Framework 4.7 now uses DirectX 11 components for WPF. These components are available as part of the operating system in recent versions of Windows including Windows 10, Windows Server 2016, Windows 8.1, and Windows Server 2012 R2.
You must install an additional DirectX component in order to install the .NET Framework 4.7 on Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2012. The installation includes a single .dll that will get added to your system. It will only be used by WPF applications. It is not possible to install the .NET Framework 4.7 without installing this component.
The DirectX dependency is now available in the Preview of Monthly Rollup released via Windows Update on May 16, 2017. The Monthly Rollup is also available for deployment via WSUS and the Microsoft Update Catalog under the following Knowledge Base Article ids:
Windows 7 SP1 and Server 2008 R2 SP2: KB4019265
Windows Server 2012: KB4019218
The DirectX dependency is also available outside of the Monthly Rollup as an independent/standalone package in the Microsoft Update Catalog. Due to its relatively smaller size as compared to the Monthly Rollup package, this standalone package may be preferable for ISVs that need to redistribute the .NET Framework 4.7 with their application.
Please see the following for more information: The .NET Framework 4.7 installation is blocked on Windows 7, Windows Server 2008 R2 and Windows Server 2012 because of a missing d3dcompiler update
Q&A
We’ve had some great questions since publishing this post. Thanks for asking! Here are the answers:
Will the .NET Framework 4.7 be made available on Windows Update?
Yes. We are working on this now. We expect this to happen within 3 months at the most.
This new DirectX dependency is a surprise and a deployment challenge. Will that get better?
This DirectX component is now available on the Microsoft Update Catalog and also included in the May Preview of the Monthly rollup available on Windows Update and WSUS/Catalog starting 5/16/2017.
We did not include this dependency within the .NET Framework installer due to reliability and user experience reasons. The DirectX component and the .NET Framework 4.7 are separate Windows installers. In the case that a reboot was already pending on the system, the DirectX component (needs to be installed first) would be made a pending update while the .NET Framework 4.7 component would not be (only 1 pending update is allowed), requiring the user to manually run the .NET Framework installer after the reboot. The user would not be given clear instructions that they need to do this due to the way this installation technology works. We have a long history with reboot challenges and chose to make .NET Framework a singular component so that it would behave in an intuitive fashion with respect to reboots. As a result, the DirectX component is a pre-requisite not an included component.
Can I use DirectX 11 or 12 with WPF now?
This new DirectX dependency is quite targeted. It does not enable the use of later versions of DirectX with WPF. The feedback on wanting to use later versions of DirectX has been passed on to the WPF team.
Closing
Thanks for trying out the .NET Framework 4.7. Please tell us what you think about the release and how it is working for you in your environment. Please share your feedback in the comments below or on GitHub.
For more information on the release, please see Announcing the .NET Framework 4.7 and the .NET Framework 4.7 release notes.
Updated 2017/06/15: Added link for windows Update release
Updated 2017/06/01: Fixed a broken hyperlink for KB4019265
Updated 2017/05/22: Updated information about the DirectX dependency to note that the dependency is now available on Windows Update, WSUS and the MU Catalog.
Updated 2017/05/04: Added Q&A section
Yeah!!
Splendid.
Is the DirectX dependency required for Windows 8? Judging by the filename on the download it is but you overlook mentioning it in the blog?
Same goes for 2012 R2 – I assume the 2012 linked file works for 2012 R2 too?
D3DCompiler_47.dll is included in-box for Windows 8.1 and Server 2012 R2
There’s conflicting information here. From the post: “You must install an additional DirectX component in order to install the .NET Framework 4.7 on Windows 7 SP1, Windows 2008 R2 SP1, Windows 2012 and Windows 2012 R2”
…which is correct? Is 2012 R2 covered or does it need the dependency installed separately?
You need this component on Windows 8 and Server 2012 ONLY!
Windows 8.1 and Server 2012 R2 do not require D3DCompiler_47.dll (already present).
Already installed on 2012 R2 w/o the component 😉 !
Thanks everyone for noticing this mistake. Fixed.
.NET is the finest framework, and getting better with every version.
it’s really is.
Hi, . NET team
Is netfx4.7 support Windows Embedded 7 and 8.1? What’s about Windows 10 Enterprise 2016 LTSB (IOT Enterprise)
Yes, all these are supported
But .net framework 4.6.2 not supported in those OS
Windows 10 version 1607 (i.e. Enterprise 2016 LTSB) already have .net 4.6.2 inbox)
as for Embedded, the installer works just fine on them, even Vista accept .net 4.6.2 installer
and the prerequisite update KB4019990 is applicable for Embedded 7, this would give you a hint about .net 4.7 applicability
Why won’t the installer for .NET Framework 4.7 automatically install the DirectX dependency?
Yeah, looks like an obvious oversight. Though I suspect the windows team is trying to push everyone out of Windows 7 into 10 where they can extract more revenues from their customers, and has used pretty deceiving tactics in the past. So I wouldn’t be surprised if Microsoft wouldn’t try to make the experience of using windows 7 as much subpar as possible.
And how would you feel if you had customers insisting you still support software you released in 2009, despite there having been three major versions each with multiple updates since then?
If you create good software, no one will want to hang to an inferior product. Microsoft never had any Windows Vista support problem (or will have a Windows 8 support problem for that matter). But it has a Windows 7 problem because it made Windows 10 unappealing to too many of its clients.
You’re saying Vista and 8 were the best? You’re crazy. There is nothing wrong with 10. Aside from the idiotic firewall that opens EVERYTHING to EVERY application (and keeps doing it), including Windows Store apps. Other that that COMPLETELY RIDICULOUS aspect of 10, it is better than 7 IMHO. 7 was never really anything to brag about, it just wasn’t as bad as Vista.
Fully agree. This has to be part of the .NET installer or 4.7 will never be deployed. We have enough deployment support calls as it is which turn out to be .NET or vcredist failures. MS, please incorporate this into the .NET installer!
I updated the post with a Q&A section that addresses this issue. Please take a look at that.
This dependency is now released on Windows Update. It should be installed on many machines now. Within 3 months, it should be on most machines on the planet (at least those that are configured to automatically install updates).
When will this version will be available on Azure Web App ? Is there any breaking changes introduced by this version ?
I believe it takes about 2 months to make its way to Azure Web App. On breaking changes, very few. See: https://github.com/Microsoft/dotnet/blob/master/Documentation/compatibility/README.md#net-framework-47
Can I redistribute KB4019990 with my programs or not?
It doesn’t seem to require a reboot, so I’d say yes. Silently installing the framework itself didn’t trigger a blocking alert, but doing the kb prior to the framework should be fine.
The package carrying the DirectX dependency (KB401990) can be installed freely on the PCs within your organization. If you want to redistribute this package with your application outside your organization you need to contact Microsoft Customer Support and request a redistribution license. The redistribution license is free, but it is specific to your organization so this needs to be created.
Where can I get KB4019990 for 32Bit Windows Embedded 8 Standard (6.2)? Or is .net 4.7 not working for Windows Embedded 8 Standard?
ok, I solved it. I copied the 32Bit D3DCompiler_47.dll manually to system32 folder and now setup works fine and installs .Net Framework 4.7 successfully on Windows Embedded 8 Standard.
It seems only netfx 4.5.2 to 4.6.1 officially supported is Windows Embedded 7/8/8.1…462 and 47 not included
But I did not find any official document clear this point(netfx 462 and 47 support in Windows Embedded 7/8/8.1)
https://blogs.msdn.microsoft.com/windows-embedded/2015/08/10/microsoft-net-framework-versions-supported-by-windows-embedded-products/
This article clear that netfx 4.5.2 to 4.6.1 are officially supported is Windows Embedded 7/8/8.1(in fact netfx 452 is supported in Embedded 8 Standard now), but this article for a long time did not be updated
https://msdn.microsoft.com/en-us/library/8z6watww(v=vs.110).aspx
This doc says that in Windows 10 1507(LTSB 2015), netfx 46 and 461 are supported, and in Windows 10 1607(LTSB 2016), netfx 462 and 47 are supported (As of 2017 May)
how do i get this in msvc 2017 community? it’s not showing up in the installer. (o/s is win 2016).
Please see this page: https://www.microsoft.com/net/targeting
Rich , I appreciate the response, but that page says it’s included in vs2017. for me (and others) it is NOT.
please see https://developercommunity.visualstudio.com/content/problem/41930/vs-2017-does-not-install-net-47-sdk-and-targeting.html
i was able to install using the “developer pack” but this brings along the framework sdk as well which i didn’t really want/need.
seems like this is a problem that should be addressed.
Will this be pushed out to Windows 7 via Windows Update?
Yes. See Q&A section (just added).
The DirectX dependency is now available as part of the May Preview of Monthly Rollup release that shipped on Windows Update on 5/16/2017. This should improve the deployment story for most cases.
What about FIPS compliant managed .net encryption?
This is a must have for any application interfacing with a us federal government system.
Downplaying FIPS as less than state of the art should not preclude adding managed FIPS compliant encryption to .net.
Relying on the win32 APIs for long term FIPS compliance not good.
FIPS compliance is an important scenario for the .NET Framework. You are correct that we do rely on Win32 APIs for this. I’d like to understand better why that approach doesn’t work well for you. Please mail me at rlander@ms if you would like to chat further.
Very simple. Any application which needs to send a file/data to the US federal government needs to use a FIPS certified compliant encryption library.
Only a FIPS certified DLL can be used in a FIPS compliant application. A newer version of the DLL needs to be certified by an outside agency.
Our need is to use managed .net code and the FIPS certified win32 DLLs are not updated for several years. Our application lifespan is 2022 or later which would mean it is relying on a win32 encryption DLL which is well over 10 years old.
Covering the next 6 to 12 months as a default business strategy is not a class A solution when my customer is funding a $1,000,000.00+ solution which needs to live well beyond the 7 year document retention period for financial data.
https://blogs.technet.microsoft.com/secguide/2014/04/07/why-were-not-recommending-fips-mode-anymore/
Using an encryption DLL which is not FIPS compliant opens our customer up to many thousands of dollars in fines per occurrence.
Understood. This is a complicated topic. I’m happy to discuss if you would like at rlander@ms. There is too much context to discuss here.
> The .NET Framework 4.7 now uses DirectX 11 components for WPF. <
Does this mean we can now use D3DImage without having to interop with DirectX 9? Or are you still forcing everyone to go through DirectX9 for backwards compatibility? Any documentation updates or blog posts on that?
This new DirectX dependency is very targeted so will not help with that. I have passed on your feedback.
Ugh, yes please do consider updating WPF to use DX11 everywhere instead of DX9.
He’s passed on the feedback to the WPF team, and when they get back from permanent vacation they’ll migrate WPF to Directx11.
LOL
Is .NET 4.7 supported on Exchange Server 2016 CU5?
I asked the team. Not at this time. I was not given a specific date as to when that would change.
Is there a way to block installation of .NET Framework 4.7 on Exchange servers? Similar to a reg key like we used for 4.6.1? We don’t want the framework to bork Exchange.
Bump. How can we prevent .NET 4.7 from being automatically deployed to our Exchange servers via Windows Update?
Just like earlier .NET Framework releases, as part of pushing .NET 4.7 on Windows Update we will share a registry key to block the update for those cases that need it. You can use that to prevent automatically getting .NET 4.7 deployed on your Exchange servers till Exchange supports .NET 4.7.
Is there any way to see the details behind the changes.
I see some reference numbers in the notes but can’t figure out how to view the commits / issues:
eg I’d like to see details of “Improved reliability of the Windows Forms DataGrid control. [236488]”
Good question. The release notes are intended to be helpful to give people a better sense of the changes that are included. The bug #s are the real Microsoft-internal TFS bug numbers, giving each bug a unique identity and making it easy for us all to talk about them. .NET Framework remains a closed-source product and uses a private Visual Studio Team System instance so it isn’t possible for external people to see the issues. We started making release notes available a few releases ago. It was an intended to increase transparency. I modeled them after what IE and Unity was doing at the time. I’d recommend filing an issue on the microsoft/dotnet repo if you want to learn more about a specific issue. https://github.com/microsoft/dotnet/issues
I’m confused why anyone would want .Net 4.7 when it has some really nasty regressions (https://support.microsoft.com/en-us/help/4015088/known-issues-in-the-net-framework-4-7), and not only will your app break in some situations, the debugger is broken when you want to use System.ValueTuple while targeting a framework other than .Net 4.7. That basically means I can’t use that new C# 7 feature because I can’t yet target .Net 4.7, installed the Creators Update which comes with 4.7 by default, MS never previewed .Net 4.7 or a developer targeting pack, and yet released this bad framework update that we’re now stuck with for an undetermined amount of time until “will get fixed in an upcoming Visual Studio 2017 update and the next .NET Framework release.” occurs.
Seems like this installer for other platforms should have never been released. MS ideally would have fixed 4.7 or simply went straight to 4.7.1 so we could all forget how bad 4.7 is just like the story of 4.6 to 4.6.1.
(While I haven’t run into the regression bugs personally, they still make the framework look really bad. I’m mostly salty about the Tuples.)
We always dislike shipping with known issues. Some of these were found after we shipped Creators Update. We decided not to hold the broad release, but continue work on fixing the issues everywhere. The team is doing that.
We discussed the 4.7 tuples one. I didn’t think that it would hold anyone back from using tuples. The issue is quite narrow and has an easy workaround. I’m wondering if you mis-read the known issue. The problem only occurs with 4.7 while you seem to be suggesting the opposite.
It is possible I misunderstood the tuple bug and I’d be happy to accept I was wrong if I am.
My current understanding is this:
Dev machine has 4.7 installed.
On said dev machine, write application that targets below 4.7, such as 4.6.
Because the project isn’t targeting 4.7, reference the nuget for System.ValueTuple.
Write code: (string fName, string lName) tuple = (“Foo”, “Bar”);
Many aspects of the debugger fail.
Retarget for 4.7 and remove nuget for System.ValueTuple to avoid issue.
I have so far been unable to use VS 2017 in my production work, and part of that was my understanding of this bug. However, I just tried a VM with VS 2017 on Windows Creators Update and my steps above didn’t produce the bug (the immediate window and watch window could evaluate the tuple I wrote). What exactly is the bug then? I read the bug report several times thinking I understood it.
Hi Adam,
What you describe is indeed a known bug (sorry about that). The compiler (which is involved in the debugging experience) has been fixed in dev15.1.
Here’s some background on the bug:
The project targets 4.6 and includes the ValueTuple library.
When the application runs, mscorlib 4.7 loads (because it is installed) into the app, as well as the ValueTuple library.
When the expression evaluator (the piece of the compiler that supports the QuickWatch and Immediate windows) prepares a compilation resembling your running application, it will load both mscorlib 4.7 and ValueTuple.
When you type anything involving tuple syntax in the EE, that syntax will be compiled, but the problem is that the ValueTuple type is now ambiguous (as it exists in mscorlib4.7 and ValueTuple).
There is technically a way to resolve this ambiguity in mscorlib itself (adding ValueTuple to the GAC and creating type unification entries, from what I understand), unfortunately, we discovered the issue too late to fix in 4.7.
In the meanwhile, we have shipped a compiler workaround, to resolve this ambiguity. When this situation arises, the EE will prefer the ValueTuple types coming from mscorlib, over those coming from the library.
https://github.com/dotnet/roslyn/pull/17192 (I think this issue is what your encountering)
https://github.com/dotnet/roslyn/pull/18552 (this is a second issue related to debugging with tuples, but not specific to 4.7, I thought I’d include as FYI)
One more thought: I suspect that the problem disappeared for you because you got the fix (via dev15.1). To confirm that, look at the version of Visual Studio. If you need any more assistance, feel free to comment on https://github.com/dotnet/roslyn/pull/17192 or file another issue there.
You can ping me on those (@jcouv).
Hi Julien,
Thanks for explaining to me that VS 2017 15.1 already had a fix, and that is indeed what I tested it on and did not see the problem.
I must have missed the article or change note that specified that fix.
I do apologize for the ruckus.
“русский” (RU):
“”We’re sorry, this download is no longer available.
Perhaps one of the following links will help you find what you need. “”
…….(((…
I have to admit that I also had intermittent problems with the link. I refreshed the page and everything worked.
The .net FW 4.7 language pack is the same EXE as the offline installer. Bad link?
https://www.microsoft.com/en-us/download/details.aspx?id=55169
If you visit the site from an ENU box then the default package is the neutral (ENU) package. You will need to select a specific language from the dropdown to see the language pack for that language.
Dear Microsoft
Could we expect .NET Framework 4.7 installer, integrated with DirectX Dependency and integrated updates for blocking installation “missing d3dcompiler update”.
If so, in what time frame ?
I added more information in a new Q&A section. Please take a look at that.
You (MSFT) are talking about “user experience” – sorry, you can’t buy me this way. Our app users expect to install it in ‘click-click-OK’ way, optionally rebooting afterwards. Requiring installation of some prerequisites breaks installation flow, makes their experience bad and requires our support dealing with your (MSFT) shortcomings. We do not expect all our users updating their computers automatically either.
In past we have created installers for our software, which were sometimes usable to fix partially broken computers – because we included/installed/configured anything, even remotely required by our software; we were not relying on unknown state of operating system. Yes, we had to include some system files, which were directly not meant for redistribution, but they were sometimes required to make installer and our software work afterwards.
Looks like now we have to include this DX component (dll files, not KB) into our setup – that is probably not legal and may create problems on target machine, but does make our users experience much better. Or maybe you can redesign your installer after all 🙂
As I understand you mean,
.NET 4.7 deployment with our application will require 2 reboot, and Microsoft will not make responsibility on that :).
You may remake DirectX installation package not to require reboot and make installation of .net 4.7 without multiple reboot, if it not happened you force developers not to use .net 4.7 due that difficulty of deployment.
Please considering to modify .net 4.7 installer or make even 2 option with prerequisites and without its.
Thank you in advance.
It’s really disappointing to see that users still cannot upgrade after clicking yes on the upgrade dialog if they don’t have the required dotnet version installed (the dialog also displays twice…) as search.microsoft.com is always down.
To make it even more annoying testing for installed dotnet versions is nearly impossible without administrative rights because without those you cannot read from HKLM.
“—————————
DotNetTest.exe – This application could not be started.
—————————
This application requires one of the following versions of the .NET Framework:
.NETFramework,Version=v4.7
Do you want to install this .NET Framework version now?”
This has been fixed. Sorry for the delay.
Thanks, that should help a lot of people, for some reason it always appears to go down for sometime when a new mayor .net version is released.
Apologies. This experience goes through a service I maintain and was a pain to update. I re-wrote the service (it’s an ASP.NET Core app running on Azure) recently and it is now much easier to update for new .NET Framework versions. This shouldn’t be a problem going forward.
I have to admit that I also had intermittent problems with the link. I refreshed the page and everything worked.
That DirectX dependency at the framework level doesn’t make any sense.
I can totally understand it being necessary for WPF, but if you don’t care about WPF and just want to use C# 7 or the improved WinForms, it’s still necessary to update the DirectX stuff?
What about servers, which have no need whatsoever for DirectX or WPF?
The dependency is no problem (just one additional file in System32). The problem is the installer not installing this automatically – for no good reason whatsoever.
The dependency is now distributed on Windows Update, so this problem should go away for most people pretty quickly.
I get it that you guys dislike it, that Windows 7 still has the majority marketshare.. but really, making the .NET framework complicated to install won’t solve your “problem” one iota.
Just include the DirectX file into the installer, and let the installer install the file if it’s not already installed on the system. Don’t be such xxxxx on this. There’s no way it’s not possible to do this.
We discussed including this component in the installer. There are two options for doing this and both of them have challenges, which is why we chose instead to deliver the component on Windows Update. The component was originally intended to ship on Windows Update before the .NET Framework 4.7 shipped but that did not happen due to scheduling problems.
The two options are:
– Chain the installers — In this option, the .NET Framework installer chains the DirectX component one. The challenge is that you will need to reboot in the middle if there is already a pending reboot. The user will not be notified and the .NET Framework install will not re-start. This is just the way Windows works and we have no control over that. We considered this option to be a bad experience.
– Include the DirectX component in the .NET Framework — In this option, the DirectX component is included as a binary in the .NET Framework installer. There is no installer chaining or reboot issue. The challenge is that the .NET Framework will need to be updated every time that the DirectX component is updated. It also means that we’ll need to continue shipping this component in the .NET Framework for many years
The first option is quite bad. The second one is more arguable. If we’d known that the component would not be released at the originally planned earlier date, we might have chosen option 2. By the time we realized that the timing wasn’t going to work out, it was too late to switch plans.
“This DirectX component will made available on Windows Update “. You mean : This DirectX component will be made available on Windows Update … ?
Reading this blog, is the High DPI support limited to Windows 10?
Does it work with Windows 8.1 which introduced Per-Monitor DPI?
Does it work with Windows 7?
The High DPI Support we added to Windows Forms directly depends on new features available only in the Windows 10 Creators Update, so yes, the support is mostly limited to Windows 10. You can check out more information about the new in this Channel 9 video: https://channel9.msdn.com/Blogs/dotnet/Introducing-Windows-Forms-HDPI-Improvements-in-NET-Framework-47
FYI, these updates install on Windows Home Server 2011 as well.
Awesome!
Nice, but I use tons of programming languages, For some reason, I like Python better than all, Its clean structure and coding style along with its powerful calculation abilities it is just a nice language, PTVS for 2017 hasn’t been released just yet, I know it is not a Microsoft Language, It takes a lot of coding to make GUI’s in python, maybe Yea can work together and give python a visual environment, for regular windows forms without having to code the crap out of them, there is a visual environment in VS for IronPython/WPF but I desperately want Python/Wincontrols as with C# and VB. I have made my own visual environment with C# as luck would have it code was on a drive that went bad, and I think you could do a better job than me anyway, please make it happen, and of course I would help if needed and possible
https://blogs.msdn.microsoft.com/pythonengineering/
Windows 10 RTM isn’t supported. Will it be in the future?
No, it will not be. Only option is upgrade to a later Win10 version, at least Anniversary Update.
Thank you for the response Rich. That’s a bummer. This prevents me from upgrading an existing application to 4.7 as lots of users still don’t have the Anniversary update. Considering people on Windows 7 SP1 get it without an OS update but not Windows 10 users, that’s disappointing…
If you think of the Windows 10 updates as service packs, then it is just like Windows 7. We don’t support Windows 7 RTM either only SP1. It isn’t exactly the same but it is similar and explains our behavior.
MSDN Team,
Is there any chance where only constructive comments are promoted ? There are plenty of offensive comments which you poor and substandard.
There are plenty of offensive comments those are poor and substandard. ( correction)
Thanks for the feedback! I marked posts as spam that were obviously offensive. I’m sorry that they were there for so long.
will this break old games on windows 7 like windows 10 1607 and later did?
Not to my knowledge. Please tell us if you have problems.
GREAT
I have Windows 10 Enterprise, version 1607 (OS Build 14393.1198). I believe this is anniversary update? Both web installer and offline tell me a newer version of Windows is required.
This should work. Is this still a problem?
Hello everyone,
AFAIK the first release of dotNET 4.7 was the v4.7.02046 with the latest Win 10 (1703). I saw CVE-2017-0248 that tell about a security problem in different versions of dotNET from 3.5 to 4.7. The MS CVE site don’t talk explicitely about the dotNET “GA” which is v4.7.02053 but the security concern has been patched a few days ago for the Win 10 (1703).
Please could one of the devs here tell if the dotNET “GA” v4.7.02053 is already patched ?
With kind regards,
Pim
See this: https://blogs.msdn.microsoft.com/dotnet/2017/05/09/net-framework-may-2017-monthly-rollup/.
.NET Framework on Win10 Creator’s Update needs the fix. .NET Framework on older Windows releases doesn’t, since it came out later.
Can you add System.lynq lib to Collection library? so whenever developer want to query List/Array no need to call System.lynq separately.
Are you talking about adding a using statement or an assembly reference? In VS 2017, default projects have both.
Yes you are right default projects have both. but other than collections are we using System.lynq with any other C# concepts?
if yes other than collection where we are using System.lynq
if no then System.lynq we can add part of System.Collections.Generic;
Please correct me if I am Incorrect.
Feel free to file an issue at https://github.com/dotnet/corefx/issues
Is the .NET framework compatible with Windows 10 Enterprise 2015 LTSB? When I attempt to update from 4.6.2 the installation is blocked with a message the it is not supported on the operating system.
The .NET Framework 4.5.x/4.6.x/4.7 is not supported on this operating system.
System requirements section provides the following:
Windows 10 Creators Update 32-bit and 64-bit .NET Framework 4.7
Windows 10 Anniversary Update 32-bit and 64-bit .NET Framework 4.6.2 .NET Framework 4.7
Windows 10 November Update 32-bit and 64-bit .NET Framework 4.6.1
Windows 10 32-bit and 64-bit .NET Framework 4.6 .NET Framework 4.6.1
This is an embedded system and I cannot change the version of the operating system.
Would the applications compiled with 4.5 as target work as before on 4.7 as well, it worked fine with 4.6 versions, Is there any deprecated or obsolete functionalities in 4.7 from the previous versions that we need to be aware of.
Also in this link https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/startup/supportedruntime-element#version the version attribute for 4.7 is 4.7 itself , till 4.6.2 it was 4.0 which is the CLR verision, does this change mean anything?
Great feedback and find. I made this PR to update the docs accordingly: https://github.com/dotnet/docs/pull/2421.
Yes, 4.5 applications will run on 4.7, just like with 4.6.x. Please tell us if you find any issues.
We don’t deploy monthly rollup previews – can I assume that this directx dependency is now included in the recently released June Rollup (non-preview) ?
Yes, the DirectX dependency is now included in the June Rollup.
Mk… so when will the 4.7 update be available in WSUS, and which product category will it be in?
We have an application which this update would break on one of our servers, but I checked my WSUS today and it doesn’t appear that we’ve received it yet.
Check out the post on .NET Framework 4.7 being released on Windows Update/WSUS: https://blogs.msdn.microsoft.com/dotnet/2017/06/13/microsoft-net-framework-4-7-is-available-on-windows-update-wsus-and-mu-catalog/
If you have an application that doesn’t run with .NET Framework 4.7, please share that with me @ rlander@ms
I have compiled my project (visual studion 2012 – tageting .net framework 4) with msbuild on my dev machine (Windows 7 with installed KB4019990). In production I use Windows 2012 R2 only with .net framework 4.5.2. If I want open the my web service I got the following error message.
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/29942614
Exception: System.ServiceModel.ServiceActivationException: The service ‘/web/Session/WebSessionManager.svc’ cannot be activated due to an exception during compilation. The exception message is: Could not load type ‘System.Diagnostics.Tracing.EventSourceOptions’ from assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.. —> System.TypeLoadException: Could not load type ‘System.Diagnostics.Tracing.EventSourceOptions’ from assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.
at System.ServiceModel.TelemetryTraceLogging.LogSeriveKPIData(ServiceDescription description)
at System.ServiceModel.ServiceHostBase.OnOpened()
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
— End of inner exception stack trace —
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)
Process Name: w3wp
Process ID: 4300
The structure EventSourceOptions is available since 4.6. When I remove the .net framework 4.7 everything works well.
Why is the target .net framework 4 ignored?
To make sure I understand your scenario correctly. You have one development machine, one production machine. The dev machine has Visual Studio 2012 on Win7 installed KB4019990 and .NET v4.7, you compile a project targets .NET v4.0. The production machine Windows 2012 R2 with .NET v4.5.2. On production machine, you got the above error when you ran app, which was compiled on the dev machine with .NET v4.7. If you remove .NET v4.7 from the dev machine, recompile the project, then run the recompiled app on production machine, no issue. Is that right?
System.ServiceModel.TelemetryTraceLogging.LogSeriveKPIData is a new internal functionality implemented in .NET v4.6.2, it uses System.Diagnostics.Tracing.EventSourceOptions, which is implemented in v4.6 as your pointed out. If your production machine has only .NET v4.5.2 installed, either of these code should be on the machine. System.ServiceModel.TelemetryTraceLogging.LogSeriveKPIData shouldn’t be on the call stack at all. However, if somehow the production machine has v4.6.2 or above system.servicemodel.dll on it, it could explain what happens here. Can you check the file version and timestamp of System.Servicemodel.dll and mscorlib.dll on the production machine? I’m wondering if System.Servicemodel.dll has newer file version and later timestamp.
Have you tried to run the app on the dev machine with v4.7 installed?
It would be very helpful if you can share your simple repro project with me for further investigation. You can reach me at Alicial@microsoft.com
I found a the issue in the InstallShield setup from my application. For some reason the installation from a assembly of my application into the gac will be overwrite the system.servicemodel.dll in “C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089” with the version 4.7.
Thank you for your quick response.
I glad that you find the problem. It would be good idea to find out why System.ServiceModel.dll is installed as part of the app installation. Redistributing System.ServiceModel.dll or any .NET Framework assembly with the app is not a good idea in general regardless if it is installed in the GAC or app local, unless it comes with redistributable patch officially from Microsoft. It could cause .NET system inconsistency like this, sometime the problem can be very nasty and hard to diagnose.
Hi,
I have installed using the standalone 4.7 installer on my win 8.1 Enterprise. I am unable to find the option of 4.7 in visual studio 2017. When I go to components list I dont see 4.7 or ever 4.6.2 there. Only have up to 4.6.1?
@Noman, to get the .NET 4.7 targeting in Visual Studio 2017, you can install the 4.7 Dev Pack (https://www.microsoft.com/en-us/download/details.aspx?id=55168) or the latest version of the Visual Studio 2017 version 15.3 – Preview (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes).
Hi, we had a production issue today when 4.7 was installed. We uninstalled it and our .NET application now works again with 4.5 installed (which it was targeted for). I’m unable to work out what caused it to fail but it seems to around establishing a connection to the database server. I’ve seen a similar issue relating to the retry timeout algorithm calculation for mirrored databases during the pre-login handshake but I’m not sure what is causing our application to fail. The top of the exception is shown.
Any help will be much appreciated.
Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was – [Pre-Login] initialization=23864; handshake=11999;
at System.Data.SqlClient…ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, String accessToken, Boolean applyTransientFaultHandling)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)
(cut)
Hi, Albert. Can you please clarify if you’re connecting to Azure SQL Database or an on-premises SQL Server? We added support for TransparentNetworkIPResolution (TNIR) in .NET Framework 4.6, which is enabled by default in the connection string. Can you try disabling TNIR in your connection string (i.e. “false”) to see if that resolves your issue?
Hi,
I’ve been wonderung about Windows version support by .NET installers. It seems you can install .NET one version ahead of the last officially supported Windows version:
– The .NET Framework 4.6 installer download includes “Windows Vista SP2” and “Windows Server 2008 SP2” as supporting operating systems, which the .NET Framework 4.6.1 installer doesn’t (so it seems .NET 4.6 is the last supported version for these Windows versions).
However, you can still install .NET 4.6.1 on Windows Vista SP2 without any problem, whereas the .NET 4.6.2 installer displays “The .NET Framework 4.6.2 is not supported on this operating system”.
– The .NET Framework 4.6.1 installer download includes “Windows 10” as supported operation system, which the .NET Framework 4.6.2 installer doesn’t (so it seems .NET 4.6.1 is the last supported version for Windows 10 Version 1507 (+ Enterprise 2015 LTSB) and Windows 10 Version 1511).
However, you can still install .NET 4.6.2 on Windows 10 Version 1507 (+ Enterprise 2015 LTSB) and Windows 10 Version 1511, whereas the .NET 4.7 installer displays “The .NET Framework 4.7 is not supported on this operating system”.
So it seems when official support for a Windows version is discarded in a .NET version, the installer of that version still allows to install it, whereas the installer of the next version doesn’t.
But does this mean it is a supported configuration to install .NET 4.6.2 on Windows 10 Enterprise 2015 LTSB (or NET 4.6.1 on Windows Vista SP2), in the sense that it will get security updates etc.?
Thank you!
Hi,
The short answer to this is that you should rely on the explicitly mentioned Supported Windows Versions as per the product release blog/KBs OR the lifecycle page for all .NET Framework version (that has the same info), rather than decipher the support policy using setup behavior. Only the mentioned Windows versions are supported and get updates.
Future updates to the lifecycle policy also appear on the lifecycle page: https://support.microsoft.com/help/17455
Thanks,
Vivek Mishra
Hi Vivek Mishra,
thanks, that’s what I suspected.
But couldn’t the .NET installer be adjusted to reject installation if the OS is not officially supported, to avoid users accidentally installing that .NET version?
For example, when .NET 4.6.2 was released, I installed it on a Windows 10 Version 1511 (“November Update”) machine, without realizing that this was actually an unsupported configuration, until I took a closer look to the download description.
What feels also a bit unfortunate to me is that you can install .NET 4.7 on Windows 7 SP1 whose extended support ends 2020, but you can only install .NET 4.6.1 on Windows 10 Enterprise 2015 LTSB whose extended support ends 2025…
I understand that you cannot install a new .NET version on an older non-LTSB Windows 10 version since you must install a new Windows 10 build to stay supported; however as the LTSB editions are supported for 10 years just like earlier Windows versions (Windows 7), I would expect that you can install a reasonably new .NET version on the Windows 10 LTSB editions.
Thanks!