Update rakefile to .NET Core solution

[BrainCrumbz]

Within chore/dotnet-core-1.0 branch, Rakefile has been partially updated to new directory locations.

There's one section that still requires work/attention though: Packaging tasks.

Ideally, if that's about NuGet packaging, that should be performed through dotnet CLI tools (pack, publish). So, besides having a working setup for packaging, is that part still relevant in Rakefile?

[amirrajan]

It'd be nice if everything was through Rake (of course it would use the pack/publish command underneath the seems). At on point, the publish command for Rake also uploaded the dll's to GitHub for download outside of nuget.

Not sure if any of that is important these days.

[BrainCrumbz]

Related update: in order to make CI work on AppVeyor, a PowerShell build script has been created. That goes from cleaning to restoring, up to publishing on MyGet for dev and NuGet for production.

Hooks between AppVeyor and Github still needs fixing, and that is waiting until we move to a Github organization. Once that works, there should be less pressure to publish manually from a dev machine. Anyway, if we want to keep that around, PowerShell works on Windows machines, but has been ported cross-platform to Linux and Mac as well. We can see how much overlap there's between PowerShell script and rakefile, if both of them should survive, or merge rakefile in powershell, or what.

[amirrajan]

PowerShell build script has been created.

I died a little inside.

Anyway, if we want to keep that around, PowerShell works on Windows machines, but has been ported cross-platform to Linux and Mac as well.

Gross. But I think in the long run killing the ruby/rake dependency is probably best.

[BrainCrumbz]

Additional notes:

• Rakefile still references nunit.framework.dll, which is now an obsolete dependency and should not be part of released package. Actually, probably there's no need for that :ilmerge task anymore.

• :spec testing task could be changed in favour of dotnet test. That would test all targeted frameworks, and there would be no need to keep a copy of NUnit.Runners.2.6.0.12051, as dotnet restore would take care of downloading needed NUnit runner

• :samples task could be doubled in order to run tests targeting .NET Core as well, using .NET Core version of NSpecRunner

• when incrementing version, maybe also sln\SharedAssemblyInfo.cs could be modified