[WIP] Update FAKE-5 to Netcoreapp20

.paket/Paket.Restore.targets

@@ -35,6 +35,7 @@
     <!-- Step 1 Check if lockfile is properly restored -->
     <PropertyGroup>
       <PaketRestoreRequired>true</PaketRestoreRequired>
+      <NoWarn>$(NoWarn);NU1603</NoWarn>
     </PropertyGroup>
 
     <PropertyGroup Condition="Exists('$(PaketRestoreCacheFile)') ">

.travis.yml

@@ -11,7 +11,7 @@ addons:
       - libunwind8
 
 before_script:
-  - wget https://github.com/fsharp/FAKE/releases/download/5.0.0-alpha015/fake-dotnetcore-ubuntu.14.04-x64.zip -O /tmp/fake-dotnetcore-ubuntu.14.04-x64.zip
+  - wget https://github.com/fsharp/FAKE/releases/download/5.0.0-alpha018/fake-dotnetcore-ubuntu.14.04-x64.zip -O /tmp/fake-dotnetcore-ubuntu.14.04-x64.zip
   - mkdir fake-dotnetcore
   - unzip /tmp/fake-dotnetcore-ubuntu.14.04-x64.zip -d fake-dotnetcore || echo unzip returned $?
   - export PATH=$PATH:$PWD/fake-dotnetcore/

RELEASE_NOTES.md

@@ -1,3 +1,7 @@
+#### 5.0.0-beta001 - 24.09.2017
+* BREAKING-CHANGE: Rework Fake.Core.Target package - https://github.com/fsharp/FAKE/pull/1664
+* ENHANCEMENT: Update fake 5 to netcoreapp20 - https://github.com/fsharp/FAKE/pull/1678
+
 #### 5.0.0-alpha018 - 24.09.2017
 * BUGFIX: Cache loaded assemblies and redirect later calls.
 

build-web-bundles.fsx

@@ -57,4 +57,4 @@ Target "Default" DoNothing
     ==> "Default"
 
 // start build
-RunParameterTargetOrDefault "target" "Default"
+RunTargetOrDefault "Default"

build.fsx

@@ -191,7 +191,7 @@ let dotnetAssemblyInfos =
       "Fake.Core.ReleaseNotes", "Parsing ReleaseNotes"
       "Fake.Core.SemVer", "Parsing and working with SemVer"
       "Fake.Core.String", "Core String manipulations"
-      "Fake.Core.Targets", "Defining and running Targets"
+      "Fake.Core.Target", "Defining and running Targets"
       "Fake.Core.Tasks", "Repeating and managing Tasks"
       "Fake.Core.Tracing", "Core Logging functionality"
       "Fake.Core.Xml", "Core Xml functionality"
