Adding .NET Standard 1.1 support for ODataV4-7.x #774

AlanWong-MS · 2017-03-17T21:47:22Z

Description

This PR adds separate .csproj files for the ODataV4-7.x libraries built with .NET Standard 1.1, and they are gathered with a newly added Microsoft.Test.OData.DotNetStandard.sln file. The intent is to have both PCL and .NET Standard libraries shipped in NuGet packages; this will help ease the transition.

Checklist (Uncheck if it is not completed)

Test cases added.
Build and test with one-click build and test script passed (around six tests fail intermittently and are not due to the effects of this changelist)

Additional work necessary

N/A: the user should be able to run build.cmd and all solutions should be able to build out of the box.

Creating a new solution file for .NET Standard projects. Adding .NET Standard versions of Microsoft.Spatial, Microsoft.OData.Edm, Microsoft.OData.Core, and Microsoft.OData.Client. Known issues: need some stylecop filters, "nuget restore" needs to be run manually on the new project files for them to compile, Microsoft.OData.Client is having issues detecting System.Runtime.Serialization namespace

Maintanence commit to clean up files.

Adding Microsoft.Test.OData.Framework.NetStandard.csproj and Microsoft.Test.OData.Services.TestServices.NetStandard.csproj. Updating readme to inform user that ODL 7.x is on .NET Standard 1.1.

Caveat: there's a bug in VIsual Studio that causes the xproj to have trouble finding the csproj files for ODL. Therefore committing the project.lock.json file as well so that we don't have to run nuget restore. Also adjusting the build script for binary output to address the E2E xproj build issue.

Build script update: removing NuGetPackage test project and deprecating it, adding E2E .NET Standard project Applying same stylecop filters to OData.Edm .NET Standard as original project. Updating some comments in Build.props.

Porting over stylecop filters from original project

msftclas · 2017-03-17T21:47:26Z

@AlanWong-MS,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

AlanWong-MS · 2017-03-17T21:52:29Z

I accounted for this existing issue with the project.json/Visual Studio reference error by adding one project.lock.json file to the Microsoft.OData.E2E.DotNetCore.xproj directory. Hopefully others won't have issues with Visual Studio not being able to locate dependencies.

AlanWong-MS · 2017-03-17T22:00:12Z

README.md

@@ -30,7 +28,7 @@ For these libraries, we accept bug reports and pull requests. The corresponding

 **ODataV4-7.x branch**

-The ODataV4-7.x branch includes the .NET libraries for OData V4 only that are in development now. It is evolved from ODataV4-6.x with kinds of improvements, new features and so on. It is in-compatible with ODataV4-6.x release and will become the master branch after it is released. It has same libraries as ODataV4-6.x branch.
+The ODataV4-7.x branch includes .NET Standard 1.1 libraries for OData V4 only that are in development now. This branch builds upon ODataV4-6.x with new features with the same libraries but is incompatible with ODataV4-6.x--it will become the master branch after it is released. Due to the new use of `project.json`, there is a change in the build process for those who are unfamiliar. Please either 1) run `nuget restore Microsoft.Test.OData.DotNetStandard.sln` in the commandline of the `odata.net/sln` directory, or 2) enable automatic package restore via Visual Studio to build them (in VS2015, go to `Tools->NuGet Package Manager->Package Manager Settings`. Enable "Allow NuGet to download missing packages".). More info regarding the command can be found [here](https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore).


Need to revise statement. It can build both PCL and .NET Standard. Also rewrite some sentences for easier understanding.

am11 · 2017-03-20T16:25:33Z

@AlanWong-MS, thank you so much for moving this forward! 🎉
Azure Table Storage, Azure Media Service and many other downstream packages that rely on OData would able to provide support for pure .NET Core support on Unix platform by this effort. In the current release of OData packages, we need to take dependency on mono PCL to run on Unix platforms (which is definitely not a non-blocker, but bit inconvenient IMO).

Now that .NET Core SDK is supported by VS2017 and .NET CLI, would it make sense to do the direct transition to CSPROJ based project instead of taking the XPROJ route? I have done the port-to-NetStd work in some projects, I would be happy to take a stab at it and provide the CSPROJ based implementation. The solution would be able to build on VS Code, VS 2017 for Mac (preview) and VS2017 {any flavor} on Windows as well as the dotnet CLI v1.0 (that ships with VS2017), MSBuild15 and nuget4. However, that SLN wouldn't be able to build on VS2015 as (CPS based) CSPROJ schema has been changed, as it provides build for multiple frameworks with a simplified structure.

Please note, (if I remember it correctly) that dotnet-cli v1.0.0-preview3 is the last version that supports project.json / xproj based projects. Starting from preview4 and now v1.0.0 (RTM) of dotnet-cli would not support project.sjon/xproj based projects. Hence this new-csproj transition is somewhat rendered as mandatory at this point.

