Java developer needs help understanding the .NET build process in F#

Question

Most of my development has been in Java, where I am used to having a runtime, a compiler, and a build tool. So now I'm trying to come into the .NET world, specifically using VSCode, Ionide plugin, and F#, to build an F# program. I'm having a hard time understanding the direct comparisons with the Java build process. This is my rough understanding so far:

• JRE -> .NET Runtime?
• JDK tools -> Microsoft Build Tools 2015 which includes the F# compiler and other tools?
• Paket -> maven?
• FAKE -> maven's <build> section in pom.xml?
• paket.dependencies and paket.references -> maven's <dependencies> section in pom.xml?
• *.*proj file -> ???

I'm really confused about the *proj file. I thought that was related to MSBuild. But I'm confused because I thought FAKE was a replacment for MSBuild, but some examples of FAKE I've seen reference this file and pass it to and MSBuildRelease task.

Also, why does paket need a dependencies and references file?

I was hoping someone could confirm, clarify, add, or any of the above, to my level of understanding so far. Much appreciated!

Edit:

I know this question is convoluted and not very specific. Thank you all for taking the time to weed through it and answer what you're able. I appreciate it.

Answer 1

Since nobody has yet answered the Paket section of your question, I'll tackle that one.

In one Git repository, you might have multiple projects. For example, it's a very common pattern (so common that the ProjectScaffold repo is set up that way because it's what most people want) to have a separate project for your main code and for your tests. In your MyApp.fsproj file, you might not want to have a reference to NUnit or XUnit, but you do want those references in your MyApp.Tests.fsproj file.

The paket.dependencies file is one-per-repository, and it lists all the packages that any project in the repository wants to use. The paket.references files, plural, are one-per-project, and go in the same directory as the .fsproj files they correspond to. They list the packages that that project wants to reference. So in the paket.references file in the same directory as MyApp.Tests.fsproj, you would list NUnit or XUnit — but you would not list the unit-testing libraries in the paket.references file that's in the same directory as MyApp.fsproj.

If you only had one project in your Git repo, then there wouldn't be a need for separate paket.dependencies and paket.references files, as they could be combined into a single file that served both purposes. But as soon as you have multiple .fsproj files in a single repository, then the separation between dependencies and references becomes useful, as you can have all your dependencies listed in a single paket.dependencies file in your repo root, but give each project its own paket.references file so that it can reference only the subset of dependencies that it specifically needs.