Project conversion to Paket and current version of ProjectScaffold

[jschiefer]

Here's a big and scary pull request for you. This implements the following changes:

• Update the base build.fsx and friends to the current version of fsprojects/ProjectScaffold (as per commit afdb450, 4/27/2016)
• This adds the following goodies:
  • Ability to use Paket
  • Adds documentation generators. This should address #39
  • Some boilerplate test code
  • Successfully builds with AppVeyor
• Converted build to Paket (easy, thanks to auto-migration).
• I manually fixed the example projects to use Paket-style references

There is some need for review. Particularly:

• I am not sure why the examples are in a separate solution. Personally, I would throw it all into the main one, but there is probably a good reason.
• Also, you may want to put the examples under src/
• Is the FsXaml.Demos.2012.sln still required? I tested this with VS 2013 Premium, don't have 2012 anymore.
• Are the F# compiler version and .Net versions in the individual fsproj files corrcect?
• The version specifications of the individual nugets imported by Paket should be checked for correctness.
• The way the AssemblyInfo.fs are handled seems to have changed with the newer version of ProjectScaffold. Check to make sure this does what you want.
• Generation of nuget-based releases is completely untested and probably broken. Good thing you just did a release! :-)

Let me know if anything needs fixing.

[ReedCopsey]

Jan:

I am not sure why the examples are in a separate solution. Personally, I would throw it all into the main one, but there is probably a good reason.

With Type providers, you can't have them together, or you can't use the provider. You have to basically compile the TP, then start up demos, shut it down, make changes, start it up (in separate VS).

Also, conceptually, the demos project is more for "end users" to see vs. the main project "developers of FsXaml"

Also, you may want to put the examples under src/

I see src/ as the main source for FsXaml itself. Prefer to keep it separate.

Is the FsXaml.Demos.2012.sln still required? I tested this with VS 2013 Premium, don't have 2012 anymore.

It's only required if we want to support VS 2012. I know of at least one user still there, but now that power tools moved off, I'm okay dropping it.

Are the F# compiler version and .Net versions in the individual fsproj files corrcect?

They should be. Did you see something weird in there?

The version specifications of the individual nugets imported by Paket should be checked for correctness.

For these purposes, I don't think they matter much.

The way the AssemblyInfo.fs are handled seems to have changed with the newer version of ProjectScaffold. Check to make sure this does what you want.

Project Scaffold was never really intended to work with type provider projects, so I was always doing it manually. Would be nice to make it work.

Generation of nuget-based releases is completely untested and probably broken. Good thing you just did a release! :-)

I've done this manually - I don't mind doing it. I'd probably like to either remove or fix the automatic nuget support - but I'm fine with either route.

Thanks for all of this - I think I'll merge it, but would you be willing to help with the remaining stuff above?

[jschiefer]

Thanks for the clarifications. I am still at the point where Type Providers contain an element of Magic, so this is helpful.

I am certainly happy to help with the rest of these issues. The only thing that struck me as odd about the versions is that the FsXaml components are built with F# 3.0, the demos are built with F# 3.1 and the (autogenerated and mostly empty) FsXaml.Tests project is targeted for a version 4.4.0.0 of the F# runtime (which I think goes with F# 4.0). Regardless of what the targeted runtime is, it would probably be good to have the same one everywhere. The targeted .Net framework version is 4.5 everywhere, which is probably a good choice.

I think it would be nice to automatically build a nuget binary every so often (with automatically increasing build number), but I can't say I understand the special considerations for type providers. I'll play around with this a little and see whether I can figure it out.

[ReedCopsey]

@jschiefer We have F# 3 in the type provider to give it the furthest "reach".

For tests project (which didn't exist until this PR) and demos, it really doesn't matter. We could switch all of the demos to using F# 4, if we wanted to do so. I had the demos on 3.1 because it's much nicer to use than 3.0, but 4 would be even nicer there - so maybe we should switch those across. They're not deployed, so it's really less important, but 4 would require VS 2015 to use, where keeping them 3.1 lets VS2013 users try the demos.