Roslyn VB compiler (at least in VS2017 Update 3 Preview 6.0) uses Microsoft.VisualBasic.CompilerServices.EmbededOperators for string comparison. The only difference is a class name.
Hi, that's cool! Thanks for that one
If you run dotnet new xunit in an empty folder, the .csproj looks very similar:
Ah, there it is. I completely missed that Test.Sdk line. Probably need to have my eyes checked...
So, basically, everyone with an existing solution is stuck until they do a manual upgrade of their test dependencies. That's not great. For the time being making an EagerFetching release to match re-linq is okay if there's no better solution by MS, but in the long term I really want to just depend on SemVer and NuGet to solve this. I'll update the github issue but would like to wait a bit until there is a respone from MS (or silence) before I do the EagerFetch update. If that work's for your release plan?
Are you going to be able to make a synchronized release soon?
Has it already been a month? So, there hasn't really been anything helpful posted by the MSBuild guys on Github, which is unfortunate.
I can do a release next week. There's also a comptely different alternative: as a build-target file to the NHibernate nuget package an simply override the
from there (https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#including-msbuild-props-and-targets-in-a-package) I could also add them to the EagerFetching package but I'm a bit reluctant due to the more global impact.
In NHibernate, I already had the alpha version of Remotion.Linq in a pull request (#696) With the AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputType set in the test projects.
We were waiting for a full release of Remotion.Linq and Remotion.Linq.EagerFetching v2.2.0 for the next released version of NHibernate. Don't want to include prerelease versions of dependencies, and need synchronized versions because that would minimize the hassle for down-stream projects that depend on NHibernate.