@@ -439,10 +439,12 @@ Target.Create "BootstrapTestDotnetCore" (fun _ ->
             let fileName =
                 if Environment.isUnix then "nuget/dotnetcore/Fake.netcore/current/fake"
                 else "nuget/dotnetcore/Fake.netcore/current/fake.exe"
-            Process.ExecProcess (fun info ->
-                info.FileName <- fileName
-                info.WorkingDirectory <- "."
-                info.Arguments <- sprintf "run %s --target %s" script target) timeout
+            Process.ExecProcessWithLambdas (fun info ->
+                    info.FileName <- fileName
+                    info.WorkingDirectory <- "."
+                    info.Arguments <- sprintf "run %s --target %s" script target)
+                timeout
+                true (Trace.traceFAKE "%s") Trace.trace
 
 
         let result = executeTarget "PrintColors"
@@ -717,7 +719,7 @@ Target.Create "DotnetPackage" (fun _ ->
     let outDir = nugetDir @@ "Fake.netcore" @@ "portable"
     Cli.DotnetPublish (fun c ->
         { c with
-            Framework = Some "netcoreapp1.1"
+            Framework = Some "netcoreapp2.0"
             OutputPath = Some outDir
         }) netcoreFsproj
 )

help/markdown/contributing.md

@@ -104,7 +104,7 @@ to automatically deploy a preconfigured virtual machine. See the [Vagrant docs](
 
 ## API-Design
 
-We [learned from our mistakes](fake-fake5-learn-more.html), so we use the following guidelines:
+We [learned from our mistakes](fake-fake5-learn-more.html), so we use the following guidelines, **please read them very carefully** (ask if you don't understand any rule):
 
  - AutoOpen is no longer used
  - we replace `<verb><module>` functions with `<module>.<verb>`
@@ -113,7 +113,11 @@ We [learned from our mistakes](fake-fake5-learn-more.html), so we use the follow
  - For compatibility reasons (migration from legacy). We assume the user doesn't open the global `Fake` namespace.
 
    -> This means we don't add anything in there in the new API.
- - Old APIs are marked as Obsolete with a link (hint) to the new API location.
+ - Old APIs are marked as Obsolete with a link (hint) to the new API location. We use codes to make explicit 
+    - FAKE0001 for moving part from one Module to another
+    - FAKE0002 for removed API we don't know who is using it and how => please open an issue if you use it
+    - FAKE0003 for API that is no more accessible (basically became internal) => please open an issue if you use it
+    - FAKE0004 for API not yet migrated, waiting for your contribution
  - Operators are opened seperatly with a separate `Operators` module
  - We avoid the `Helpers` suffix (because we now expect users to write `<module>.<function>`)
 

help/markdown/core-targets.md

@@ -53,27 +53,27 @@ Now we have the following options:
 ## Final targets
 
 Final targets can be used for TearDown functionality. 
-These targets will be executed even if the build fails but have to be activated via ActivateFinalTarget().
+These targets will be executed even if the build fails but have to be activated via Target.ActivateFinal().
 
-	FinalTarget "CloseSomePrograms" (fun _ ->
+	Target.CreateFinal "CloseSomePrograms" (fun _ ->
 		// close stuff and release resources
 	)
 
-	// Activate FinalTarget somewhere during build
-	ActivateFinalTarget "CloseSomePrograms"
+	// Activate Final target somewhere during build
+	Target.ActivateFinal "CloseSomePrograms"
 
 
 ## Build failure targets
 
 Build failure targets can be used to execute tasks after a build failure.
-These targets will be executed only after a build failure but have to be activated via ActivateBuildFailureTarget().
+These targets will be executed only after a build failure but have to be activated via ActivateBuildFailure().
 
-	BuildFailureTarget "ReportErrorViaMail" (fun _ ->
+	Target.CreateBuildFailure "ReportErrorViaMail" (fun _ ->
 		// send mail about the failure
 	)
 
-	// Activate BuildFailureTarget somewhere during build
-	ActivateBuildFailureTarget "ReportErrorViaMail"
+	// Activate Build Failure Target somewhere during build
+	Target.ActivateBuildFailure "ReportErrorViaMail"
 
 ## Visualising target dependencies
 
@@ -87,7 +87,7 @@ the dependency graph to the standard output *instead* of building anything. This
 the build script contains a call like this:
 
 ```
-RunTargetOrDefault "Default"
+Target.RunOrDefault "Default"
 ``` 
 
 ### Example
@@ -113,15 +113,15 @@ resulting in an image like this:
 ![graph](pics/specifictargets/graph.png "Dependency graph")
 
 
-# Using FAKE's parallel option
+## Using FAKE's parallel option
 
 Since multithreading is beneficial (especially for large projects) FAKE allows to specify the
 number of threads used for traversing the dependency tree.
 This option of course only affects independent targets whereas dependent targets will
 still be exectued in order.
 
 
-## Setting the number of threads
+### Setting the number of threads
 The number of threads used can be set using the environment variable ``parallel-jobs``.
 This can be achieved in various ways where the easiest one is to use FAKE's built-in support for 
 setting environment variables:

help/markdown/fake-commandline.md

@@ -96,24 +96,23 @@ For this short sample we assume you have the latest version of FAKE installed an
     source https://nuget.org/api/v2
     source ../../../nuget/dotnetcore
 
-    nuget Fake.Core.Targets prerelease
+    nuget Fake.Core.Target prerelease
     nuget FSharp.Core prerelease
     -- Fake Dependencies -- *)
 	open Fake.Core
-	open Fake.Core.Targets
 
-	Target "Clean" (fun () ->  trace " --- Cleaning stuff --- ")
+	Target.Create "Clean" (fun () ->  trace " --- Cleaning stuff --- ")
 
-	Target "Build" (fun () ->  trace " --- Building the app --- ")
+	Target.Create "Build" (fun () ->  trace " --- Building the app --- ")
 
-	Target "Deploy" (fun () -> trace " --- Deploying app --- ")
+	Target.Create "Deploy" (fun () -> trace " --- Deploying app --- ")
 
 
 	"Clean"
 	  ==> "Build"
 	  ==> "Deploy"
 
-	RunTargetOrDefault "Deploy"
+	Target.RunOrDefault "Deploy"
 
 If you are on windows then create this small redirect script:
 

help/markdown/fake-fake5-custom-modules.md

@@ -48,7 +48,7 @@ One example would be:
     (* -- Fake Dependencies paket-inline
     source https://nuget.org/api/v2
 
-    nuget Fake.Core.Targets prerelease
+    nuget Fake.Core.Target prerelease
     nuget MyTaskNuGetPackage
     -- Fake Dependencies -- *)
     #load "./.fake/build.fsx/intellisense.fsx"

help/markdown/fake-fake5-modules.md

@@ -15,7 +15,7 @@ Create a new file `paket.dependencies` and add the following content
 group NetcoreBuild
     source https://nuget.org/api/v2
 
-    nuget Fake.Core.Targets prerelease
+    nuget Fake.Core.Target prerelease
 ```
 
 Now you can directly use `open Fake.Core` and use the [Target module](core-targets.html).
@@ -86,7 +86,7 @@ To write your build dependencies in-line you can put the following at the top of
     (* -- Fake Dependencies paket-inline
     source https://nuget.org/api/v2
 
-    nuget Fake.Core.Targets prerelease
+    nuget Fake.Core.Target prerelease
     -- Fake Dependencies -- *)
     #load "./.fake/build.fsx/intellisense.fsx"
 

help/markdown/fake-migrate-to-fake-5.md

@@ -4,7 +4,7 @@
 
 In this tutorial you will learn how to migrate your existing build scripts to the new FAKE 5 dotnet-core version.
 
-First we want you to know that there are two version of FAKE 5. One is just an update to the regular FAKE 4, but contains the new netcore API.
+First we want you to know that there are two versions of FAKE 5. One is just an update to the regular FAKE 4, but also contains the new API.
 We will call this the "legacy FAKE version" it is just like the FAKE you are already used to. The second version is the "new/dotnetcore/standalone FAKE 5" or just "FAKE 5".
 This "new" version has several advantages:
 
@@ -13,30 +13,35 @@ This "new" version has several advantages:
 * Paket bootstrapper / build.cmd and build.sh are no longer required (you can still use them)
 * This will be the only Version available in FAKE 6
 
-Therefore you have the FAKE 5 timeframe to update your build scripts to the new version.
+Therefore you have the FAKE 5 timeframe to update your build scripts to the new version. If you have any issues in the migration process, please see [how to fill issues or discuss about your issues](/contributing.html) (don't be shy about contributing ;)).
 
 ## Migration Guide
 
-Upgrading to FAKE 5 is a multi step process and has various manual steps in between. Here are the steps:
+Upgrading to FAKE 5 is a multi step process and has various manual steps in between. **If you do these steps out of order it will be a lot harder for you to migrate the script successfully**. Here are the steps:
 
-- Regular update to FAKE 5. This should not be breaking. If it breaks you please open an issue.
-- Fix all the (obsolete) warnings in your build-script to use the new API (see the 'Use the new FAKE-API' section).
+- Update to legacy FAKE 5. This should not be breaking. If it breaks you please open an issue.
+
+  - With Paket: add `prerelease` after `nuget FAKE` in paket.dependencies file then `.paket/paket.exe update FAKE`, check that paket.lock references FAKE version 5 
+
+- Fix all the (obsolete) warnings in your build-script to use the new API (see the [Use the new FAKE-API](#Use-the-new-FAKE-API) section).
   This should still not break your build. If things break here or you have difficulties after reading the 'Use the new FAKE-API' section
   please open an issue.
+  - Becareful if you update only some warning, it could break. For example, if you use `Target.Create`, but continue to use old operators definition, you will probably experiment some errors like "Target [...] is not defined".  
 - Change to the new version of FAKE 5.
 
   - This is for example done by installing FAKE as dependency on your build infrastructure.
     There are a variety of installing options available. (TODO: Link to 'installing FAKE' section)
   - Add a FAKE header (TODO: add Link), and tell FAKE which features/packages you want to use in the dependencies file or in-line.
-    See the 'Adding FAKE dependencies' section below.
-  - Run the build with the new version of FAKE :). You might want to read the 'CLI migration' section
+    See the [Adding FAKE dependencies](#Adding-FAKE-dependencies) section below.
+  - Run the build with the new version of FAKE :). You might want to read the [CLI migration](#CLI-Migration) section
 
   If things break in the last step please let us know as well.
 
-If you do these steps out of order it will be a lot harder for you to migrate the script successfully.
-
 ### Use the new FAKE-API
 
+After upgrading to legacy FAKE 5 the warnings should tell you exactly what you do. If there is stuff missing or a warning message should be improved let us know.
+Some warnings indicate how we want the new FAKE version to be used.
+
 The most important part to know is that basically every feature/function changes its location and sometimes they were even grouped in different modules
 as the old API was growing several years now and we never could do breaking changes.
 
@@ -49,21 +54,17 @@ as the old API was growing several years now and we never could do breaking chan
   So please try it out and if stuff breaks let us know :).
   The good thing is you can always "lock" the versions of the FAKE modules until you are ready to upgrade.
 
-After upgrading to legacy FAKE 5 the warnings should tell you exactly what you do. If there is stuff missing or a warning message should be improved let us know.
-Some warnings indicate how we want the new FAKE version to be used.
-
-The "open Fake" and AutoOpen modules are completely obsolete. 
-We urge you to finish your API-Migration (after fixing all warnings) by removing "open Fake".
-This removes a lot of automatically opened stuff and if your build fails you ar probably stuff where we forgot to add the obsolete warning (let us know) or that 
-stuff you are using was not migrated yet (let us know or send a PR, TODO: Add link to guideline).
-
 In this new work you should write "Module.Method a b" instead of "MethodModule a b". Which means in the old world we had lots of methods like
 "ReadFile argument" (the module probably even opened via `[<AutoOpen>]`), which is considered bad style now.
 In the new world we would open the `Fake.IO.FileSystem` namespace to indicate that we are using the file-system.
 At the same time we would write `File.Read argument`, which is only a bit longer but now the IDE can help you a lot better and the code looks a lot more ideomatic and clean.
 
 > If you still find places where we use the "bad" style in the new API, let us know (open an issue).
 
+The "open Fake" and AutoOpen modules are completely obsolete. 
+We urge you to finish your API-Migration (after fixing all warnings) by removing "open Fake".
+This removes a lot of automatically opened stuff and if your build fails you have probably stuff where we forgot to add the obsolete warning (let us know) or that 
+stuff you are using was not migrated yet (let us know or send a PR, TODO: Add link to guideline).
 
 ### Add FAKE dependencies
 

integrationtests/core-reference-fake-core-targets/before/reference_fake-targets.fsx

@@ -3,7 +3,7 @@ storage: none
 source https://nuget.org/api/v2
 source ../../../nuget/dotnetcore
 
-nuget Fake.Core.Targets prerelease
+nuget Fake.Core.Target prerelease
 nuget FSharp.Core prerelease
 -- Fake Dependencies -- *)
 

paket.dependencies

@@ -1,4 +1,4 @@
-version 5.97.0
+version 5.100.2
 content: none
 // just in case we need some special nuget feature again...
 //source https://ci.appveyor.com/nuget/paket
@@ -57,6 +57,7 @@ group Build
     source https://api.nuget.org/v3/index.json
     source https://ci.appveyor.com/nuget/fake
     source https://ci.appveyor.com/nuget/fsharp-formatting
+    source https://dotnet.myget.org/F/roslyn-tools/api/v3/index.json
 
     nuget FSharp.Core ~> 4.1.0
     nuget Nuget.CommandLine
@@ -65,6 +66,7 @@ group Build
     nuget FSharp.Formatting.CommandTool prerelease
     nuget SourceLink.Fake
     nuget ILRepack
+    nuget RoslynTools.ReferenceAssemblies
 
     github fsharp/FAKE modules/Octokit/Octokit.fsx
 
@@ -77,7 +79,7 @@ group NetcoreBuild
     nuget FSharp.Core ~> 4.1.0
     nuget System.AppContext prerelease
     nuget Paket.Core prerelease
-    nuget Fake.Core.Targets prerelease
+    nuget Fake.Core.Target prerelease
     nuget Fake.Core.Globbing prerelease
     nuget Fake.Core.SemVer prerelease
     nuget Fake.IO.FileSystem prerelease
@@ -96,28 +98,18 @@ group NetcoreBuild
     nuget Fake.Tools.Git prerelease
     nuget Mono.Cecil prerelease
     nuget Octokit
-    // Something strange is going on.
-    nuget System.Reflection.TypeExtensions 4.3.0
 
 group netcore
     //source https://ci.appveyor.com/nuget/paket
     source https://api.nuget.org/v3/index.json
     storage: none
-    framework: netstandard1.6, netcoreapp1.1
+    framework: net46, netstandard1.6, netstandard2.0, netcoreapp2.0
 
-    nuget Microsoft.NETCore.App !~> 1.1
+    nuget Microsoft.NETCore.App framework: netstandard1.6, netstandard2.0, netcoreapp1.1
     nuget FSharp.Compiler.Service storage: packages, content: none
-    nuget Microsoft.DotNet.PlatformAbstractions !~> 1
-    // START _ REMOVE ME ONCE PAKET WORKS https://github.com/fsprojects/Paket/issues/2715
-    nuget Microsoft.NETCore.DotNetHostPolicy !~> 1.1
-    nuget Microsoft.NETCore.Platforms !~> 1.1
-    nuget Microsoft.NETCore.DotNetHostResolver !~> 1.1
-    nuget Microsoft.NETCore.Runtime.CoreCLR !~> 1.1
-    nuget Microsoft.NETCore.Jit !~> 1.1
-    nuget Microsoft.NETCore.Targets !~> 1.1
-    // END _ REMOVE ME ONCE PAKET WORKS
+    nuget Microsoft.DotNet.PlatformAbstractions ~> 2.0
 
-    nuget NETStandard.Library !~> 1.0
+    nuget NETStandard.Library ~> 2.0
     nuget FSharp.Core ~> 4.1.2
     nuget Argu
     nuget Octokit