Add .Net Core support

[jeremymeng]

This is for #237.

Open issue:

• Add 'dotnet' and its dependencies to the .nuspec.
• Integrate the new projects into the Fake build.

I know little about Fake. Also I am not sure how well it supports the new .NET Core based test project. so any helps are welcome!

[alexanderfast]

This looks interesting. Do you consider the pull request complete or will you be adding more to this?

[jeremymeng]

[Oops wrong sign-in in previous comment]
As far as the source code porting is concerned, I think it is complete. Since I am not familiar with Fake the build system, I probably won't work on it.

[alexanderfast]

I've had a look at all the changes now. There are more compile time ifdef's than I expected. Granted, I haven't really worked with the open source dotnet before, but I thought they were more compatible than this. Is there a way to rewrite some of the code so that it would work for both?

[nemec]

The overwhelming majority of the ifdefs seem to fall under two categories: reflection and stringcomparer.

It looks like @jeremymeng used them to avoid making backwards-incompatible changes to the non-core build, which is definitely appreciated, but given that we're still in beta for 2.0 I vote to use whichever option works on both platforms. In the Exception/ApplicationException case, I'd like to find a descriptive exception type that's available on both platforms (or make our own) -- we should avoid throwing a generic Exception since that forces the user to cast too wide of a net when catching it.

[jeremymeng]

Yes, the only reason is that I wanted to keep the Desktop code intact. I will take a look to make improvements.

[alexanderfast]

@nemec are we waiting for 2.0 to go stable before merging this?

[jeremymeng]

I replaced ApplicationException with InvalidOperationException but it might not make sense for all the places. Please suggest other exception types if you have better ones.

[jeremymeng]

The new CommandLine.dotnet and CommandLine.dnx.Tests now build clean from Visual Studio 2015.

Help on the Fake integration is welcome.

[eByte23]

Keen for this. @jeremymeng @mizipzor what is need for this to be merged?

[heaths]

Any updates on this? We would like to use this in a .NET Core application.

[eByte23]

While we wait for this pr you can use my port from myget feed here
https://www.myget.org/F/ebyte-dotnetcore/api/v3/index.json
Just add that to your nuget file

[nemec]

Given recent developments this pull request will need a bit of work to support the new csproj for Core. To be honest, I'm a bit hesitant to even merge support into master until, at the very least, 1.0 is out the door. Even at this late stage there's still a lot of churn.

What if we moved work on this to a dotnet-core branch until Core is stable? If needed, we can squash some of the rework away before merging a moderately clean patch to master.

[eByte23]

I don't think thats right though the csproj setup has been release yet at all.
it won't be available till vs 15 release according to that article.

The current setup of project.json allows multi target framework versions, e.g. 2, 3.5, 4, 4.5, netstandard etc. As others do you can keep the exact same setup re: sln's and csprojs just add a new sln,xproj,project.json for vs2015.

Use ifdefs and extension methods to change code for version targeting and also use the include and exclude files build options in project.json.

If you like I can push up my branch to show you what I mean but I don't see a reason not to support netstandard but if you are not happy to merge it that's fine too.

[heaths]

The csproj changes are only for build-specific options, like compiler options. Dependencies, target frameworks, etc., will still be managed in project.json so I doubt the planned changes for VS15 RTW will make any difference to the PR.

[jeremymeng]

What if we moved work on this to a dotnet-core branch until Core is stable?

Sounds like a good idea. Even better if alpha packages can be released from that branch to early adopters.

[nemec]

Okay it's been merged into the branch dotnet-core. I'm not sure how to let Github know it's been merged so I'm just going to close this pull request.

Regarding Nuget packages, I'm on Linux at the moment and Nuget keeps wanting to use backslashes, which are not path separators, so it's breaking. @gsscoder may be coming back tomorrow (see #291) and may be able to help with that. He's also the only one with access to the Nuget repository.

[pawelsawicz]

Did you push dotnet-core branch as a alpha package to nuget ? Would love to test it for my project

[TechnikEmpire]

Like @pawelsawicz , also looking for this. There are a lot of clone/forked versions on nuget, lots of with the same name as well. Trying to figure out of one of them is the "real" .net core version.

[TechnikEmpire]

@pawelsawicz and others, I've created an unofficial nuget package from master and I'm using it in a .NET core app project with success. You can find it at:

https://www.nuget.org/packages/CommandLineParser.Unofficial.CoreBeta/2.1.0-beta

I understand that the owner of the official nuget package is very busy, so I created this in the meantime, but please @nemec or others ping me when 2.1-* gets officially pushed and at that point we can discuss if it's best to pull this to get people back on the correct package.