Some information can be found here: https://docs.microsoft.com/en-us/dotnet/articles/core/tools/project-json-to-csproj

Please let me know if I can contribute. :)

AlanWong-MS · 2017-03-21T21:24:36Z

@am11, thank you for your contributions and support. :)

Thanks for your comment as well as your previous PR (#591) related to this. We did a thorough review of your PR and we ultimately decided to create a separate one for two main reasons: 1) we're going to target .NET Standard 1.1 to enable a wider range of support and 2) we’re trying to maintain capability with our existing test infrastructure so we went with .csproj/project.json files for .NET Standard (whereas yours went the .xproj route) to be consistent with our PCL versions.

Now that .NET Core SDK is supported by VS2017 and .NET CLI, would it make sense to do the direct transition to CSPROJ based project instead of taking the XPROJ route?

We’re just as excited as everyone else with the release of VS2017 and would like to onboard to the new product as soon as we can. However, we’re still in the process of getting VS2017 set up on our machines and build infrastructure (some migrations from older systems left to take care of). We do hear you on the points you made regarding VS2017’s advantages—we’re trying to get to the .NET Standard checkpoint first so VS2015 is an intermediate step for us on the way to VS2017.

Having said that, you are one of our amazing pioneers of transitioning to .NET Standard, and we’d welcome your help again in assisting the community on moving to VS2017. :) We don’t have a solid timeframe at this point, but it’s definitely on our radar.

Thank you!

- Updating Build.props to remove unnecessary code churn - Removing Microsoft.Test.DotNetCore.sln because the E2E tests have been moved to the NetStandard.sln - Updating readme for more clear understanding - Updating build script to move to VS2015

- Typo in readme. PCL259 -> PCL111

robward-ms · 2017-03-21T21:07:27Z

sln/Microsoft.Test.OData.DotNetCore.sln

@@ -13,20 +13,8 @@ Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Microsoft.OData.Client.Port
 EndProject
 Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Microsoft.Test.OData.Services.TestServices.Portable", "..\test\EndToEndTests\Services\TestServices\Build.PortableLibrary\Microsoft.Test.OData.Services.TestServices.Portable.csproj", "{4382D649-1A86-48D0-9156-AC37C3D568C0}"
 EndProject
-Project("{8BB2217D-0F2D-49D1-97BC-3654ED321F3B}") = "Microsoft.OData.E2E.DotNetCore", "..\test\DotNetCoreTests\Microsoft.OData.E2E.DotNetCore\Microsoft.OData.E2E.DotNetCore.xproj", "{F53B4237-F3EE-4700-8E46-9E8BBB367E87}"


This solution was intended to run the Dot Net Core tests. Since we now have a solution that both builds the product and runs the test, let's remove this solution.

We could just use this one but I think the name Microsoft.Test.OData.DotNetStandard.sln is more appropriate as this solution builds the product code we'll release as well.

robward-ms · 2017-03-21T21:07:55Z

src/Microsoft.OData.Edm/Csdl/Semantics/IEdmReferentialConstraint.cs

@@ -1,26 +0,0 @@
-//---------------------------------------------------------------------


Can you add a comment in the description as why this file is being deleted?

Will add consolidated descriptions of the commits into the overall description when we do a squash PR.

robward-ms · 2017-03-21T21:09:00Z

tools/CustomMSBuild/Build.props

@@ -38,6 +38,9 @@

    <!-- This ensures OutputPath always matches OutDir, especially when TFS overrides OutDir. -->
    <OutputPath>$(OutDir)</OutputPath>
+
+    <!-- Setting this variable to false preserves the OutputPath set above. Without this variable, our OutputPath would eventually be overwritten with a different one in the Microsoft.Common.CurrentVersion.Target script. -->


I think we want this change but can you remove the other changes from this file so they are not included in the commit?

robward-ms · 2017-03-21T21:09:59Z

src/Microsoft.OData.Client/Build.NetStandard/project.json

@@ -0,0 +1,14 @@
+{


In addition to the new projects, I would also expect changes to the NuSpec files to publish the new project outputs.

robward-ms · 2017-03-21T23:08:37Z

README.md

@@ -30,7 +28,9 @@ For these libraries, we accept bug reports and pull requests. The corresponding

 **ODataV4-7.x branch**

-The ODataV4-7.x branch includes the .NET libraries for OData V4 only that are in development now. It is evolved from ODataV4-6.x with kinds of improvements, new features and so on. It is in-compatible with ODataV4-6.x release and will become the master branch after it is released. It has same libraries as ODataV4-6.x branch.
+The ODataV4-7.x builds upon the [ODataV4-6.x branch](https://github.com/OData/odata.net/tree/ODataV4-6.x) and produces both [PCL (Portable Class Libraries) Profile259](https://msdn.microsoft.com/library/gg597391.aspx) and [.NET Standard 1.1](https://docs.microsoft.com/en-us/dotnet/articles/standard/library) libraries. Following ODataV4-6.x, this branch implements new features with the same libraries and will become the master branch after release. 


The current projects are Profile111, not 259.

…ing nuspec files for .NET Standard binaries and new filepath to libraries.

- MSBuild doesn't pre-process the dependency graph provided by the csproj files, so explicitly spoonfeeding the chain in the Microsoft.Test.OData.DotNetStandard.sln file

AlanWong-MS added 7 commits March 15, 2017 13:40

Updating .gitignore and removing dup file

9eb4db9

Maintanence commit to clean up files.

Adding .NET Standard test projects and updating readme

c28c482

Adding Microsoft.Test.OData.Framework.NetStandard.csproj and Microsoft.Test.OData.Services.TestServices.NetStandard.csproj. Updating readme to inform user that ODL 7.x is on .NET Standard 1.1.

Update build script to default to VS 2015 for .NET Standard

ef444b5

Updating build script and other miscellaneous items

f61a424

Build script update: removing NuGetPackage test project and deprecating it, adding E2E .NET Standard project Applying same stylecop filters to OData.Edm .NET Standard as original project. Updating some comments in Build.props.

Address stylecop errors

bab3899

Porting over stylecop filters from original project

msftclas added the cla-not-required label Mar 17, 2017

LaylaLiu added in-progress and removed cla-not-required labels Mar 17, 2017

AlanWong-MS commented Mar 17, 2017

View reviewed changes

AlanWong-MS added 2 commits March 21, 2017 16:02

Code review changes

9180534

- Updating Build.props to remove unnecessary code churn - Removing Microsoft.Test.DotNetCore.sln because the E2E tests have been moved to the NetStandard.sln - Updating readme for more clear understanding - Updating build script to move to VS2015

Fixing typo

2d641cd

- Typo in readme. PCL259 -> PCL111

robward-ms approved these changes Mar 21, 2017

View reviewed changes

AlanWong-MS added 2 commits March 24, 2017 12:59

Updating project.json dependency for Microsoft.OData.Client and updat…

d8e524a

…ing nuspec files for .NET Standard binaries and new filepath to libraries.

Resolving race condition during build

1cd502c

- MSBuild doesn't pre-process the dependency graph provided by the csproj files, so explicitly spoonfeeding the chain in the Microsoft.Test.OData.DotNetStandard.sln file

AlanWong-MS mentioned this pull request Mar 27, 2017

Add NetStandard support #591

Closed

Merge branch 'ODataV4-7.x' into ODataV4-7.x

40d520e

AlanWong-MS closed this Mar 29, 2017

AlanWong-MS deleted the ODataV4-7.x branch March 29, 2017 17:22

LaylaLiu removed the in-progress label Mar 29, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Adding .NET Standard 1.1 support for ODataV4-7.x #774

Adding .NET Standard 1.1 support for ODataV4-7.x #774

Uh oh!

AlanWong-MS commented Mar 17, 2017 •

edited

Loading

Uh oh!

msftclas commented Mar 17, 2017

Uh oh!

AlanWong-MS commented Mar 17, 2017

Uh oh!

AlanWong-MS Mar 17, 2017

Uh oh!

am11 commented Mar 20, 2017

Uh oh!

AlanWong-MS commented Mar 21, 2017 •

edited

Loading

Uh oh!

robward-ms Mar 21, 2017

Uh oh!

robward-ms Mar 21, 2017

Uh oh!

AlanWong-MS Mar 21, 2017

Uh oh!

robward-ms Mar 21, 2017

Uh oh!

AlanWong-MS Mar 21, 2017

Uh oh!

robward-ms Mar 21, 2017

Uh oh!

AlanWong-MS Mar 27, 2017

Uh oh!

robward-ms Mar 21, 2017

Uh oh!

Uh oh!

		@@ -1,26 +0,0 @@
		//---------------------------------------------------------------------

Adding .NET Standard 1.1 support for ODataV4-7.x #774

Adding .NET Standard 1.1 support for ODataV4-7.x #774

Uh oh!

Conversation

AlanWong-MS commented Mar 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist (Uncheck if it is not completed)

Additional work necessary

Uh oh!

msftclas commented Mar 17, 2017

Uh oh!

AlanWong-MS commented Mar 17, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

am11 commented Mar 20, 2017

Uh oh!

AlanWong-MS commented Mar 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AlanWong-MS commented Mar 17, 2017 •

edited

Loading

AlanWong-MS commented Mar 21, 2017 •

edited

Loading