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.

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

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.

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

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.

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.

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.

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.

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?

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

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 ?

11 months ago

James Urry

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.

“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!

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?

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

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

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.

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

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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!

@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?

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.

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.

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

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.

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

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:

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?

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.

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.

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.

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?

Thanks , I have just been looking for information about this
subject for a while and yours is the greatest I’ve came upon so far.
However, what concerning the conclusion? Are you positive
about the source?