Last Updated: 6/15/2017
Today, we are announcing the release of the .NET Framework 4.7. It’s included in the Windows 10 Creators Update. We’ve added support for targeting the .NET Framework 4.7 in Visual Studio 2017, also updated today.
See Announcing the .NET Framework 4.7 General Availability to learn about and download the .NET Framework 4.7 for other Windows versions and Windows Update.
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
- Performance and reliability improvements
You can see the complete list of improvements and the API diff in the .NET Framework 4.7 release notes.
To get started, upgrade to Windows 10 Creators Update or install the .NET Framework and then install the update to Visual Studio 2017.
Q&A
We’ve had some great questions since publishing this post. Thanks for asking! Here are the answers:
Does .NET Framework 4.7 support .NET Standard?
Yes. It implements .NET Standard 1.6. You can reference .NET Standard 1.0 through 1.6 class library projects from .NET Framework 4.7 projects. The same is true of NuGet packages. You can reference any NuGet package that was built for .NET Standard 1.0 through 1.6.
The .NET Standard 2.0 spec will ship later this year. .NET Framework 4.6.1 and later will support .NET Standard 2.0. At the point that .NET Standard 2.0 class library projects and NuGet packages start being created, you’ll be able to reference them from .NET Framework 4.6.1 or later projects.
Does .NET Framework 4.7 include System.ValueTuple?
Yes. This type is included in the .NET Framework 4.7. You can learn more about the tuple syntax in the New Features in C# 7.0 and What’s New in Visual Basic 2017 posts.
Here are some good examples of projects taking advantage of the new C# syntax: progaudi/MsgPack.Light, chtoucas/Narvalo.NET, aspnet/Microsoft.Data.Sqlite.
You no longer have to reference the System.ValueTuple NuGet package with .NET Framework 4.7 projects. You can continue to reference it or reference projects that reference it. There is a known issue for debugging with the System.ValueTuple package, which will get fixed in an upcoming Visual Studio 2017 update and the next .NET Framework release.
You need to reference the System.ValueTuple NuGet package with .NET Core 1.x and .NET Standard 1.x projects. System.ValueTuple will be included in .NET Core 2.0 and .NET Standard 2.0.
.NET Framework 4.7 is part of Windows 10 Creators Update. What about other Windows versions?
You can start using .NET Framework 4.7 today on Creators Update. Please read Announcing the .NET Framework 4.7 General Availability to install the .NET Framework 4.7 on other Windows versions. The .NET Framework 4.7 will support the same Windows versions as .NET Framework 4.6.2. It is an in-place update.
.NET Framework Documentation
We are also launching a set of big improvements for the .NET Framework docs, today. The .NET Framework docs are now available on docs.microsoft.com. The docs look much better and easier to read and navigate. We also have a lot of navigation and readability improvements planned for later this year. The .NET Framework docs on MSDN will start redirecting to the new docs.microsoft.com pages later this year. Some table of contents and content updates will be occurring over the next few days as we complete this large documentation migration project, so please bear with us.
The docs will show up on open source on GitHub later this week @ dotnet/docs, too! Updating and improving the docs will now be easier for everyone, including for the .NET writing and engineering teams at Microsoft. This is the same experience we have for .NET Core docs.
We also just released a new experience for searching for .NET APIs. You can now search and filter .NET APIs, for .NET Core, .NET Framework, .NET Standard and Xamarin all in one place! You can also filter by version. UWP APIs are still coming. When you do not filter searches, a single canonical version of each type is shown (not one per product and version). Try it for yourself with a search for string. The next step is to provide obvious visual queues in the docs so that you know
Check out the new .NET API Browser, also shown below.
High DPI for Windows Forms
This release includes a big set of High DPI improvements for Windows Forms DPI Aware applications. Higher DPI displays have become more common, for laptops and desktop machines. It is important that your applications look great on newer hardware. See the team walking you through Windows Forms High DPI Improvements on Channel9.
The goal of these improvements is to ensure that your Windows Forms apps:
- Layout correctly at higher DPI.
- Use high-resolution icons and glyphs.
- Respond to changes in DPI, for example, when moving an application across monitors.
See: High DPI Support In Windows Forms documentation.
Rendering challenges start at around 150% scaling factor and become much more obvious above 200. The new updates make your apps look better by default and enable you to participate in DPI changes so that you can make your custom controls look great, too.
The changes in .NET Framework 4.7 are a first investment in High DPI for Windows Forms. We intend to make Windows Forms more High DPI friendly in future releases. The current changes do not cover every single control and provide a good experience up to 300% scaling factor. Please help us prioritize additional investments in the comments and at microsoft/dotnet issue #374.
These changes rely on High DPI Improvements in the Windows 10 Creators Update, also released today. See High DPI Improvements for Desktop App Developers in the Windows 10 Creators Update (a video) if you prefer to watch someone explains the what’s new.
You may want to follow and reach out to @WindowsUI on twitter.
Improvements for System DPI aware Applications
We’ve fixed layout issues with several of the controls: calendar, exception dialog box, checked list box, menu tool strip and anchor layout. You need to opt-into these changes, either as a group or fine-tune the set that you want to enable, giving you control over which HDPI improvements are applied to your application.
Calendar Control
The calendar control has been updated to be System DPI Aware, showing only one month. This is the new behavior, as you can see in the example below at 300% scaling.
You can see the existing behavior below at 300% scaling.
ListBox
The ListBox control has been updated to be System DPI Aware, with the desired control height, as you can see in the example below. This is the new behavior, as you can see in the example below at 300% scaling.
You can see the existing behavior below at 300% scaling.
Exception Message box
The exception message box has been updated to be System DPI Aware, with the correct layout, as you can see in the example below. This is the new behavior, as you can see in the example below at 300% scaling.
You can see the existing behavior below at 300% scaling.
Dynamic DPI Scenarios
We’ve also added support for dynamic DPI scenarios, which enables Windows Forms applications to respond to DPI changes after being launched. This can happen when the application window is moved to a display that has a different scale factor, if the current monitors scale factor is changed, you connect an external monitor to a laptop (docking or projecting).
We’ve exposed three new events to support dynamic DPI senarios:
Ecosystem
We’ve recently been talking to control providers (for example, Telerik, and Grape City) so that they update their controls to support High DPI. Please do reach out to your control providers to tell them which Windows Forms (and WPF) controls you want updated to support High DPI. If you are a control provider (commercial or free) and want to chat, please reach out at dotnet@microsoft.com.
You might be wondering about WPF. WPF is inherently High DPI aware and compatible because it is based on vector graphics. Windows Forms is based on raster graphics. WPF implemented a per-monitor experience in the .NET Framework 4.6.2, based on improvements in the Windows 10 Anniversary Update.
Quick Lesson in Resolution, DPI, PPI and Scaling
Higher resolution doesn’t necessarily mean high DPI. It’s typically scaling that results in higher DPI scenarios. I have a desktop machine with a single 1080P screen that is set to 100% scaling. I won’t notice any of the feature discussed here. I also have a laptop with a higher resolution screen that is scaled to 300% to make it look really good. I’ll definitely notice the high DPI features on that machine. If I hookup my 1080P screen to my laptop, then I’ll experience the PerMonitorV2 support when I move my Windows Forms applications between screens.
Let’s look at some actual examples. The Surface Pro 4 and Surface Book have 267 PPI displays, which are likely scaled by default. The Dell 43″ P4317Q has a 104PPI at its native 4k resolution, which is likely not scaled by default. An 85″ 4k TV will have a PPI value of half that. If you scale the Dell 43″ monitor to 200%, then you will have a High DPI visual experience.
Note: DPI and PPI are measurements that takes into account screen resolution, screen size and scaling. You can use them interchangeably.
You can use Magnifier to help you see if your app is correctly scaling the elements when running on high-dpi monitor, by “zooming-in” to see the pixels.
Take advantage of High DPI
You need to target the .NET Framework 4.7 to take advantage of these improvements. Use the following app.config file to try out the new High DPI support. Notice that the sku attribute is set to .NETFramework,Version=v4.7 and the DpiAwareness key is to set PerMonitorV2.
You must also include a Windows app manifest with your app that declares that it is a Windows 10 application. The new Windows Forms System DPI Aware and PerMonitorV2 DPI Aware features will not work without it. See the required application manifest fragment below. A full manifest can be found in this System DPI Aware sample.
Please see Windows Forms Configuration to learn about how to configure each of the Windows Forms controls individually if you need more fine-grained control.
You must target and (re)compile your application with .NET Framework 4.7, not just run on it. Applications that run on the .NET Framework 4.7 but target .NET Framework 4.5 or 4.6, for example, will not get the new improvements. Updating an the app.config file of an existing application will not work (re-compilation is necessary). You only need to re-compile the application/EXE project. You can continue to use libraries and components built for earlier .NET Framework versions.
WPF Touch/Stylus support for Windows 10
WPF now integrates with the touch and stylus/ink support in Windows 10. The Windows 10 touch implementation is more modern and mitigates customer feedback that we’ve received with the current Windows Ink Services Platform (WISP) component that WPF relies on for touch data. You can opt into the new Windows touch services with the .NET Framework 4.7. The WISP component remains the default.
The new touch implementation has the following benefits over the WISP component:
- More reliable – The new implementation is the same one used by UWP, a touch-first platform. We’ve heard feedback that WISP has intermittent touch responsiveness issues. The new implementation resolves these.
- More capable – Works well with popups and dialogs. We’ve heard feedback that WISP doesn’t work well with popup UI.
- Compatible – Basic touch interaction and support should be almost indistinguishable from WISP.
There are some scenarios that don’t yet work well with the new implementation and would make staying with WISP the best choice.
- Real-time inking does not function. Inking/StylusPlugins will still work, but can stutter.
- Applications using the Manipulation engine may experience different behavior
- Promotions of touch to mouse will behave slightly differently to the WISP stack.
Our future work should address all of these issues and provide touch support that is completely compatible with the WISP component. Our goal is to provide a more modern touch experience that continues to improve with each new release of Windows 10.
You can opt-into the new touch implementation with the following app.config entry.
ClickOnce
The ClickOnce Team made a set of improvements in the .NET Framework 4.7.
Hardware Security Module Support
You can now sign ClickOnce manifest files with a Hardware Security Module (HSM) in the Manifest Generation and Editing Tool (Mage.exe). This improvement was the second most requested feature for ClickOnce! HSMs make certificate mangement more secure and easier, since both the certificate and signing occur within secure hardware.
There are two ways to sign your application with an HSM module via Mage. The first can be done via command-line. We’ve added two new options:
-CryptoProvider <name> -csp
-KeyContainer <name> -kc
The CryptoProvider and KeyContainer options are required if the certificate specified by the CertFile option does not contain a private key. The CryptoProvider option specifies the name of the cryptographic service provider (CSP) that contains the private key container. The KeyContainer option specifies he key container that contains the name of the private key.
We have also added a new Verify command, which will verify that the manifest has been signed correctly. It takes a manifest file as it’s parameter:
-Verify <manifest_file_name> -ver
The second way is to sign it via the Mage GUI, which collects the require information before signing:
Store Corruption Recovery
ClickOnce will now detect if the ClickOnce application store has become corrupted. In the event of store corruption, ClickOnce will automatically attempt to clean-up and re-install broken applications for users. Developers or admins do not need to do anything to enable this new behavior.
API-level Improvements
There are several API-level improvements included in this release, described below.
TLS Version now matches Windows
Network security is increasingly important, particularly for HTTPS. We’ve had requests for .NET to match the Windows defaults for TLS version. This makes machines easier to manage. You opt into this behavior by targeting .NET Framework 4.7.
HttpClient, HttpWebRequest and WebClient clients all implement this behavior.
For WCF, MessageSecurity and TransportSecurity classes were also updated to support TLS 1.1 and 1.2. We’ve heard requests for these classes to also match OS defaults. Please tell us if you would like that behavior.
More reliable Azure SQL Database Connections
TCP is now the default protocol to connect to Azure SQL Database. This change significantly improves connection reliability.
Cryptography
The .NET Framework 4.7 has enhanced the functionality available with Elliptic Curve Cryptography (ECC). ImportParameters(ECParameters) methods were added to the ECDsa and ECDiffieHellman classes to allow for an object to represent an already-established key. An ExportParameters(bool) method was also added for exporting the key using explicit curve parameters.
The .NET Framework 4.7 also adds support for additional curves (including the Brainpool curve suite), and has added predefined definitions for ease-of-creation via the new ECDsa.Create(ECCurve) and ECDiffieHellman.Create(ECCurve) factory methods.
This functionality is provided by system libraries, and so some of the new features will only work on Windows 10.
You can see an example of .NET Framework 4.7 Crypography improvements to try out the changes yourself.
Building .NET Framework 4.7 apps with Visual Studio 2017
You can start building .NET Framework 4.7 apps once you have the Windows 10 Creators Update and the Visual Studio 2017 update installed. You need to select the .NET Framework 4.7 development tools as part of updating Visual Studio 2017, as you can see highlighted in the example below.
Windows Version Support
The following Windows versions will be supported (same as .NET Framework 4.6.2):
- Client: Windows 10 Creators Update (RS2), Windows 10 Anniversary Update (RS1), Windows 8.1, Windows 7 SP1
- Server: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 SP1
A .NET Framework 4.7 targeting pack is available on the .NET targeting packs page.
Closing
The improvements in the .NET Framework take advantage of new Windows 10 client features and make general improvements for all Windows versions. Please do tell us what you think of these improvements.
Update 6/15/2017: Added link for Windows Update release.
Update 5/2/2017: Added support for other Windows versions.
Updated 4/6/2017: Added Q&A section.
Not quite sure why the release notes seem to talk about TLS 1.1/1.2 in WCF Message security. Shouldn’t that be *Transport* security instead?
Personally, I think having those enabled by default would make far more sense, given how often it is being recommended to switch completely to TLS 1.2 overall.
Both WCF Message Security and Transport security support TLS1.1 and TLS1.2. This particular change tracks the fix for Message Security. The fix was quirked in .NET Framework 4.7 for preventing potential compatibility issues when runtime upgrades to .NET Framework 4.7 in production. Hence you would need to intentionally retarget your application to .NET 4.7 to get TLS1.1 and TLS1.2 support by default.
As a user, it’s good to see better High DPI support. As a developer, it’s good to see performance and reliability improvements.
I also like that ValueTuple gets backed in, so we won’t need to add the nuget package to use C# 7’s new tuples anymore.
I added a Q&A at the start that covers tuples. Thanks for reminding me!
What about .NET framework 4.7 support for Windows Embedded 8.1 Industry and Windows Embedded Standard 7? And will Windows 10 Enterprise LTSB 2015 support .NET Framework 4.7?
So, there is no answer for this question? I just found it https://blogs.msdn.microsoft.com/windows-embedded/2015/08/10/microsoft-net-framework-versions-supported-by-windows-embedded-products/ however it no update for long time…
An answer was provided over here: https://blogs.msdn.microsoft.com/dotnet/2017/04/11/net-framework-april-2017-monthly-rollup/
Nice, congrats on the release!
A few questions:
– Why wasn’t there any kind of CTP or beta for this? This is literally the first I’ve heard of .NET 4.7.
– It seems like with .NET Standard and the changes to .NET Core, you guys are a lot closer to being able to sunset the separate “.NET Framework” and make .NET Core the “main” .NET Framework. I can say even though I exclusively use .NET Framework, I really want this to happen as the bifurcated effort has been going on for a few years now and it’s clear innovation in .NET proper is suffering as a result of the need to coordinate from all these separate frameworks. Is there a plan yet for doing this? When will it be communicated publicly?
– I follow the CoreFx repo and I still have basically zero idea what is going on with .NET at any given point in time (thus my prior two questions). As .NET is supposed to be open-source now, is there a way to improve this communication with the community? Perhaps design notes and roadmaps like the language teams are doing?
Good point on the CTP/Beta. Feedback taken.
.NET Core is getting a lot more APIs in .NET Core 2.0 but it is still nowhere near the size of .NET Framework. There are millions of apps that are running on .NET Framework and they will continue to be 5 and 10 years from now. The .NET Framework is like a star with many planets (and comets and asteroids) that orbit it due the gravity that it exerts on them. Awesome analogy, eh? Our customers expect us to continue to improve those apps since they are happy with them as Windows + .NET Framework apps.
So, you can choose to see that as a bifurcated effort and costing us focus on the team. In reality, we work hard to leverage our efforts across .NET Framework, .NET Core and increasingly Xamarin, too. When we build a feature, it costs us 1.25 units of effort (totally made up number) to support it on 3 platforms instead of 1 unit of effort for just 1 platform. I’m very happy with that proposition. Make it once, sell it 3x customers.
Communication could be a lot better. Agreed. We recently created the dotnet/announcements repo: https://github.com/dotnet/announcements. There are not many announcements there yet, but there will be. We also have a design repo planned, too. We’ll announce that at the announcements repo when it shows up.
Great feedback. Thanks.
Thanks for response. Looking forward to seeing the announcements and design repo in action.
The only thing that doesn’t make sense to me is that there still isn’t a plan for .NET Framework and .NET Core (and Xamarin) to become the same thing. My understanding is with .NET Standard, platform specific stuff like WPF, WinForms is allowed. So make all that stuff platform specific, .NET Core compatible and move towards one version. I find it hard to believe the long term plan is really to maintain 3 different frameworks.
It’s already extremely frustrating that the new project format and associated tooling in VS is only available to .NET Core and not .NET Framework. Differences like this in tooling and functionality will only grow over time.
Will there be some pain merging the frameworks? No doubt. But apps that can’t or won’t upgrade will always have the version of .NET they’re already using. Everyone else might have to spend a little time doing compat work to upgrade to the next version, but that’s the price of progress. Apple breaks backwards compat worse than this and gets away with it. You can even make upgrade tools to assist like Apple does.
There isn’t a plan to merge the frameworks but to make it increasingly cheaper to maintain them. We’ve made significant breaking changes in the past, intentional or accidental, and the customer feedback has always been loud and uniform in nature. Merging the frameworks would be super expensive and likely result in unhappiness. Instead, we intend to continue to add value to all the .NET products and make it increasingly easier to move code between them. That’s where .NET Standard and a uniform project format come in.
There is a reason why Microsoft has become pretty successful with large corporate and government customers … because we work harder than almost any other company to keep apps working over long periods of time. I say almost since IBM has a long history of similar, actually even more herculean, efforts. Props to IBM.
> Apple breaks backwards compat worse than this and gets away with it. You can even make upgrade tools to assist like Apple does.
I’m going to go out on a limb here … but I don’t think any of our larger customers wants this. I have never heard a single one ask us to “please break compatibility like Apple”. They do want new and innovative features from us, but they expect all their existing code to work at the same time. It’s often challenging to do both at the same time, but we typically find a way to do it.
We do intend to make .NET Core VS project improvements available to more project types. It will come in later releases. It’s too challenging to invent the improvements for .NET Core and enable it for other project types in the same release, particularly with our short releases.
Part of the problem with breaking changes is lack of proper documentation that “pairs” old api usage with new API usage, often the documentation just states that a particular API has been deprecated without listing necessary forward links and without providing any non-trivial examples for possible rewrites. It is not enough to list a bunch new parameters options and API names without a mapping between old and new. Non-trivial changes has to be documented “both way”.
If the metric 1.25 of work unit is applied, it would make sense to address more in-depth changes across versions and forward code migration paths with the new documentation.
Documentation should not be a DOXYGEN like listing of the API sorted by the implemented code.
Documentation in far too many places describes how to “draw a button” and is too meager for experienced developer with non-trivial API usages, it would help to have explicit prerequisites, assembly and references checklists in the documentation.
It is very handy that 4.x avoids framework installation duplication by mapping 4.0.. forward onto 4.7.
.NET Core & Standard is meant to be cross platform, but how come that it is not possible to support older Windows version with some of new “features” that is a big deal for long time loyal Windows developers ?
Is it then fair to say that there are also no plans to merge Mono either? i.e. maintain 3 separate frameworks.
Right … No plans to merge Mono. That said, the Mono team is ingesting large amounts of source from both corefx and referencesource on a regular basis, so “merging” is kinda happening in a different way. We believe that this approach is the best choice.
The release notes mention:
– Implemented flexibility in specifying Server GC resource consumption. [271883]
Where can I get more information on this?
I updated the release notes with a link to the coreclr repo. Check it out: https://github.com/Microsoft/dotnet/blob/master/releases/net47/dotnet47-changes.md#clr
Could you share some more details regarding Azure connections reliability? What protocol was used before?
@odinserj – See https://github.com/Microsoft/dotnet/blob/master/releases/net47/dotnet47-changes.md#sql
The SQL client code used to try all SQL protocols (shared mem, named pipes, etc) even though it should have been able to tell it was talking to Azure and therefore should only try TCP.
Thanks for HangFire by the way! 🙂
Ah, you are welcome! That’s why I’m asking about connections. Didn’t know there were additional delays due to protocol probing.
Thanks for the hint, Ian! Those release notes are much better to read 😉
I can’t find the edit function on docs.microsoft.com. Seeing that ValueTuple was now in .NET 4.7 made me smile and I went to read the docs to see if there were any quirks.
I happened to spot a typo in…
https://docs.microsoft.com/en-au/dotnet/api/System.ValueTuple?view=netframework-4.7
Create(T1, T2, T3)
Creates a new value tuple with 8 components (a triple).
(8 ==> 3)
No biggie – I was really hoping I could hit “Edit” and fix it but it doesn’t seem like that’s available for all of the docs website yet unfortunately.
“Edit” is coming soon. We don’t have everything in place yet for .NET Framework docs. We are very close to enabling the full open source experience for the .NET Framework docs. I expect it will take another week. Thanks for trying!
What’s this about WPF switching to a new printing API? If I follow the links to PrintQueue and from there to Printing Overview to get a look at the printing API I just get to the XPS printing overview https://msdn.microsoft.com/en-us/library/ms742418(v=vs.110).aspx
There’s nothing telling about XPS printing being deprecated, nor anything about a new printing API. Anyone knows where this is located in the documentation? Or is this deprecation/new API change something specific to creators update and I have to wait for a documentation update?
Check out this page. It is clearer on this point: https://msdn.microsoft.com/library/windows/desktop/dd374565.aspx
Ah, thank you, that indeed clears up my confusion; I was looking at the high level WPF side of printing, not at the low level implementation API which got deprecated/replaced.
Making the WinForms high DPI improvements depend on compilation against .NET 4.7 is a bad move
* we need to abandon Windows 7 support by compiling against .NET 4.7 (only available on Win10-RS2 if I understood it right?)
* we need to wait until all our WinForms third party components provide a non-backwards-compatible 4.7-only build (if ever!)
This will delay adoption of better high DPI support for years. I hope this will be fixed in future updates, having a dependency on everything being compiled against .NET 4.7 is a showstopper since we have a lot of older third party components (some of them didn’t even switch to .NET 4.0 yet because they didn’t want to drop .NET 2.0/3.5 support and running .NET 2.0 code on .NET 4.0 was working just fine).
I hope the situation will be improved in future updates.
It is only available for Win10-CU right now. It is supposed to be available for others later (I guess soon).
At least that is how I read it.
Oh, I must have missed the paragraph that .NET 4.7 will come to other Windows versions later.
That helps a bit, still having to compile every component against .NET 4.7 would be a huge requirement when you depend on third party components.
rereading the article, maybe they can clarify why it needs recompilation? If its just for the manifest then I could recompile my .exe but would get away with having third party components not compiled against .NET 4.7 and still have these third party components get the new high DPI support?
.NET Framework 4.7 itself will be available on Win7 sometime later this spring. The WinForms HDPI improvements however will still require Win10 CU to work. We totally understand the desire to make these improvements available on Win7 however the underlying operating system does not support the features WinForms needs in order to make per-monitor DPI support (Dynamic DPI) available. Additional control behavior improvements may also require underlying Windows OS feature (as in improvements to comctl32.dll for example).
If our app is built against 4.5.2 or 4.6 but 4.7 is deployed, is the backward compat. still guaranteed to keep our application running?
Yes. 4.0, 4.5.* and 4.6.* apps will all run on 4.7. If your app is targeting an earlier version than 4.7, you will not see the High DPI improvements.
I added some updates to the blog post to make this clearer. Couple updates here:
– .NET Framework 4.7 will support the same Windows versions as 4.6.2.
– Only the app/exe needs to be compiled for 4.7. The libraries don’t matter for High DPI. There is a check done at startup that checks: AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName.
Thank you for the clarification!
So to summarize the new information, it looks like once .NET 4.7 is available for all platforms we can compile the application .exe against 4.7 framework and get high DPI improvements on Win10-RS2, but keep running as usual on all older platforms which currently support .NET 4.6.2, with the only additional requirement of installing .NET 4.7
That looks not so bad anymore, thanks again.
Correct.
It is stated in the post that not only the application should be compiled against .NET 4.7 to use High DPI improvements, but should include manifest “that declares that it is a Windows 10 application”. Will this manifest prevent this application from running on earlier Windows versions? If so, .NET 4.7 availability for earlier Windows is not sufficient for applications that want to support it.
Declaring Windows 10 support in the manifest will not prevent the application from running on other OSes. It’s just telling the application that if it is being run on Windows 10, use features that exist in that OS version. You can read a bit more at: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx.
Great!
Is the FX4.7 compliant to netstandard 1.6?
I would guess that the answer is no. I think Microsoft’s current plan is to work on getting Net Standard 2.0 finalized, and getting Net Core 2.0 finished.
hmm, the nestandard implementation table, on the “netstandard1.6” column says “vNext” (4.6 is already netstandard1.5).
If no .net framework version will ever be 1.6, it (1.6) would be a useless version.
Great question. I updated the blog post to cover this (at the top).
Install fails, and yet there is still no proper way to report errors other than through Visual Studio itself which still does not work for me.
It fails to install the .Net Core SDK 1.0.1 claiming that it is already installed. Yet it is not.
Sorry … what install fails?
Visual Studio. Because Core won’t install.
You see loads of people have the problem: https://developercommunity.visualstudio.com/content/problem/40193/visual-studio-2017-update-fails.html?childToView=41055#comment-41055
I logged a bug on git: it seems to have been since fixed: https://github.com/dotnet/core-setup/issues/1973
PS. While you are reading. Although I can report a problem in the VS ‘report a problem’ button, I can never edit any comments on the Developer Community web site. Whenever I sign in I get the error:
“An Internal error has occurred and we are sorry for the inconvenience.
We are doing our best to fix the problem as soon as possible.”
I think there’s something messed up with my account/MSDN subscription.
So happy RegexGroup.Name made it into this release. I’ve been using an ugly reflection hack for years to get around that.
Also, kudos on naming this 4.7 instead of 4.6.3. The minor point releases were really annoying as it makes it harder to remember and discuss with IT what version we need to be on.
Why not 4.6.3 ?
Having .NET _Framework_ specifically for Windows 10 Creator Update is very weird. You definitely should extract WinForms and WPF as separated libraries with their own life-cycles.
Also I didn’t find any info on whether it’s an in-place upgrade or requires specifically targeting and recompilation.
.NET Framework 4.7 is an in-place update and requires specific targeting (it has new APIs). It will be available on the same Windows versions at 4.6.2. I updated the blog post to make this clearer.
Yay!
I have a request (just like everyone else on this page apparently)! Can you guys take ownership of the Chocolatey packages for the framework and targets and keep them updated?
Thanks!
Can you point to the ones you are referencing? I don’t personally use Chocolatey or just mail me at rlander@ms.
The Magnifier tool is actually pretty useless for testing high DPI, because it just does a bitmap scale up. The Magnifier could lead you to believe your app works properly, but it’s not going to look the same with real Windows high DPI scaling.
I updated the text on Magnifier. I oversold it’s use. I believe it is correct now. Thoughts?
I’ve successfully upgraded Windows 10 Pro to build 15063.13, and applied the recent update to Visual Studio 2017 CE. But I don’t see .NET Framework 4.7 as a target in the framework list both in New project (project template) dialog and in Properties for an existing project. (I am able to select build 15063.13 for a UWP app though.) Anyone had a similar experience?
Note: I just checked registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Release key and its value is 707fe (460798) and bound to version 4.7, according to MSDN (Version key value is also correct, I guess: 4.7.02046) – https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx. So it seems that .NET 4.7 is indeed installed, but Visual Studio 2017 with the latest update (checked Extensions and Updates dialog and nothing is available anymore – therefore the yesterday update was correctly applied.)
Same problem here.
So, apparently you need to enable it manually. In VS Installer choose “Modify”, on the right expand “.NET desktop development” and then check “.NET Framework 4.7 development tools”. That did the trick for me.
Yes, you have to make this choice in setup (see the image in the post). You don’t get 4.7 automatically as a target. I’m looking into why that is. That doesn’t seem like the right behavior.
New WPF Touch support: Do I have to target Framework 4.7 to use the new touch system or does it work with target 4.0 on Creators Update when I add the following line?
You do not need to target 4.7. The app.config entries are enough.
From the MSDN entry: https://msdn.microsoft.com/en-us/library/mt800336(v=vs.110).aspx it reads like targeting .NET 4.7 is necessary for the improvements. Can you double check?
.NET Core has a lot of improvements done to the JIT compiler to improve code quality and code performance. I see all these great patches being checking into GitHub/coreclr. Has any of this made its way back to .NET 4.7? This is the most frustrating part about still using the desktop framework, as it is never clear what improvements (at this lower level) are being added or taken from coreclr/corefx repositories. It FEELS like the .NET desktop framework is just not getting the same love and attention as .NET Core.
Yes, a bunch of .NET Core JIT improvements are in 4.7. The team is sharing them with me. I’ll add them to the release notes next week. I already added a link for the GC change, to .NET Core.
.NET folks could you please expand on what JIT improvements are in 4.7? Interesting to know.
Are there benchmarks or numbers for perf increase when you move an mvc 5.x project from 4.6.2 to 4.7?
We don’t have any benchmarks to share. I’ll aim to make that happen in the future when a new .NET Framework release includes performance-related improvements.
You said that 4.7 is coming for other versions “soon”. Any hints as to whether that’s days, weeks, a month or so?
It is weeks. More than 3, less than 10 and hopefully closer to the first number. We have some quality-related process to still go through to get the release ready. This week’s release was one Windows version. We now have to get the product ready to ship for nearly over a dozen different variations.
In the closing comment, you say the new version “makes general improvements for all Windows versions”. For those of us not using Win 10, what are some of those improvements that are not W10 -specific?
Look here: https://github.com/Microsoft/dotnet/blob/master/releases/net47/README.md
If you skip Windows Forms and WPF, you have your answer. Very few other things were Windows 10 specific.
I have Creators Update and latest VS version (15.1 26403.0). However, I don’t see .NET Framework 4.7 in dropdown list.
Figured it out.
I’d be interested to know what prompted this change: “Changed the background color of property grid lines to provide an 8:1 contrast ratio for high contrast themes. [225121]”
Sadly, PropertyGrid uses the same color not just for grid lines, but also for the left border and category names background. As a result, all property grids using default colors now look… well, rather ugly.
We have the same problem, the PropertyGrid now really looks strange on Windows 10 Creators Update.
Before: https://picload.org/image/rcdcagwl/propertygrid-before.png
After: https://picload.org/image/rcdcagwa/propertygrid-after.png
Is there a way to restore the previous behavior or to manually set these colors?
Thanks!
We made the change in order to comply with industry standards (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) around Accessibility in High Contrast scenarios and the resulting default color scheme changes did impact Visual Studio but were consistent with the colors chosen there. We appreciate your feedback around your scenarios and will consider making changes in a future release.
I second Cc’s comment. The PropertyGrid control looks super dark and ugly now in a normal (non-High Contrast) mode. I’ve used it in a couple of end-user-facing applications, and it’s a dramatic and terrible looking change when a system is updated to .NET 4.7. Please give us some way to revert this behavior without requiring us to recompile and target .NET 4.7.
The PropertyGrid’s LineColor property is still tagged with the DefaultValue(typeof(Color), “InactiveBorder”) attribute. But if the LineColor property isn’t explicitly set in .NET 4.7 it will actually use ControlDark instead of InactiveBorder as its ambient value. 🙁
If you explicitly set the LineColor property to SystemColors.InactiveBorder at run-time, then the control will respect that and use the InactiveBorder color like it used to. Fortunately, all of my apps use an ExtendedPropertyGrid control I made that inherits from PropertyGrid, so I only had to add “this.LineColor = SystemColors.InactiveBorder;” into its constructor to get all of my property grids looking nice again.
This was an easy change for me, but I already hate looking at the PropertyGrid in other .NET 4.7 apps. For example, did anyone look at VS 2015’s or 2017’s Tools –> Options dialog for pages that use PropertyGrid DialogPages (when running on Win10 Creators Update, of course)? Some examples for options pages that are super dark now are: “Business Intelligence Designers”, “Data Factory”, “Microsoft Team Foundation Server 2015 Power Tools”, “PowerShell Tools”, “Text Templating”, and “Windows Forms Designer”.
FYI: The team is taking another look at this one. We have asked both Microsoft accessibility and designer folks to help us make a better choice. Accessibility shouldn’t come at the cost of aesthetics.
@Rich
Sure you’re allowed to call UWP “touch first”?
There are many high ranking MSFT officials not stopping to claim that UWP is ready for new Desktop Apps and we all should start to shift our code bases in it’s direction. Why would we move to something “touch first”?
This was a bad choice of words, going back to earlier phrasing. The main point is that UWP has touch as a first-class experience from its initial design. Clearly, for UWP, keyboard and mouse have to first-class, too. I’m a keyboard-first individual, so I’m right there with you.
Is there anything I can do in my windows machine for app like Sqlyog to get it worked on Windows 10 at 125% well. I am not sure if I have this problem earlier in my life.
any idea how I can fix this issue.
I’d have to have a better idea of what is going wrong in the application and what they’re seeing. The screen shots of the app seem to be Winforms but I don’t know if the software vendor has implemented HDPI scaling support or not. My advice would be to contact the vendor for support.
It’s great to have the non client area and child dialogs correctly scaling in WPF.
Unfortunately, we are currently experiencing an issue with spell checking which has occured after update to .NET 4.7 as described here:
https://github.com/Microsoft/dotnet/issues/376
https://social.msdn.microsoft.com/Forums/vstudio/en-US/16f8b757-ce23-42c9-a503-daa748a989f3/
This appears to be a regression.
The new touch setting (Switch.System.Windows.Input.Stylus.EnablePointerSupport=true) breaks double clicking with the finger:
https://connect.microsoft.com/VisualStudio/feedback/details/3129181/problem-with-wpf-listview-on-touch-screen
It also doesn’t work correctly on High DPI displays: For example the StylusSystemGesture event is send to the wrong UIElement.
Please make a possibility to choose English language in Visual Studio Installer. I have a Russian Windows 10, and so VS Installer shows in Russian, but I need tools only in English. For example, I spent 30 minutes trying to figure out how to switch on .NET 4.7 support using your english example, which is not the same at all.
Is there a link to more information about the ClickOnce updates?
For the Store Corruption Recovery, does the application installed via ClickOnce have to target the 4.7 framework? Or, does the ClickOnce deployed app just need to be running on a machine with the new framework installed?
The application does not need to target .NET Framework 4.7 for this. You are correct – .NET Framework 4.7 does need to be running on a machine in order for ClickOnce to attempt to automatically recover.
Hi, we are a group of student and we have a project that we need to develop a new (small)language. We can target any run time. we found a lot information about `developing a new language that targets JVM` and plentty of tools like; Ohm, Xtext and Xtend. + a lot of reading about Groovy, Kotlin or some other languages being developed for JVM .
But , all students in our group have .NET knowledge and background and we would like to develop something that can benefits CLR( especially CLRCore). We could not find any documentation or info anywhere how to develop a small DSL language that targets CLR especially CoreCLR for having cross platform support.
There is only one book out there and it is very old.
http://www.apress.com/us/book/9781590591345
any advice is greatly appreciated.
Thanks
Hi, Hussein. You might like to look at the Dynamic Language Runtime which is a set of APIs that enable you to implement dynamic languages. Often DSLs are more dynamic in nature vs. static typing, though you can use the DLR for static languages too.
From this page: http://dlr.codeplex.com/wikipage?title=Docs%20and%20specs&referringTitle=Documentation
Take a look at this walkthrough that constructs a dynamic language soup to nuts (doesn’t walkthrough the lexer) using the DLR:
Word: http://www.codeplex.com/Download?ProjectName=dlr&DownloadId=74709
PDF: http://www.codeplex.com/Download?ProjectName=dlr&DownloadId=127519
If you decide to go this route, you will want to see the expr tree doc on that page too. These are the same expression trees used by the C# compiler when you create LINQ queries, but they have been expanded to support control flow and more than just expressions.
All the code that implements the Sympl example language (in C# or IronPython) is here: http://dlr.codeplex.com/SourceControl/latest#DLR_Main/Runtime/Samples/sympl/
I hope that helps.
Bill
Thank you Bill, the C# example is very nice and We will also look at Phillip’s suggestion so we now have a good starting point.
Hey Hussein,
Bill mentioned the DLR which is a great start. Another alternative is using F# and FPParsec.
FPParsec is one of, if not the best, options for creating a DSL on .NET: http://www.quanttec.com/fparsec/
Building a proper parser generator is very difficult unless you use tools like the above. Both the tutorial and User’s Guide have extensive documentation and samples. There are also a lot of people in the F# community who are experts with FPParsec, so it’s quite easy to get help. Hopefully this helps!
Thank you some much Phillip, that is really helpful.
@Rich Lander [MSFT] – Thank you. Good to know that .Net Framework 4.6 is not a dead end and detour to .Net Core, any updates on the future of WCF supporting the rest hateoas in built to this framework space?
Hello,
I installed Windows 10 Creators Update and .NET 4.7. But it seems that all my existing ASP.NET MVC web-sites running from .NET 4.5.2 to 4.6 have started raising the following error:
Index was outside the bounds of the array.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IndexOutOfRangeException: Index was outside the bounds of the array.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[IndexOutOfRangeException: Index was outside the bounds of the array.]
System.Web.PipelineStepManager.ResumeSteps(Exception error) +1780
System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb) +121
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +483
May I know if this is a known issue? At this point, my machine is dead-in-the-water.
Thanks.
Deepak Gupta
FYI for anyone else running into this issue, I resolved it by uninstalling and then reinstalling IIS.
I’m keen to test the time in using the azure database connection with tcp/ip, see if it really is faster..
Why .Net 4.7 is not available as a redistributable installation? What is the timeline this will be available? We want to leverage the High DPI support for one of our Windows Forms application but our end users are not in Creators Update yet.
See the Q&A at the start of the post. We’re working on the redistributable install and we hope that it will be available in May, but definitely first half of the year.
What happens to the owner user who does not like asp.net von that steal information change settings to keep owner from changing a free enviroment. Tech IT which one of you steals from a broad band user has had her personal as in Medicare and social security bank history army history home of record reports. Find me and good reason why you can’t use civilians like me for practice report echo logman back marvel malate trace WiFitri@microsoft.com report investigate. Do pass this on to the right security tech
Hurry IT I’m getting bored waiting to file a late tax and pay my bills CAPICE
I’m sorry but I don’t know what you are asking for.
Does .NET Framework 4.7 include System.ValueTuple? Yes. This type is needed to use the new C# 7 tuple language syntax.
And what about the new Visual Basic.NET 15 tuple language syntax?
Good point. I updated the Q&A at the start of the post to better cover this. Look there.
Tuples are in VB15. Here is the post on VB15: https://blogs.msdn.microsoft.com/vbteam/2017/03/30/whats-new-in-visual-basic-2017/.
Thank you! It helped.
We have software in the field targeting the .NET framework 4.0 (WPF) that is failing after the Win 10 Creators update. Specifically, using .ShowDialog() more than once seems to crash and also a Windows forms DateTimePicker wrapped by WindowsFormsHost control in WPF no longer works after the update. Where would be the best place to discuss these issues? For the moment, we have to recommend to clients to not install the update or roll it back.
Please send mail to rlander@ms – we can figure out what is going on. Thanks for reporting!
We have a c# User Control .dll which we call from a vb6 app. With the .NET 4.7 we encounter the following error when we call the .dll “wrong number of arguments or invalid property assignment”.
Rolled back the Windows upgrade which reinstated 4.61 and the problem goes away.
Help would be appreciated as we have a large number of clients out there and it will be a disaster as these client have their windows updated.
Please send mail to rlander@ms – we can figure out what is going on. Thanks for reporting!
Please can I have your full email address
Still no email address tried rlander@ms.com no luck please paste a link.
Still waiting getting very frustrated
try microsoft.com
Thank you that worked.
Still waiting Rich no answer yet????
We have a Sitefinity 5 webapp that no longer functions once the Windows 10 Creators Update was installed.
Why do MS CONTINUALLY force feed us updates that break things? If you want to install a new .NET Framework, fine. But don’t overwrite a WORKING .NET 4.6 install!
FFS. More time down the drain.
Please send mail to rlander@ms – we can figure out what is going on. Thanks for reporting!
Daniel I also have problems witth Sitefinity, what error do you get? MS we need this fixed ASAP…
I’m getting this at Sitefinity startup:
The type initializer for ‘Telerik.Sitefinity.Security.SecurityManager’ threw an exception.
Daniel – also in the same boat, except with a Sitefinity 9.x install. Won’t start. Rolling back the Creators update is the ONLY way to get it working again right now.
My error is:
“The type initializer for ‘Telerik.Sitefinity.Security.SecurityManager’ threw an exception.”
When are the releases for the other Windows versions coming? I would really love to see 4.7 in my production environment – but i am running Windows Server in different versions on the machines. A redistributable offline installer would make my life even easier – it was some kind of pain doing the update on 20 Dev machines and then updating and modifying the VS2017 install.
Thanks – and please keep up the great work on .NET and C# – i love it.
Microsoft .NET Framework 4.7 (Offline Installer) for Windows 7 SP1, Windows 8.1, Windows 10 Anniversary Update, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016
https://www.microsoft.com/en-us/download/details.aspx?id=55167
Is net framework 4.7 work in windows 7 32bit i3 4gb ram ?
So this is frustrating. I have installed 4.7 successfully on my W10 dev machine. VS2017 did not list 4.7 in the list of targets when I tried to create a new project,
Hmm, ah install W10 Creators Update…Ok lets do that…Oh No…W10 Update Assistant says W10 will not run on this PC
What!!!!!
Tell me how can I develop to 4.7 using VS2017 ?
Install the .Net 4.7 Developer Pack
microsoft lost it long time ago at the time you promoted html5 over silverlight instead of just merging silverlight/wpf and create a true multiplatform sdk..
since then you destroyed the whole .net community that was very active on their own and it’s really sad..
i’m fed up with your crap.. FED UP! You hire the worst people, liberals retards who have no visions
I can even start to list all the points because WHAT’S THE POINT?
we will have to wait another 5years to have something stable, one api & one code base for all platform hahaha so pathetic.. You cant even have one api for all version of windows
you even have another one that break way of doing things in wpf > xamarin
no untyped data template.. are you fucking kidding me..
the only reason we stay is because .net is use a lot in entreprises but we would never ever stay if the market was half and half.. of course now you even added html5 so we have to learn this to if we want jobs in .net.. FED UP!! you are insane
and why the f. can’t we edit our comments on your website? how retarded can you be? we are not in 1995
you are insane of pushing your .net framework like 4.6.2, 4.7 only on big updates like creator..
i really dont understand the way you work, your “big” update better be f. stable and without any exploit or you’ll get sued
personnaly you should have a second very secure windows update only for OS sdks like .net.. and all .net framework should be instable on all windows version
UWP and WPF need to be unified NOW not tomorrow NOW.. and later merge xamarin into it.
you mix everything togheter so you force people to update to creator to have the 4.7.. hence if the creator have bugs you impose potential bugs and exploit on your own customers
.NET Framework 4.7 is not only included in Windows 10 Creators Update, but also available for Windows 7 SP1 and above OS platforms. Please refer to this blogpost for details – https://blogs.msdn.microsoft.com/dotnet/2017/05/02/announcing-the-net-framework-4-7-general-availability
Since installing .net 4.7, stepping into .net source-code isn’t working anymore for System.Windows.Forms.dll. The symbols (*.pdb) are found (…\SymbolCache\MicrosoftPublicSymbols\System.Windows.Forms.pdb\fbc5c24779694d94943cc680b759738f1\System.Windows.Forms.pdb) and the function-names are visible in call-stack, but if one clicks on it, there is a message that debug informations doesn’t contain source-code-informations.
Thats a problem for us because we are trying the new high-dpi-features for winforms and we found some strange behaviours. So we need to know how the scaling-functions in winforms are working exactly.
Was planning to migrate an existing WebForms project to 4.7 later this year for the DPI support, but it looks like there may be an issue. One of our Win7 machines was updated, at which point a 3rd party WPF application targeting 4.6.2 stopped working. It tossed a COMException at MS.Win32.Penimc.UnsafeNativeMethods.CoCreateInstance. Downgrading back to 4.6.2 fixed the problem. This has also been reported with Quicken users:
https://getsatisfaction.com/quickencommunity/topics/-net-4-7-update
And some software I’ve never heard of called Mailwasher:
http://forum.firetrust.com/viewtopic.php?f=50&t=21527
Only a smattering of reports so far when you google it, but there definitely appears to be an problem.
Thanks for reporting. We are currently investigating an issue that may be this same one. In any case, we are investigating the issue now.
John – would be great if you could reach out to us so that we could ask you some more questions. Please reach out to me at rlander@ms.
Is there any mention to changes to how HttpContext.Current.Session or HttpContext.Current.Cache is impacted by the .NET 4.7 upgrade?
We have a solution which started throwing null reference exceptions after installing the update, rolling the update back resolved the issue.
Hi Chris. There were internal changes made, but there should not be any regression in these areas. Could you provide more details about your solution? What version of the framework were you updating from? Can you post the exception details and stack trace?
Hi Stephen,
I don’t have exception details to provide now as the issue was resolved in production by uninstalling the update and rebooting.
The part of the solution failing was a ASMX web services method now running in .NET 4 that uses those two HttpContext objects to store program information. It appears .NET 4.7 changes the behavior of the session in a way that no other version of .NET did as this project was initially .NET 2.0 and later compiled against .NET 4.
Thanks,
Chris
In Visual Studio 2015 and 2017, I can get “Target framework” dropdowns to be 4.7 . How do I get 4.7 as a choice on the “Publish” tab’s “Prerequisites” button list?
Hi Eric,
You can get the .NET 4.7 in Prerequisites of VS 2015 by installing the 4.7 Dev Pack (https://www.microsoft.com/en-us/download/details.aspx?id=55168).
For VS 2017, the same option will be made available in future version of Visual Studio 2017 updates. But, as a workaround you can make the same to appear by copying the VS 2015 ‘DotNetFX47’ folder to Microsoft SDKs location, after installing the 4.7 Dev Pack.
Copy folder ‘DotNetFX47’ from “…\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper\Packages\”
to “…\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\”.
Thanks,
Vivek Mishra
This did not work for me. I assume you have to have Visual Studio 2015 installed for the Dev Pack to install the prerequisite into it? This pretty freaking ridiculous. How hard is it to just release the Click Once package?
Even after installing Visual Studio 2015, I was able to get access to the DotNetFX47 folder and copy it to Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\, but Visual Studio 2017 doesn’t recognize it.
Any links or further info regarding the Mage.exe HSM improvements? It doesn’t currently work with a SafeNet device when calling -Update. Fails with “-Sign command requires on of -CertFile or -CertHash”.
MageUI.exe does not work either with a SafeNet token. Shows the CSP but not the container. Manually adding the container produces “path was not in legal form” error.
Posted this question to the MSDN forums:
https://social.msdn.microsoft.com/Forums/en-US/91e74b1f-d82e-4313-86b0-f481264fbc84/mageexe-net-47-hardware-security-module?forum=csharpgeneral
I replied to the MSDN forum, copying here for completeness sake.
4.7 version of Mage tools works only with private keys from the user store when accessed via the CSP, public key file and private key container name combination. In the next version we added support for machine key store. Error messages that you posted are consistent with this bug. Is your key stores in the user or machine store? Could you please verify it on 4.7.1 version of the .Net SDK when it’s available?
Thank you, Tanya
There are conflicting statements which I feel need clarification. “You can reference .NET Standard 1.0 through 1.6 class library projects from .NET Framework 4.7 projects.” and ” .NET Standard 2.0 class library projects and NuGet packages start being created, you’ll be able to reference them from .NET Framework 4.6.1 or later projects.”.
The first statement limits .Net 4.7 to 1.0 through 1.6.
The second statement says Standard 2.0 for 4.6.1 and later which would include 4.7.
So can Standard 2.0 be referenced by .Net 4.7 or not?