8 Referencing Other Projects
Craig Oates edited this page 4 years ago

From a personal point-of-view, I like to keep "plumbing code" and "business logic" separate. The most common approach I take to do this is create various library projects and reference them in the main project. This all happens in the same solution if I can help it. Because of this preference, I designed Console.Waterworks (C.W.) to operate with this as the default context.

To help get a feel for how Console.Waterworks (C.W.) based projects looks when used with a library, I have set this repository up with one. Technically, there are two libraries but they are doing the same thing. The only difference is one is a tradition .Net library and the other is a .Net Core one.

If you look in the Solution Explorer, in Visual Studio, you will see four projects. Two of them are console programs and the other two are libraries. Each library is paired with a console project. So, in-effect, there are two "projects". Although, there is really on one project. This is because the "two" projects are different flavours on .Net. They both do the same thing, but target different environments. (.Net is in a bit of a mess at the time of writing this.)

solution overview

Feel free to focus on either the .Net or .Net Core "projects". They both mirror each other so, if you learn one, you learn the other. The only reason I included both was for the sake of completeness. The important thing to take away, here, is the console-to-library relationship.

console-library relationship

If we wanted to be more exact about the relationship, ConsoleCommands is bound to FunkyFish (or FunkyFishCore). And you can see this in the repositories code.

// This module resides in the BFLib project -- FunkyFish.fs.
module FunkyFish
    let LibraryTest1 x y = x + y
    let LibraryTest2 x y z = (x * y) * z
    let LibraryTest3 name = "Hello " + name
	
// This module resides in the BrittleFish project -- ConsoleCommands.fs.
namespace Commands
    module ConsoleCommands =

        open System
        open Console.Waterworks
        open Console.Waterworks.Attributes
        open FunkyFish // This is where the "LibraryTest" functions are -- in BFLib
		
		// The other functions in this file/module have been removed from brevity.
		
		[<ListCommand>]
		[<Description "Adds the two numbers together.">]
		[<Parameters "x:int y:int">]
		[<Usage "> libtest1 5 10">]
		let libtest1 x y =
			String.Format("Result: {0}" , LibraryTest1 x y) // Library Call to FunkyFish.
			
		[<ListCommand>]
		[<Description "Multiplies x and y together then mulitplies that by z or... (x * y) * z">]
		[<Parameters "x:int y:int z:int">]
		[<Usage "> libtest2 5 10 2">]
		let libtest2 x y z = 
			String.Format("Result: {0}", (LibraryTest2 x y z))// Library Call to FunkyFish.
			
		[<ListCommand>]
		[<Description "Appends the named passed into the console onto \"Hello\" and displays it in the console.">]
		[<Parameters "name: string">]
		[<Usage "> libtest3 \"Craig Oates\"">]
		let libtest3 name =
			String.Format("Result: {0}", LibraryTest3 name) // Library Call to FunkyFish.

consolecommands library binding

As you can see, once you are inside a command-method, you are free to put any code you want in there. For example, you can call your library code.

If you are unsure how to reference a .Net library in another project, within your solution, I have provided a link, which is: