RFC - CefSharp 41 VC++ 2013

[amaitland]

So we're looking at upgrading the current VC++ 2012 requirement to VC++ 2013 for the next major release (Based on the cef 2272 branch).

This will also mean that the minimum requirement for for developing CefSharp will be VS2013. As the Community Edition is now freely available, this shouldn't be too much of a hurdle for people. When VS 2015 is released, we'll look at adding additional support.

Now's the time to have your say!

[amaitland]

The upcoming 39 release will still be based on VC++ 2012.

[amaitland]

/cc @jornh @perlun @jankurianski @rassilon

[jankurianski]

Good with me.

[perlun]

How about .NET framework dependency? We still have cases where we must be able to embed CefSharp in .NET 4.0 (not 4.5) apps, where it simply unfeasible to require all users to download .NET 4.5.1 just because of CefSharp.

So from my POV, that would be my main concern. IIRC, this is the way it is (http://stackoverflow.com/questions/2921702/change-c-cli-project-to-another-framework-than-4-0-with-vs2010)

• Visual Studio 2010: generates C++/CLI assemblies compatible with .NET 4.0.
• Visual Studio 2012: generates C++/CLI assemblies compatible with .NET 4.5.
• Visual Studio 2013: no idea. .NET 4.5.1?

This is a very stupid limitation, but I guess the core reason behind it is the fact that the C++/CLI toolchain ties much more tightly together with a specific .NET version than the .NET compiler, or whatever.

Anyhow - as far as I'm concerned, I know that I will have problems upgrading some of our customers to a version of our platform that would depend on NET 4.5. Others would work fine, but maybe we just have to live with this? I mean, we can still provide a version based on CefSharp 37 (or 39) to the "legacy" customers. I don't want to force my personal preferences to force everyone else to use antiquated versions of Visual Studio...

If/when we do this change, we could drop the VS2010/VS2012 settings. At the moment, I think stuff is a bit conditionalized. We can still keep the conditionalization, since we might need it for VS2013/2015 eventually.

[amaitland]

This is a very stupid limitation, but I guess the core reason behind it is the fact that the C++/CLI toolchain ties much more tightly together with a specific .NET version than the .NET compiler, or whatever.

I was under the impression it was possible, just had to be done by hand. I haven't verified this, just going by what I've read.

http://stackoverflow.com/questions/2921702/change-c-cli-project-to-another-framework-than-4-0-with-vs2010#comment36808506_2921868
http://blog.kalmbach-software.de/2014/02/06/change-target-framework-in-ccli-for-vs20102012/

[perlun]

I was under the impression it was possible, just had to be done by hand. I haven't verified this, just going by what I've read.

It is possible, but you will then have to have the VS2010 tools installed as well. 😄 That's unfortunately how C++/CLI works. There's (to the best of my knowledge) no way around that.

[amaitland]

It is possible, but you will then have to have the VS2010 tools installed as well. 😄 That's unfortunately how C++/CLI works. There's (to the best of my knowledge) no way around that.

Gotcha, thanks for the clarification 👍

If/when we do this change, we could drop the VS2010/VS2012 settings. At the moment, I think stuff is a bit conditionalized. We can still keep the conditionalization, since we might need it for VS2013/2015 eventually.

Whilst the build script still has support for VS2010, we haven't released a cef.sdk nuget package that supports it for quite a while, it's effectively been dropped. I think the reality is that when 2015 comes out that will mean supporting 2012/13/15. Practically I think that's getting a little hard to keep three versions of VS around. Support Current and Current - 1 makes sense to me.

I'm surprised at how many people are still using .Net 4.0.

Anyways, I'm curious to see if anyone else has comment.

[rassilon]

Interesting. I was not aware of that behavior of CLI/C++, how annoying.

Hrm. I think I'll have to ponder this some more. Ugh.

Bill

[daveaton]

I am currently using visual studio 2013 and shipping 2013 C++ requirements out. I am also using .Net 4.0 not .Net 4.5.0 or 4.5.1.. I just weed out the parts that use those commands and build back to .NET 4.0 standards.

I am forced to use .NET 4.0 at the moment not because of Windows XP But rather than MAC and Linux requirements most of the emulators support up to .NET 4.0 but do not support anything newer

David

[lamerbug]

There's nothing to be surprised, net4.0 is still needed because of support legacy OS'es like Windows XP (which is still showing significant usage % (15-20), even better than 8.1 lol) and other stuff mentioned above.
In other words, I think u cannot just drop vs2010/4.0 support and cut off 20+% users now. Maybe next year...

[amaitland]

There's nothing to be surprised, net4.0 is still needed because of support legacy OS'es like Windows XP (which is still showing significant usage % (15-20), even better than 8.1 lol) and other stuff mentioned above.

Cutting Windows XP support would also cut the number of issues created by 10-15%, so personally, that's a huge plus 😄 Unless someone puts up their hand to help with support for Windows XP/2003 then I don't see any particular reason to factor it in as a minimum requirement.

As it stands I think 41 will keep the same dependencies, and 43 will up the requirements.

[amaitland]

@lamerbug @rover886 @ray007 @murphmar @ulmer-morozov @BestofBestDeokwan Is anyone prepared to put in the hours to help support Windows XP/2003? Answer questions, test new releases, contribute content to the wiki.

[amaitland]

It should be noted that CEF (and Chrome) will drop support for Windows XP end of the year.

http://magpcss.org/ceforum/viewtopic.php?f=6&t=12864#p25413

[lamerbug]

Is anyone prepared to put in the hours to help support Windows XP/2003? Answer questions, test new releases, contribute content to the wiki.

Well, I would think about it... At least, I had many hours building and debugging and reading tha' freaking sources to get previous release running smooth on XP/VS2010/net40 ) so maybe I can help someone.

It should be noted that CEF (and Chrome) will drop support for Windows XP end of the year.

oops... So it just won't run on XP anymore or what do they mean?

[jornh]

http://chrome.blogspot.dk/2015/04/providing-updates-for-chrome-for-xp.html Says they originally planned to kill it April 2015 == now(). I'm guessing after end of 2015 they won't extend it once more and probably soon thereafter will actively clean up possible XP-only related parts of the Chromium code base.

[perlun]

Let's not mix things up here. There are two different requirements:

• Supporting Windows XP/2003
• Supporting .NET 4

The first may require a bit of work, and one or more volunteers willing to do the job. The second is not as awkward, but it means that we still need to keep the project compilable using VS2010 (AppVeyor will let us know if it's not, since I know many of us probably don't use VS2010 any more).

My suggestion:

• Drop Windows XP (or support if we have enough people being able to work on it)
• Support VS2013/2015 and VS2010. Drop support for VS2012 (to keep the number of different targets down).

As stated, I personally need .NET 4.0. Background: we are integrating CefSharp in an application platform provided by a 3rd party and some of our customers are still holding on to older versions of the application framework (ERP customers don't tend to upgrade every other day). In other words, we do not have full control over the environment in question, so enforcing .NET 4.5 is simply not doable. So I personally very much need .NET 4, at least for some year more or so. I might be able to contribute the needed time for supporting this, since it is in my employer's interest that this will work. In other words, if this means time/work needed - contact me @jornh and/or @amaitland.

[amaitland]

Support VS2013/2015 and VS2010. Drop support for VS2012 (to keep the number of different targets down).

The problem becomes compiling cef.sdk, whoever does that would need to keep three versions installed, which may not be practical. Ideally we'd automate the generation, though that's somewhat difficult as we source the builds from cefbuilds.com which has a captcha check in place, so using a build script is difficult.

As stated, I personally need .NET 4.0

Are you limited to using VC++ 2012 as well? The strange thing I discovered with Windows XP was that when I build the current master with VS2013 and modified the examples to use .Net 4.0 it basically worked on Windows XP with minimal fuss (install .Net and the VC Redist). So upgrading may actually resolve a lot of the issues people are seeing. I personally don't think we should support Windows XP unless those that require it step up and get involved.

[rover886]

whoever does that would need to keep three versions installed, which may not be practical.

I am agree with this. currently my organization is using VS2010, so for us it's not so possible to install VS2012/VS2013/2015 😃. I am also agree with @perlun we should have support for VS2010.

What if any contributor do the build in VS2010 and give it to CefSharp? Like, when a new version of CefSharp is released, a contributor will build script for VS2010. For version 37 I personally build CefSharp in VS2010 after reporting issue and under the guidance of @amaitland , @jornh (issue #810 )

[perlun]

Are you limited to using VC++ 2012 as well?

As far a the redist is concerned - no. That can work. But can you really create .NET 4 stuff w/ VC++ 2012 using C++/CLI? Isn't it still so that VC2010 = .NET 4, VC2012 = .NET 4.5 (as a base dependency)?

[perlun]

What if any contributor do the build in VS2010 and give it to CefSharp?

That's actually not an issue since AppVeyor fixes that for us. 👍 😄

[amaitland]

But can you really create .NET 4 stuff w/ VC++ 2012 using C++/CLI?

The current release is built for .Net 4.0 and VC2012. So maybe it's possible to target VC++ 2013 and use .Net 4.0? Some of the things I've read at a little conflicting. I'm in the process of setting up a virtual machine to test in isolation. The part I find interesting is that you can install VC++ 2013 on Windows XP which is limited to .Net 4.0. So that to me suggests there's some sort of compatibility between versions.

[amaitland]

There is nothing stopping anyone from repackaging CefSharp for Windows XP or whatever flavor they like and pushing it to nuget.org with a slightly different name, some sort of suffix maybe? They can be based on the same cef.redist packages. The true definition of getting involved.

[hvdijk]

As far as I can tell from this discussion, there are three main concerns with a VS2013 upgrade:

• Developers stuck on VS2010 or VS2012 for whatever reason might no longer work with CefSharp.
• Developers stuck supporting .NET 4.0 for whatever reason might no longer work be able to work with CefSharp.
• Developers stuck supporting XP for whatever reason might no longer be able to work with CefSharp.

For the first: as mentioned, the VS2013 Community Edition is available free of charge (for home users and small companies), and I think that's a convincing argument that it should not be much of a problem.

For the second: although VS2013 has a requirement on .NET 4.5, that only applies to the development environment itself. It can still create .NET 4.0 applications and libraries. A VS2013-built CefSharp application works even if .NET 4.5 is not installed on the end user's system.

For the third: the current CefSharp 39 releases cannot work on XP. (Manual builds using an up-to-date version of VS2012 do work, but AppVeyor appears to be using an older update version of VS2012.) Upgrading to VS2013 actually fixes this. I've brought up the problem in issue 1007, and have successfully tested VS2013-based AppVeyor builds on Windows XP.

So I'm all in favour of the upgrade.

[amaitland]

Rather than delay 41, we'll keep things as they are for now. 41 brings with it a huge set of changes to the API so let's get through that first.

For version 43 we should reevaluate, hopefully VS2015 is out in the not too distant future and we'll look at moving the minimum requirement for building CefSharp to VS2013. Keeping with supporting VS Current and VS Current - 1. I think then we can look at changing to a new VC++ version.

[perlun]

For the second: although VS2013 has a requirement on .NET 4.5, that only applies to the development environment itself. It can still create .NET 4.0 applications and libraries. A VS2013-built CefSharp application works even if .NET 4.5 is not installed on the end user's system.

Unfortunately, this is not true when speaking about C++/CLR. Only regular .NET works that way. C++/CLR is much tighter coupled to a particular .NET version.

[hvdijk]

Unfortunately, this is not true when speaking about C++/CLR. Only regular .NET works that way. C++/CLR is much tighter coupled to a particular .NET version.

I tested a VS2013-based build (from AppVeyor) on XP, where .NET 4.5 isn't even available, before making that comment. You can see my fork here. Did I miss something in the update?