Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for .NET Core/CoreCLR #672

Closed

Conversation

clairernovotny
Copy link

This is for #668.

I've added a build-time package for my Dependency generator tool: https://github.com/onovotny/ReferenceGenerator. That puts the right dotnet stuff in the nuspec.

Then I've updated the nuspec to put the right files in the lib dirs.

I've removed the un-needed xproj stuff as there's no need for them to support CoreCLR. If you want to use the new .NET Core libraries, you can also do that with a "modern PCL" -- that is, create a new PCL project that targets aspnet 5, universal 10 and .net 4.6. You can use linked files/shared projects to share the code with the existing PCL.

The only thing you need xproj for is for websites. The other xproj can be moved into a "modern PCL" that only targets aspnet 5 too. I can help with that later if you need.

As-is, the package should work on everything....but should be tested of course :)

@tillig
Copy link
Member

tillig commented Aug 11, 2015

Lots to soak in and understand here. Thanks for taking the time! I'm going to have to mess with this.

@clairernovotny
Copy link
Author

The DI project can probably be a regular "portable" project that targets only aspnet 5. then it'll probably build...correctly as it won't need any dnx/dnu stuff.

@clairernovotny
Copy link
Author

this is the general idea anyway, no worries if you adapt it to however works best for you.

@alexmg
Copy link
Member

alexmg commented Aug 11, 2015

If we can avoid being broken by DNX updates all the time that would be
good. Would still like to test against DNX environment to be sure though.

On Wed, 12 Aug 2015 09:00 Oren Novotny notifications@github.com wrote:

this is the general idea anyway, no worries if you adapt it to however
works best for you.


Reply to this email directly or view it on GitHub
#672 (comment).

@alexmg
Copy link
Member

alexmg commented Aug 12, 2015

Does the build machine require the Windows 10 developer tools to be installed? It was nice being able to completely bootstrap a build from the command line with only PowerShell and Git as the starting dependencies.

@clairernovotny
Copy link
Author

For what I've done so far, the Win10 tools aren't required. They would be if you want to use "modern PCL".

"all" I've done is put the existing Profile259 PCL in the \lib\dotnet dir and attach the reference generator tool to list out the correct set of dependencies for the dependency group. Because it's "just" a Profile 259 PCL, all of the package versions are 4.0.0 and work across all .NET 4.5+/System.Runtime systems.

If you use a newer PCL profile or a .NET Core based library that references newer BCL contract/package versions, then you'd need to do more work in the form of blank dependency groups and adding specific TFM lib dirs with compatible versions (the 259 dll). It's confusing for sure.

@clairernovotny
Copy link
Author

A few other thoughts: if you download nuget.exe, make sure it's the v3 beta. It's here for now: http://dist.nuget.org/win-x86-commandline/v3.1.0-beta/nuget.exe

Then call nuget restore on the sln for it to generate the proper .nuget.props/.nuget.targets/project.lock.json files

Add *.nuget.props, *.nuget.targets and project.lock.json to the .gitignore - nuget will generate those

As for building w/o VS installed, I'm not sure. Rember that MSBuild was split from the framework in 2013. The version in the system framework directory is old. You'll want to build with the v14 tools here: C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe. I don't know if that's available for install w/o VS.

I fear the build-agent-without-VS battle has been lost long ago :/

@tillig
Copy link
Member

tillig commented Aug 17, 2015

@onovotny If we wanted to keep project.json with the dnx/dnu builds, looking at your chart it appears we could target dotnet, net45, and netcore45 and cover all the platforms. We might not even need the PCL profile.

If we switched to target those, putting in the appropriate dependencies in project.json, would that work? Or am I missing something fundamental?

Reason being... I kinda like the new build structure. I'd hate to have to go back if I don't have to.

@tillig
Copy link
Member

tillig commented Aug 27, 2015

The develop branch has been updated so the project.json stuff supports dotnet as the platform rather than the specific PCL target. I've verified compatibility for:

  • .NET 4.5.2
  • .NET 4.6
  • Universal Windows Platform
  • Windows 8.1 apps
  • DNX/DNX Core (which we already unit test)

I couldn't get Android/Xamarin ("monoandroid5.0") or iOS/Xamarin ("xamarinios1") to work because we need System.Reflection.Extensions and those don't appear to support the Xamarin platforms yet, which makes me think maybe our Xamarin support wasn't 100% to begin with.

Since we have this working, I'll close this PR and we can update in the develop branch to address any additional shortcomings.

Thanks again @onovotny for helping us through this one.

I'll update #668 accordingly.

@tillig tillig closed this Aug 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants