CefSharp 51 requires .NET 4.5.2

[robinrodricks]

CefSharp 43 required .NET 4.0. The CefSharp site also says .NET 4.0 is enough. Suddenly with CefSharp 51 it becomes mandatory for user apps to use .NET 4.5.2. This is not possible since I cannot guarantee all client PCs will have .NET 4.5.2. Is it possible for CefSharp 51 and newer to be built with .NET 4.0? What newer .NET features are required?

• What version of the product are you using?
  • 51, trunk branch, downloaded from NuGet on 2016/08/28
• What architecture x86 or x64?
  • x64 PC, building a x86 project
• On what operating system?
  • Win7 x64
• Are you using WinForms, WPF or OffScreen?
  • WinForms
• What steps will reproduce the problem?
  • Create a new .NET 4.0 project
  • Add 3 CefSharp DLL refs
  • Copy all CefSharp stuff into bin (I don't use NuGet)
  • Build
• What is the expected output? What do you see instead?
  • Expect it to compile with .NET 4.0
• Please provide any additional information below.

[amaitland]

The CefSharp site also says .NET 4.0 is enough.

The official list of releases is https://github.com/cefsharp/CefSharp#release-branches

.Net 4.5.2 is the lowest version supported by Microsoft. Either use an older version or choose a different CEF wrapper.

[amaitland]

What newer .NET features are required?

https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-ending-for-the-net-framework-4-4-5-and-4-5-1/

[MoonStorm]

Please lower the requirements if the wrapper isn't using anything new in 4.5.2. And I can't think of anything. Otherwise we need to force the users to upgrade their version of .NET for no real reason.

[amaitland]

Please lower the requirements if the wrapper isn't using anything new in 4.5.2. And I can't think of anything. Otherwise we need to force the users to upgrade their version of .NET for no real reason.

.Net 4.5.2 is the lowest version supported by Microsoft. Either use an older version or choose a different CEF wrapper.

I will also add that .Net 4.5.2 runs on every OS that Chromium supports (Windows 7 and above).

The time for discussing this has long since past, you should consider using another wrapper if this doesn't suite your requirements or build your own version from source.

[jankurianski]

You are free to fork the project and lower the requirements for yourself. It is not difficult to build CefSharp yourself, see: https://github.com/cefsharp/CefSharp/wiki/Getting-Started#building-cefsharp

To give you an idea of what you are asking here, a better way to ask this question would be "I would like to lower the requirements of CefSharp and offer my spare time to support older versions of .NET, including answering questions related to older versions of .NET, checking all reported bugs to see if they are occurring due to the older .NET framework version, and reviewing PRs when issues arise related to the older .NET framework version."

[MoonStorm]

You know very well that forking, building and referencing open-source projects is not a sustainable solution. We're way past that way of thinking. These types of projects are kept alive by people who are giving up their time for contributing to something they love and share those contributions with other people. And I know that because I'm also maintaining open-source projects made available on distribution networks. If I can't find the time, other people will help.

Long story short, this is the first time I've encountered a project forcing minimum requirements based on a patch version of a framework. And what's even worse, it's the first time I'm seeing Microsoft's support policies being followed so stringent by an open-source project. Their policies don't reflect on the reality. And the reality is users won't follow them and as a result developers won't either. Plus it's not the developers role to force upon the users and corporate environments the Microsoft's policies.

[amaitland]

What are you hoping to achieve here? When are we allowed to upgrade exactly? Have to draw a line in the sand somewhere, a logical place is when support ended. The Wpf version in particular gains a boos by being able to invalid a dirty rect, other async workarounds were removed and the new binding feature benefits from the additional type info available. I'd very much like to upgrade to .Net 4.6 and remove some hacks relating to Task continuations, I will however hold off until support is ended or a overriding requirement arises. The changes aren't simply made on a whim, though I could see how that might look from the outside.

As for maintaining your own fork, your opinionated view isn't necessarily a pragmatic one. Maintaining a fork that provides different version comparability should be quite feasible, publishing packages to your own myget feed similarly so. I personally have no interest in maintaining an ifdef mess that would be required to maintain two version.

Also what stops you from using another CEF wrapper? How about giving CefGlue or ChromiumFx a go?

No further rants necessary, thank you.