We're updating the issue view to help you get more done. 

Release NuGet package of Remotion.Linq.EagerFetching for .netstandard1.0

Description

Remotion.Linq was released with a .netstandard1.0 compatible package, but EagerFetching was not.

Activity

Show:
Michael Ketting
May 12, 2017, 8:47 AM

As described in https://groups.google.com/forum/#!topic/re-motion-users/IgbykBpeldY
Resolving this feature request requires porting the all the .NET Core commits in Remotion.Linq to Remotion.Linq.EagerFetching (i.e. excluding 2861933c32a57f5676dbb990a13416ccfb18fd03 to including 29cd82725117fd43f3fb6966ba76da719e36111d)
Note that the commits / feature branches that deal with build script updates can be skipped sicne they're already done. Similiarily, code-changes done for new featuers in re-linq will be skipped. And the project GUID for the new projects must be updated to ta new value.

This will setup separate projects for .NET 4.5 and .NET Core, create the nuspec files needed, adapt the build script to deal with project.json stuff. In the end, a nuget package will be created which contains the existing .NET 3.5, .NET 4.0, .NET 4.5 builds and the new .NET Core build linked to .NET Standard.

As mentioned in the mailing list thread, I don't have a timeframe for when I will be able to take the time for doing this myself, but I do have time to do code reviews of pull requests

User known
May 13, 2017, 7:38 PM

Are you ok with using Visual Studio 2017's .csproj, or do you want to stay on Visual Studio 2015 and project.json?

Do I need separate issues/feature branches for converting the Visual Studio version like you had in Remotion.Linq? ()

Michael Ketting
May 14, 2017, 8:48 AM

Great, thanks for picking this up

VS2017: I wish that I could but the build script isn't yet set up to deal with that (I can't switch the C# compiler without releasing a new major version and the build script can't yet separate msbuild and the c# compiler). Plus there's this issue regarding full Framework references (https://github.com/NuGet/Home/issues/4853) which I'm not sure will affect me. Bottomline: we're stuck with VS2015 for the time being.

Feature branches: No, one branch is fine.

For booking purposes: When all is said and done, we'll also need a Contrib License Agreement, please. Details are here: https://www.re-motion.org/web/?page_id=82

User known
May 17, 2017, 8:22 PM

I created a pull request #1.

I don't know why you would want to stay on VS2015, the Core.csproj won't load in Visual Studio when there is also a project.json file. The same for the main Relinq project.

I also emailed in the contrib license agreement.

Michael Ketting
May 18, 2017, 6:35 AM

Hi Nathan,

thanks for the PR. Will be checking it out during the weekend. CLA should get processed sooner

Re VS2015: As I mentioned, it's not so much a matter of "want" but "must" due to the unfortunate perfect storm of business cosntraints and time constraints. Even getting to VS2015 was an effort that only happened because there was no other way to support .NET Standard in re-linq.

~Michael

Assignee

Michael Ketting

Reporter

User known

Labels

None

Components

Fix versions

Priority

Normal
Configure