I got an interesting email today. The author said 'I have a problem consuming a.net core class library in a winforms project and can't seem to find a solution.' This was interesting for a few reasons. First, it's solvable, second, it's common, and third, it's a good opportunity to clear a few things up with a good example.

To start, I emailed back with 'precision questioning.' I needed to assert my assumptions and get a few very specific details to make sure this was, in fact, possible. 'What library are you trying to use? What versions of each side (core and winforms)?

What VS version?' The answer was 'I am working with VS2017. The class library is on NETCoreApp 1.1 and the app is a Winforms project on.NET Framework 4.6.2.' Let's solve it.

Xcode Linked Frameworks And Libraries

Referencing a.NET Core library from WinForms (running.NET Full Framework) Before we parse this question. Let's level-set.NET is this big name. It's the name for the whole ecosystem, but it's overloaded in such a way that someone can say 'I'm using.NET' and you only have a general idea of what that means. Are you using it on mobile?

Let's consider that '.NET' as a name is overloaded and note that there are a few 'instances of.NET'.NET (full) Framework - Ships with Windows. Runs ASP.NET, WPF, WinForms, and a TON of apps on Windows. Lots of businesses depend on it and have for a decade. Super powerful.

Non-technical parent maybe downloads it if they want to run paint.net or a game.NET Core - Small, fast, open source, and cross-platform. Runs not only on Windows but also Mac and a dozen flavors of Linux. Xamarin/Mono/Unity - The.NET that makes it possible to write apps in C# or F# and run them on everything from an iPad to cheap Android phone to a Nintendo Switch. All of these runtimes are.NET. If you learn C# or F# or VB, you're a.NET Programmer.

If you do a little research and google around you can write code for Windows, Mac, Linux, Xbox, Playstation, Raspberry Pi, Android, iOS, and on and on. You can run apps on Azure, GCP, AWS - anywhere.

What's.NET Standard?.NET Standard isn't a runtime. It's not something you can install. It's not an 'instance of.NET.' .NET Standard is an interface - a versioned list of APIs that you can call. Each newer version of.NET Standard adds more APIs but leaves older platforms/operating systems behind.

The runtimes then implement this standard. If someone comes out with a new.NET that runs on a device I've never heard of, BUT it 'implements.NET Standard' then I just learned I can write code for it. I can even use my existing.NET Standard libraries. Now, you could target a runtime - a specific.NET - or you can be more flexible and target.NET Standard. Why lock yourself down to a single operating system or specific version of.NET? Adobe indesign cs5 for mac. Why not target a list of APIs that are supported on a ton of platforms?

The person who emailed me wanted to 'run a.NET Core Library on WinForms.' Tease apart that statement.

Javascript Libraries And Frameworks

What they really want is to reuse code - a dll/library specifically. When you make a new library in Visual Studio 2017 you get these choices. If you're making a brand new library that you might want to use in more than one place, you'll almost always want to choose.NET Standard.NET Standard isn't a runtime or a platform. It's not an operating system choice.NET Standard is a bunch of APIs.

Optional Libraries Frameworks And Applications For Machine Learning

Next, check properties and decide what version of.NET Standard you need. You can find them at The API browser has all the.NET Standard APIs versioned. You can put the version in the URL if you like, or use this nice interface.

You can check out, for example, and see all the namespaces and methods it supports. It works on Windows 10,.NET Framework 4.6.1 and more. If you need to make a library that works on Windows 8 or an older.NET Framework like 4.5, you'll need to choose a lower.NET Standard version. When choosing a.NET Standard version, you should consider this trade-off:. The higher the version, the more APIs are available to you. The lower the version, the more platforms implement it.

In general, we recommend you to target the lowest version of.NET Standard possible. The goal here is reuse. You can also check out the and run it on your existing libraries to see if the APIs you need are available.NET Standard is what you target for your libraries, and the apps that USE your library target a platform. I emailed them back briefly, 'Try making the library netstandard instead.' They emailed back just a short email, 'Yes! That did the trick!'

Sponsor: Big thanks to! Don't rely on your users to report the problems they experience. Automatically detect, diagnose and understand the root cause of errors, crashes and performance issues in your web and mobile apps. Great explanation, Scott, thank you. I'm looking for some resources that explain how the new compat shims work, which - I think - allow a NETStandard library author to reference libraries/packages that haven't yet explicitly been targeted to NETStandard (but would otherwise meet the spec of the parent NETStandard library). Heard Immo Landwerth mention these at.NET Fringe, but a quick search didn't turn up much.

Perhaps it's a feature of the 2.0 tooling and not yet fully documented? Or perhaps I can learn how to better google something with bing for myself. What I don't understand is that ASP.NET Core MVC libraries depend on Standard 1.6.

According to the.NET Standard version table, Standard 1.6 is not supported on Framework 4.6.1, however I can (thankfully) target an ASP.NET Core app to run on Framework 4.6.1. This allows me to pull in Framework 4.6.1 based libraries, for functionality that isn't supported in.NET Standard 1.4. However, if I want to include NuGet package Microsoft.AspNetCore.Mvc.Core, I cannot import this in a Standard 1.4 library, because it depends on Standard 1.6. And I cannot upgrade to Standard 1.6, because I cannot reference a Standard 1.6 library form a host app that targets Framework 4.6.1.

Unfortunately that library includes a very important interface: IActionContextAccessor. However, I can change the library to Framework 4.6.1, depend on the NuGet package becase it can also target Framework 4.5.1, and then reference that in the host app? But in future, when 2.0 tooling is released (still in preview) then it's possible to refer to a Standard 1.6 library from a Framework 4.6.1 host application.

