text: References
  The Elements compiler uses references to pull in classes from external libraries – be it core framework libraries for the platform, third party libraries, or even your own libraries you created to contain code you are sharing between projects. Depending on the platform your project is targeting, references are to different file types, but the general concepts of references are the same.
  Elements knows three different types of references.
  - Plain (or Direct) References
  - Project References
  - Package References
  - Shared Project References
  Plain References
  Plain References are the simplest form of reference, where your project will point directly to a specific named library. The build chain will locate this library – either via a direct Hint Path to a local file or via a process called [Reference Resolving] that locates the library in a number of standard locations.
  Once found, the compiler will make all public types and APIs from the library available to your project's code (governed by the rules for accessing types across different Namespaces, of course).
  You can read more about Plain References here.
  You can add project references via the Add Reference dialog (all IDEs) or by simply dragging a File from Finder or Windows Explorer onto the "References" node of a project (Fire and Water).
  Project References
  Elements also supports so-called project references. Rather than pointing to a pre-compiled library somewhere on disk, project references point to a second project (that needs to be open as part of the same Solution).
  The build tool chain will automatically resolve project references, compile the connected projects in the right order, and make sure the output of the referenced projects will be used when compiling the referencing project. This process also takes into account the current Configuration and device type (e.g. iOS Device vs. iOS Simulator on Cocoa).
  Once resolved, the output of the referenced project is treated the same way as a plain and direct reference to that library file would be.
  Project references can also be on Cocoa to establish a relationship between an .app and Extensions or a Watch Kit App. Rather than resulting in a plain reference, the Extension will be embedded in the main app. Similar, Android SDK applications can reference an Android NDK Extension project, to have its code embedded for JNI.
  You can read more about Project References here.
  You can add project references via the Add Reference dialog described above (Visual Studio) or simply by dragging a library project node onto the "References" node of a different project (Fire and Water).
  Package References
  Package references, currently supported for .NET and Java only, are references to pre-compiled bundles of APIs that can be automatically obtained from an online package repository, at build time. These can include platform-vendor-provided or third party packages.
  Elements supports:
  - NuGet packages on the .NET
  - Gradle (i.e. Maven) packages on the Java, most frequently used on Android.
  You can read more about Package References here.
  You can add and adjust package references via the Add Reference dialog (all IDEs).
  Shared Project References
  Finally, Elements projects can also reference one or more Shared Projects. Referencing a shared project simply includes all the files contained in the shared project into the current project, and compiles or processes them as if they were part of the local project.
  You can read more about Shared Projects in general here, and about working with them in Fire and Water here.
  References vs. Namespaces
  It is important to not confuse references with Namespaces. While there is often a one-to-one mapping to which libraries contain which namespace, that overlap is arbitrary. A single referenced library can contain types in multiple namespaces (which may or may not be named the same as the library itself), and multiple libraries can contribute to the same namespace.
  When using first or third party frameworks and libraries, it is important to know both what namespaces the types you want to use are in, but also which libraries need to be referenced in order to make the types available, as well. For example, all standard Cocoa SDK libraries ship with Elements in library files that match their namespace –
  Foundation.fx contains the
  Foundation namespace,
  UiKit.fx contains the
  UIKit namespace, and so on. On the other hand, on .NET many core namespaces are located in
  mscorlib.dll and
  System.dll.