scientistproject / Scientist.net

A .NET library for carefully refactoring critical paths. It's a port of GitHub's Ruby Scientist library
MIT License
1.46k stars 95 forks source link

Upgraded to .NET Core RC2. #61

Closed joncloud closed 8 years ago

joncloud commented 8 years ago

I think this may resolve #54, however the new release is still a little confusing to me. I created a new local package, and installed it to an RC2 ConsoleApp with success.

@davezych do you have any experience with RC2?

joncloud commented 8 years ago

Just noting: I missed the build scripts. If this is the right direction, then I can address that too.

jpsingleton commented 8 years ago

At a glance, this looks like the right direction. But I don't have the time to test it just now.

It might be worth looking at how Dapper did this upgrade. Although they had to tweak a few things after that, so worth looking at the commits in master.

joncloud commented 8 years ago

I updated the dotnet target to be netstandard1.1, and updated the build scripts to use the new dotnet cli. One thing stood out though in the build output is that the dotnet pack command seemed to name the artifacts based upon the old version (not the one in the current project.json. I am unsure why it did that, but I may be missing something.

davezych commented 8 years ago

@joncloud sorry, been MIA for a whole bunch of different reasons this whole month.

I don't have a ton of experience with RC2 (more specifically the dotnet runner) but it looks like you got things figured out. I just reviewed this and the results of the appveyor build and it passes the eye test to me.

Have you tried the resulting package with a .NET 4.5 project/.NET Core project just to make sure the ref's and targets are all good?

joncloud commented 8 years ago

Yeah - I just did a re-test using the artifacts from the appveyor build, and the packages seem to be compatible with .NET 4.5 and .NET RC2 projects.

haacked commented 8 years ago

Yeah - I just did a re-test using the artifacts from the appveyor build, and the packages seem to be compatible with .NET 4.5 and .NET RC2 projects.

Sounds good to me. I'll have to trust you on this one. Anyone else have any concerns or should I go ahead and merge this?

jpsingleton commented 8 years ago

The latest CI package still says alpha5 even though project.json was updated to alpha6. I'm not sure if this is an issue though.

Perhaps it's just an Appveyor setting or maybe the FAKE build script might needs some changes. The final package from master will need a new name or it will conflict with the version on NuGet.

davezych commented 8 years ago

project.json is going away (this is the best link I could find that actually confirms this, but I do know it's true: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/). I don't know if that has anything to do with the package version still showing alpha5.

jpsingleton commented 8 years ago

This blog post that I linked to in the issue explains the project.json removal a bit more: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json

I'm not sure what the correct way to package libraries is now. The docs say:

Some details are subject to change as the toolchain evolves.

joncloud commented 8 years ago

After a little bit more research I found we're parsing the data from ReleaseNotes.md. I updated it based upon what current data is there, and I suspect the appveyor build should provide the correct version. Local testing of build.cmd CreatePackages provides the correct naming.

davezych commented 8 years ago

Oh yes, that thing I did that I forgot about.

Good job, @joncloud :+1:

haacked commented 8 years ago

So, is this ready to merge? I'm not set up to test it right now.

joncloud commented 8 years ago

I think so.

haacked commented 8 years ago

:thumbsup: