Skip to content

Migration to .NET Standard 2.0 - #360

Merged
panesofglass merged 27 commits into
fsprojects:masterfrom
ChrSteinert:master
Mar 8, 2018
Merged

panesofglass merged 27 commits into
fsprojects:masterfrom
ChrSteinert:master

Conversation

@ChrSteinert

@ChrSteinert ChrSteinert commented Feb 18, 2018

Copy link
Copy Markdown
Contributor

This upgrades the project to .NET Core 2.0.
Also, necessary type anotations for new core 2.0 APIs had been made.

  • Migrate to SDK project file format
  • Upgrade to .NET Standard 2.0
  • Migrate test
  • Fix build
  • Reenable SourceLink
  • Fix Tests
  • Fix NuGet packaging

Upgrades to .NET Core 2.0.
Makes necessary type anotations for new core 2.0 APIs.
@panesofglass

Copy link
Copy Markdown
Contributor

@ChrSteinert SourceLink changed a lot, so you can remove what's in there now. @ctaggart can probably help with the new version of SourceLink.

@ChrSteinert

Copy link
Copy Markdown
Contributor Author

Cool, thanks for the update. Will move on without it then (this should make things easier for now ;) )

@ChrSteinert ChrSteinert changed the title [WIP] Migration to .NET Standard 2.0 Migration to .NET Standard 2.0 Mar 1, 2018
@ChrSteinert

Copy link
Copy Markdown
Contributor Author

Ok - I guess I am happy with this for now. Would love to get some feedback on this!

@panesofglass panesofglass left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good! Thank you for your efforts so far. I made a few comments about the build script based on feedback I received from @enricosada. You can see an example of what I mean here.

Comment thread .travis.yml Outdated
language: csharp

mono: latest
dotnet: 2.1.4

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this require 2.1.4? If not, shouldn't we keep it as low as possible or use a matrix to test multiple versions?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I'd guess 2.0.3 is the lowest possible.

Comment thread build.fsx Outdated

Target "Clean" (fun _ ->
!! solutionFile |> MSBuildRelease "" "Clean" |> ignore
// !! solutionFile |> MSBuildRelease "" "Clean" |> ignore

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Call dotnet clean? Is that a thing?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a thing! :)

Comment thread build.fsx Outdated
#endif
|> ignore
!! solutionFile |> MSBuildRelease "" "Restore" |> ignore
!! solutionFile |> MSBuildRelease "" "Build" |> ignore

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably use the DotNetCli module here to run the restore and build, which should be one task with that module.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was reverting back to MSBuild for travis to be happy. See this CI run: https://travis-ci.org/fsprojects/FSharpx.Extras/builds/345267943?utm_source=github_status&utm_medium=notification

I would assume this can only be "fixed" with only compiling to netstandard.
Any opinions on dropping net45?

Comment thread build.fsx Outdated
// Build a NuGet package

Target "NuGet" (fun _ ->
Paket.Pack(fun p ->

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer the DotNetCli module to Paket.

<DocumentationFile>bin\Debug\FSharpx.Extras.xml</DocumentationFile>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<TargetFramework>net45</TargetFramework>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we add netstandard2.0?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow - the main part slipped me …

<AssemblyName>FSharpx.Text.StructuredFormat</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion>
<TargetFramework>net45</TargetFramework>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add netstandard2.0?

<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<TargetFramework>net45</TargetFramework>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test with netcore2.0?

<AssemblyName>FSharpx.Tests</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion>
<TargetFramework>net45</TargetFramework>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test with netcore2.0?

Adds System.Reflection.Emit.Lightweight for Emit.DynamicMethod on .NET Standard 2.0.
@ChrSteinert ChrSteinert changed the title Migration to .NET Standard 2.0 [WIP] Migration to .NET Standard 2.0 Mar 2, 2018
@ChrSteinert

Copy link
Copy Markdown
Contributor Author

I hope having a fresh lock file is an okish thing to have‽

@ChrSteinert

Copy link
Copy Markdown
Contributor Author

Hmm. Tests succeed, but Pakets reports an error. How unfortunate.

Comment thread build.fsx Outdated
OutputPath = "bin"
Version = release.NugetVersion
ReleaseNotes = toLines release.Notes})
OutputPath = "bin" })

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will also rebuild without specifying you want to skip it.

@ChrSteinert ChrSteinert changed the title [WIP] Migration to .NET Standard 2.0 Migration to .NET Standard 2.0 Mar 3, 2018
@ChrSteinert

Copy link
Copy Markdown
Contributor Author

Cool - added the --no-build to save the environment ;)
I am happy with this again ;)

Comment thread build.fsx Outdated
{ p with
OutputPath = "bin" })
OutputPath = "bin"
AdditionalArgs = [ "--no-build" ] })

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@panesofglass

Copy link
Copy Markdown
Contributor

@forki, @enricosada, or anyone else want to weigh in before we merge?

@enricosada enricosada left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some feedback.

for sourcelink you can do like FSAC ( https://github.com/fsharp/FsAutoComplete/blob/master/src/Directory.Build.props ) or directly add these in paket (should work now afaik, target will be imported correctly for privateassets)

About commands, probably is easyer to call all targets against the solution, instead for earch project.
result is pretty much the same, but is faster. You call on this, no hard feeling. my idea is dotnet build FSharpx.Extras.sln or just dotnet build from root should do (same for dotnet test, dotnet pack, etc).

</PropertyGroup>
<PropertyGroup Condition="$(TargetFrameworkVersion) == 'v4.0'">
<DefineConstants>NET40</DefineConstants>
<DocumentationFile>bin\$(Configuration)\$(TargetFramework)\$(AssemblyName).xml</DocumentationFile>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is old style 😄

you can replace with

<GenerateDocumentationFile>true</GenerateDocumentationFile>

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, have never seen that. That is awesome. Will put it in!

Comment thread src/FSharpx.Extras/paket.template Outdated
FSharpx.Extras implements general functional constructs on top of the F# core library. Its main target is F# but it aims to be compatible with all .NET languages wherever possible.

files
src/FSharpx.Extras/bin/Release/net45/* ==> lib/net45

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you really need that? you can generate with dotnet pack. paket support that (will use paket refs)

</PropertyGroup>
<PropertyGroup Condition="$(TargetFrameworkVersion) == 'v4.5'">
<DefineConstants>NET45</DefineConstants>
<DocumentationFile>bin\$(Configuration)\$(TargetFramework)\$(AssemblyName).xml</DocumentationFile>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like previous, use <GenerateDocumentationFile>true</GenerateDocumentationFile>

FSharpx.Extras implements general functional constructs on top of the F# core library. Its main target is F# but it aims to be compatible with all .NET languages wherever possible.

files
src/FSharpx.Text.StructuredFormat/bin/Release/net45/* ==> lib/net45

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same dotnet pack

@ChrSteinert

Copy link
Copy Markdown
Contributor Author

dotnet build already targets the SLN file. For test I opted to specify projects specifically because FAKE will think that test failed in projects without tests in it and fail the whole build.

One additional thing I noticed; dotnet pack does not correctly set the version of the package. It is always 1.0.0.0. Any clues?

@enricosada

Copy link
Copy Markdown

@ChrSteinert dotnet pack /p:Version=1.2.3 will generate a package with that version (ideally also setting the attributes of assembly like Version and FileVersion, but atm doesnt work for F#, is not implemented).
you can also use /p:PackageVersion=1.2.3 (that will just set package version leaving assembly info as is)

probably you can move all the paket.template attributes in fsproj or a Directory.Build.props. you can see the full list in https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#nuget-metadata-properties , for example the descvription is <Description>my description</Description> or "/p:Description=my description" or setting an env var Description

@ChrSteinert

Copy link
Copy Markdown
Contributor Author

OK - so move away from Pakets pack to .NET. Will do that.

@ChrSteinert

Copy link
Copy Markdown
Contributor Author

@enricosada How does it look now?

@enricosada enricosada left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@panesofglass
panesofglass merged commit 5ac4edd into fsprojects:master Mar 8, 2018
@toburger

Copy link
Copy Markdown

Any chance to get this published to NuGet?

@panesofglass

Copy link
Copy Markdown
Contributor

@enricosada or @forki, do either of you know how publishing works now? I haven't done much with this set of projects in quite some time.

@sergey-tihon

sergey-tihon commented Jun 2, 2018

Copy link
Copy Markdown
Member

@panesofglass would you like to become a maintainer of this project? (I can add you to NuGet package owners)

I guess that @forki does not mind

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.

5 participants