More XP problems

[hvdijk]

Hello,

The CefSharp 39 packages don't work on Windows XP. I'm aware of the FAQ entry, but the problems here aren't covered there.

Most importantly, it just plain bombs. Dependency Walker shows that the problem is that CefSharp.Core.dll refers to GetTickCount64, which is new in Windows Vista. This dependency does not come from the source code, and if I build CefSharp myself instead of using the pre-built packages, there is no reference to GetTickCount64 anywhere. This may be related to one of the updates to Visual Studio.

I will be using the locally built packages for now to avoid this problem, but it would be nice if the official packages could be built without this dependency.

Additionally, a milder issue, the DependencyChecker.IsWindowsXp property doesn't work. Its value is only ever read in the DependencyChecker.CefOptionalDependencies initialiser, but the initialiser will already have run by the time any code gets the chance to set the property value. It seems like it would be easy to make DependencyChecker.IsWindowsXp a read-only property: it can simply check Environment.OSVersion.Version.Major < 6 (optionally in addition to a sanity check -- Environment.OSVersion.Platform == PlatformID.Win32NT && Environment.OSVersion.Version.Major < 6 -- but clearly the other platforms aren't going to work).

I clean up DependencyChecker.CefOptionalDependencies manually now to work around that problem.

With those changes, it's working nicely for me on XP SP3, .NET Framework 4 and Visual C++ redistributables installed.

[amaitland]

With those changes, it's working nicely for me on XP SP3, .NET Framework 4 and Visual C++ redistributables installed.

Great 👍

[hvdijk]

Sorry, I don't understand why you closed this? If your position is that as you no longer support XP, you are not willing to make changes to get it working on XP again, that is an unfortunate but understandable position. However, in that case, the FAQ entry is just plain wrong. "We no longer officially support Windows XP. That being said CefSharp should work in most cases" -- The current releases of CefSharp shouldn't work on any Windows XP machine for anyone. Perhaps the entry should then say something like "We no longer support Windows XP, and our CefSharp releases will not run on it. If you need to use CefSharp on Windows XP, compiling your own version from source may allow it to work."?

[amaitland]

Sorry, I don't understand why you closed this?

Your problem was solved and at no point did you ask a question.

If your position is that as you no longer support XP, you are not willing to make changes to get it working on XP again, that is an unfortunate but understandable position.

At no point has anyone volunteered time/resources to provide support. Some make requests for support, some are down right rude in the process. So personally I have no interest in support ing Windows XP. Are you or the company you work for interested in contributing past the point of meeting your own requirements?

However, in that case, the FAQ entry is just plain wrong.

Thank you for the suggestion, I have updated the FAQ.

Additionally, a milder issue, the DependencyChecker.IsWindowsXp property doesn't work.

I have no objects if you wish to submit a PR.

[hvdijk]

Well, for the first problem, my request was basically to the person making the releases (I don't know who that is) to install any available updates to Visual Studio before making the next release. :) (I did check, and my system reports I have no updates to install, so assuming the problem is indeed in the different VS2012 update versions, installing all updates should fix it.) This doesn't require any changes in the source code, so I can't submit a pull request for that.

Another possibility would be to explicitly target the v110_xp toolchain, which should work with older update versions of VS2012 as well. If that would be more acceptable to you, I'd be happy to submit a pull request for that. And for making DependencyChecker.IsWindowsXp a calculated property, like I suggested here, if that looks like a good approach to you, I'll submit a pull request for that as well. I can probably do that later today.

I can't promise to help maintain XP support, but if pull requests for XP support that don't hurt newer Windows versions are acceptable, then I can at least help get the current versions into a state that benefits everyone, not just myself.

[amaitland]

Well, for the first problem, my request was basically to the person making the releases (I don't know who that is) to install any available updates to Visual Studio before making the next release

The builds are automated, they're produced by AppVeyor. The build script is located at https://github.com/cefsharp/CefSharp/blob/master/build.ps1

You can fork and toy around with it as you choose.

Another possibility would be to explicitly target the v110_xp toolchain, which should work with older update versions of VS2012 as well. If that would be more acceptable to you,

I'm not particularly keen on this option. I would prefer to move to v120, though there is still some discussion over that. (Making the minimum requirement VC++ 2013 has some potential technical difficulties).

And for making DependencyChecker.IsWindowsXp a calculated property, like I suggested here, if that looks like a good approach to you, I'll submit a pull request for that as well. I can probably do that later today.

Go for it.

The alternate option is that someone builds and releases a set of packages to a separate feed e.g. MyGet and people seeking XP support use those packages. The build script produces the Nuget packages.

[amaitland]

I can't promise to help maintain XP support

Supporting a whole platform requires someone to test, troubleshoot and bug fix. As it stands there are very few active contributors, only a handful that actually provide support. Someone with a vested interest in the platform needs to step up and contribute.

[hvdijk]

The build I did locally was through the included Build.bat file, which simply calls the build.ps1 you mention, and produced the XP-compatible NuGet packages for me. Thanks for referring me to AppVeyor, I'll sign up and check to see what's going on that causes the incompatibilities. Perhaps it would be reasonable to not change the minimal requirements, but still upgrade the automated builds to VS2013, if the VS2013 builds do work.

[hvdijk]

An update: AppVeyor can compile it with VS2013 without problems, and the resulting DLLs still target .NET 4.0 and do not require GetTickCount64. https://github.com/hvdijk/CefSharp/commit/140a92057929f75c286d680d80ba79e352aa2b6b I will do some actual testing on a clean XP SP3 virtual machine (with .NET Framework 4, and the Visual C++ 2013 redistributables) tomorrow to check that if any other troublesome dependencies have been introduced by the 2013 update, as well as testing on Windows 8.1 as a sanity check. At any rate, aside from the IsWindowsXp bits, the changes are limited to the automated builds, so shouldn't affect anyone's local development. Reading issue 907, I must admit I'm having a bit of trouble seeing what the problem is. If actual testing shows any errors, perhaps it will then become obvious.

[amaitland]

The DependencyChecker changes will need to be split out into a separate PR. It's still unclear if VC++ 2013 will be used.

[hvdijk]

Sure, done. And just for the record, I've tested the AppVeyor build from my fork (built with VS2013) and it works just great, for me anyway.

[amaitland]

From the limited interaction I've had with AppVeyor support they've been very responsive, so if you can identity the missing patches then I'm confident they'd help be receptive to adding them.

http://www.appveyor.com/docs/installed-software#getting-the-list-of-installed-software

[amaitland]

Cherry picked part of https://github.com/hvdijk/CefSharp/commit/140a92057929f75c286d680d80ba79e352aa2b6b adding support for newer MSBuild under VS2013, thanks 👍

See f2da822

[hvdijk]

It took some time to verify that simply installing VS2012 Update 4 is enough to fix the problems, but I was able to check that now, and have opened a topic on the AppVeyor. Will see how they respond.