Important If you are using Python from a python.org 64-bit-only Python installer for macOS 10.9 and later, no further action is needed to use IDLE or tkinter. A built-in version of Tcl/Tk 8.6 will be used. If you are using Python (prior to 3.7) from a python.org 64-bit/32-bit Python installer for macOS 10.6 and later, you should only use IDLE or tkinter with an updated third-party Tcl/Tk 8.5 (not 8.6), like installed.

If you are using macOS 10.6, do not use IDLE or Tkinter from the Apple-supplied Python 2.6.1 in macOS 10.6. If possible, install and use a newer version of Python and of Tcl/Tk. If you are using macOS 10.7 or later, the Apple-supplied Tcl/Tk 8.5 still has serious bugs that can cause application crashes. If you wish to use IDLE or Tkinter, install and use a newer version of Python and of Tcl/Tk. Python's integrated development environment, and the it uses, depend on the which is not part of Python itself.

For best results, it is important that the proper release of Tcl/Tk is installed on your machine. For recent Python installers for macOS downloadable from this website, here is a summary of current recommendations followed by more detailed information. Python Release Installer Variant macOS Release Recommended Tcl/Tk Alternate Tcl/Tk Not Recommended all 10.6 to 10.14, 64-bit-only 10.9 to 10.14, 64-/32-bit 10.7 to 10.14 10.6. Tk On macOS There are currently three major variants of Tk in common use on macOS: Aqua Cocoa Tk A newer native implementation available as a universal 64-bit and 32-bit binary. This variant is the standard native macOS variant in Tk 8.6 and as of Tk 8.5.13.

Aqua Cocoa support was backported to Tk 8.5 (prior to 8.5.13) and released by Apple starting with macOS 10.6 and by ActiveState starting with their 8.5.9.1 release. Aqua Carbon Tk Because it is implemented with older macOS Carbon interfaces, it is only available as a 32-bit binary (usually for Intel and PowerPC processors). Aqua Carbon Tk 8.4 is included with macOS releases 10.4 through 10.14 and is also available from ActiveState. Aqua Carbon variants of Tk 8.5 had been available as an ActiveState Community Download prior to ActiveTcl 8.5.9. As of 8.5.13, the Tk project no longer supports Carbon builds of Tk 8.5.

32-bit-only Python installers downloadable from this website for older Python releases were linked with Aqua Carbon Tk 8.4. X11 Tk The traditional platform-independent UNIX Tk implementation which requires an X11 server, such as the Apple X11.app available as an optional component in all recent macOS releases.

64-bit and 32-bit binaries can be built. While the Python installers downloadable from this website do not support X11 Tk, other distributors of Python for macOS may do so.

ActiveTcl 8.5.18.0 ActiveState provides binary distributions of Tcl/Tk which are upward compatible with and generally more up-to-date than those provided by Apple in macOS releases. This version of Tcl/Tk includes fixes for some critical problems that you may encounter using tkinter or IDLE (see below). You can download an installer for this release from. Note that ActiveState Community Edition binaries are not open source and are covered by an ActiveState license. You should read the license before downloading to verify that your usage complies with its terms of use. This is an Aqua Cocoa Tk.

Apple 8.5.9 This release is included in macOS 10.7 through at least macOS 10.14. As of this writing, there are at least two known issues with Tk 8.5.9 that are present in Apple 8.5.9 Tk but fixed in more recent upstream 8.5 releases. The more serious problem is an immediate crash in Tk when entering a composition character, like Option-u on a US keyboard. (This problem is documented as.) There is also the more general problem of input manager support for composite characters which has also been fixed in more recent Tcl/Tk 8.5 releases. You can avoid these problems by using a current python.org installer that links with or by using a third-party distribution of Python that does not use Apple 8.5.9 Tk. This is an Aqua Cocoa Tk. Note While Tcl and Tk are separate frameworks and libraries, they are closely related and are normally installed or updated simultaneously.

You should not attempt to mix-and-match Tcl and Tk versions. References to a specific version of Tk assume the corresponding version of Tcl is installed as well. The Python for macOS installers downloaded from this website dynamically link at runtime to Tcl/Tk macOS frameworks.

The Tcl/Tk major version is determined when the installer is created and cannot be overridden. All python.org installers for Python 3.7.x and 64-bit-only macOS installers for Python 3.6.x and 2.7.x link to their own built-in Tcl/Tk 8.6 frameworks and do not use external Tcl/Tk frameworks. The Python 64-bit/32-bit macOS installers for Python 3.6.x and and 2.7.x dynamically link to Tcl/Tk 8.5 frameworks. The dynamically linking occurs when tkinter (Python 3) or Tkinter (Python 2) is first imported (specifically, the internal tkinter C extension module).

By default, the macOS dynamic linker looks first in /Library/Frameworks for Tcl and Tk frameworks with the proper major version. This is the standard location for third-party or built from source frameworks, including the ActiveTcl releases. If frameworks of the proper major version are not found there, the dynamic linker looks for the same version in /System/Library/Frameworks, the location for Apple-supplied frameworks shipped with macOS. (Note, you should normally not modify or delete files in /System/Library.) As is common on macOS, the installed Pythons and the Tcl and Tk frameworks are built to run on multiple CPU architectures ( universal binaries) and across multiple macOS levels ( minimum deployment target). For Python to be able to dynamically link with a particular Tcl and Tk version, the available architectures in the Tcl/Tk frameworks must include the architecture that Python is running in and their minimum deployment target should be no greater than that of Python.