In this example we start off by formatting a volume then creating a “Develop” directory, obviously you can just create the folder somewhere without formatting.

Give “SpludlowGroup” Permissions

NOTE: Do not set permissions on the C drive (at the top level) under any circumstances.

If you are creating a directory on an existing volume that contains other files then set the permissions on that folder rather than the whole volume.

The benefits of giving “SpludlowGroup” full control over an entire separate volume is that you won’t have to worry about permissions with the Framework performing operations on any files on that volume. You may create work directories or dump test data there.

Create an empty Visual Studio solution

A “solution” is a container for “projects” which are the individual applications like DLLs, Webs, EXEs.

The solution is all contained within a directory “WeiredSystems” and the main file is “WeiredSystems.sln”

After creating the solution Visual Studio is closed then launched from the .sln file, the easiest way to open a solution.

Basics of Visual Studio Program Layout

Obviously Visual Studio has a lot of functionality but don’t worry, you only need to learn a small part of it to start creating applications.

The panel on the right is the “Solution Explorer” this is where you do all your navigation of projects and individual code files. It’s pretty intuitive and many actions can be performed here. Try right clicking on things for menus.

The “Toolbox”, which is shown being pinned on the left, is where controls that you drag to you design surfaces will be, like dragging a button onto a form. When just writing normal code it don’t relay do that much, but I like to have it pinned.

The “Output Window” shown at the bottom will show the output from the compiler (the thing that makes the DLLs and EXEs from source code).

These panels can also be tabbed, for example the “output window” will share with the “error list” you can switch between them easily by clicking the tabs.

Below the “Solution Explorer” in the bottom left is where the “Properties” will appear (when you create something in the next step) it shows the properties of whatever is selected and you can also make changes here (to the currently selected item in Solution Explorer).

Create a Class Library (.NET Framework)

A Class library is where you should put all you code that does things (business logic). You reference it from other projects (including the Spludlow Framework) so you can share code between applications. It is physically compiled into a .DLL file.

Right clicking on the solution allows you to “Add->New Project…” choose a “Class Library (.NET Framework)” and ensure the version of .net you are targeting is correct.

Name the class library “WeiredSystems” so the final DLL will be “WeiredSystems.DLL”, this is the one project that will have the same name as the solution.

NOTE: You may have noticed “.NET Core” and “.NET Standard” these are newer technologies than the original “.NET Framework” that the Spludlow Framework uses. In the future .net development will move to these new APIs, but for now we will stick to the “.NET Framework”.

Add a Class to the library

Delete the automatically created “Class1.cs” and add a new class by right clicking on the project and selecting “Add->New Item...->Class” and name it: “HelloWorld.cs”.

Change the class to “public” this means you can call it from elsewhere. Now add a method:

public static string SayHello(string name)

{

return "Hello " + name + " from " + Environment.MachineName;

}

Pretty obvious what’s this is doing it will return a string that will let you know what machine it’s running on.

Click on the “double disk” icon this means save all.

Add a Windows Forms Test Application

Now let’s make a UI front end application that we can call our code from. This application is not meant to be used by anyone except you, purely for developing and test running code.

Right click the solution “Add->New Project…” choose “Windows Form App (.NET Framework)” and ensure the version of .net you are targeting is correct.

NOTE: Windows Forms are the original Windows UI programs, to keep things as simple as possible then use these. WPF (Windows Presentation Framework) are the newer types of Windows UI application.

Name the application “TestForm” so the final program will be “TestForm.exe”. You will be presented with a Windows program window in the design surface.

Add a test button and put some code in the buttons click method

Right click the project and select “Set as StartUp Project” this means when you start debugging from Visual Studio this application will be started.

Drag a button from the toolbox onto your windows and double click it. You will be taken to this method:

private void button1_Click(object sender, EventArgs e)

{

}

If you haven’t guessed then this is the method that will run when you click the button. Don’t worry about the “sender” and “e” you don’t need them.

Add a reference to your class library and run the test application

Right click on references in the “TestForm” project and select “Add Reference…” select “Projects” and tick “WeiredSystems” (the DLL you created earlier). Your test form now has a reference to your DLL.

Put some very simple code at the top and bottom of your method so you can display a “result” string:

private void button1_Click(object sender, EventArgs e)

{

string result = null;

// develop and test here !!!

if (result == null)

result = "[NULL]";

MessageBox.Show(result);

}

Now if you do anything to set the “result” string in the middle of your method it will be displayed at the end. The null stuff is just so you can tell the difference between an empty string and null.

Put the call to the DLL in the middle of the method:

result = WeirdSystems.HelloWorld.SayHello("fred");

Go to the “Debug” menu and “Start without Debugging”, your source code will be automatically saved, the program will be compiled and ran. The form should appear click the button and the Message Box will be displayed.

NOTE: I don’t normally bother debugging unless I’ve got problems it will just run quicker

To recap on the DLL and test Application

So what have we achieved here? Well not that much but a pretty good starting point especially if you are new to any of this.

The Class library DLL is now ready for you to add as much code as you can write.

The test form may seem pointless but is fine for calling code during development, pretty much everything I have ever developed has started out in “button1_Click”.

The most important thing you should have learnt from this is always separate business logic and UI code from day one. If you start out with your own DLL you can call it from anywhere.

Spludlow Framework - Set a Develop Source host then download latest binaries and release to all hosts

See above video.

Configure your Development machine as a “Develop Source”

When a machine is configured as a Develop Source it can used as a source in the Spludlow release system to push applications out to other hosts.

Go to the Spludlow Intranet Config page and edit the host that will be your develop source “WSYS-HEAD-DEV” in this case. Set the Boolean “DelevlopSource” to “True”.

Select all hosts, using the toggle button, and send the configuration to all hosts. Use the Logs and Status pages to check it has finished without any problems.

When a machine is a “Develop Source” it means the Intranet Release page will include it as a source in the dropdown list.

Download latest Spludlow Binaries

Go to the Intranet Call page and change the host dropdown to the development machine “WSYS-HEAD-DEV” in this case.

Search for “binaries” and select on the “ObtainBinaries” method without any parameters (it has https://www.spludlow.co.uk/Install/Downloads/Index.txt hardcoded into it).

Click “Make Call Text” then “Run Call Text”.

Check the Intranet Logs page for subject: “Release ObtainBinaries; Downloaded: 6” click on it and you can see the table telling you what was downloaded.

The binaries are downloaded to “C:\ProgramData\SpludlowV1\Release\Binaries”. From here they can be released to all hosts.

NOTE: This folder is only intended for downloaded Spludlow applications.

NOTE: This method checks the Applications.txt files on all the hosts.

Configure the “DevelopSources.txt” file on the Development machine

This file contains 2 columns; the key used to identify the application, and the path to where the application is be taken from.

As the file does not exist yet it can be automatically created. After this you can manually edit it to include additional applications.

Go to the Intranet Call page and change the host dropdown to the development machine “WSYS-HEAD-DEV” in this case.

Search for “binaries” and select on the “DevelopSourcesFromBinaries”. Click “Make Call Text” then “Run Call Text”.

Check the Intranet Logs for a subject of “MergeDevelopSources” this shows what it done.

You can now go a look at “C:\ProgramData\SpludlowV1\Config\DevelopSources.txt” and tidy it up with tabs.

NOTE: If you don’t have permission to save to this file you can save it to desktop then drag it over. A better way to solve this problem is add your user (“Admin” in this case) to the “SpludlowGroup” group and reboot.

NOTE: This method gets the list of applications from whatever is in “C:\ProgramData\SpludlowV1\Release\Binaries”.

Release the download binaries to all hosts

All hosts have an “Applications.txt” configuration file that declares what Spludlow managed applications are on the host. This is initially setup when the Framework is installed with the core Spludlow applications

Go to the Intranet Release page and click the “Reset” button. You should now have a matrix of what applications are available and where they can be sent to.

Click all the hostname headings to select all and click the “Send” button, a confirmation of what is being sent where is displayed.

NOTE: “Spludlow” on its own represents the Spludlow DLL only and is not required anywhere as it is included with all applications.

Check the logs and status page to check it has finished without any problems.

NOTE: The Intranet will briefly show “Service Unavailable” during the update as the Intranet is one of the applications being updated. You will also notice errors on the status page during the update as the web services on each host are stopped during updates.

When the status page shows everything is back up then the update is complete.

You can check the version of the Intranet on its home page.

Spludlow Framework - Registering your DLL and running code in a web service on remote hosts

This final step of getting started will build on the previous 2 steps of creating your DLL and configuring a develop source machine to get your DLL out to the hosts and run your code in a web service.

Building your DLL as a “Release”

When you build, compile your source into binaries (DLLs and EXEs), in Visual Studio there are 2 standard profiles: “Debug” and “Release” that are selected using the dropdown on the top tool bar. When building under “Debug” extra information is compiled into binaries to aid in debugging. When you build under “Release” your binaries are clean and run more efficiently because the “debug symbols” are not present. So when running in production (not in development) you want to use the “Release” profile.

Another important difference is that Visual Studio will put the binaries in different locations “projectDirectory\bin\Debug\WeiredSystems.DLL” vs “projectDirectory\bin\Release\WeiredSystems.DLL”. So it is important to build under “Release” before releasing as the Framework always looks in the release directory.

NOTE: If you are building and releasing and your changes don’t seem to be doing anything you have probably forgot to do a release build.

While still in “Debug” do a clean with “Build Menu->Clean Solution”, this will clear all the “bin\Debug” directories. I like to keep the debug directories clear unless currently debugging.

Change to “Release” and build the entire solution “Build Menu->Rebuild Solution”, check the Output window it should be succeeded.

You should now have the release binaries sitting in the “bin\Release” directories.

Register your DLL in “DevelopSources.txt”

We used “DevelopSources.txt” before to declare where the most recent downloaded Spludlow binaries where located. Now we will add a line to declare where your DLL is located so the release system can take it right from development to its target destinations.

Open “C:\ProgramData\SpludlowV1\Config\DevelopSources.txt” in notepad and add the line:

WeirdSystems D:\Develop\WeirdSystems\WeirdSystems

NOTE: The directory is to the top of the project directory and not the “bin\Release” directory.

Go to the Intranet Release page and click “Reset” we can now see a line for “WeirdSystems” but there are no checkbox as they have not been declared on the target hosts yet.

Register your DLL in “Applications.txt” on the 3 target hosts

On all 3 hosts (including the development machine) open “C:\ProgramData\SpludlowV1\Config\Applications.txt” in notepad and add the line:

WeirdSystems C:\Program Files\SpludlowV1\WeirdSystems Lib

NOTE: The host “WSYS-HEAD-APP” can be accessed through an admin share, the host “WSYS-BRAN-APP” is on a remote desktop so it is accessed using remote desktop.

NOTE: In a WORKGROUP (not Windows Domain) Administrator shares (\\host\c$) are disabled by default, to use them apply the “LocalAccountTokenFilterPolicy” registry hack.

Release your DLL to all 3 hosts

Go back to the Intranet Release page and click “Reset”, you should now see checkboxes in the “WeirdSystems” line.

Check all 3 and click “Release”. Check Logs and Status page until release has finished.

Running your code in the Intranet Call Page

Select the host you want it to run on in this case “WSYS-BRAN-APP” (the host on the remote network). Search for “hello” and select the “SayHello” method, the parameter textbox will appear enter “fred”. Change the address dropdown to “WSYS-BRAN-APP” (without anything after it) this means run in web service and receive the result back to the page. Click “Make Call Text” and “Run Call Text” the output will be shown at the bottom of the page.

Configuring the Test Form application to work with Spludlow

Any application that wants to use Spludlow needs 2 things; a reference to Spludlow.dll and a line adding to the .net configuration file.

In the solution explorer right click on TestForm’s references and click “Add Reference..”. This time use “Browse” and browse to “C:\ProgramData\SpludlowV1\Release\Binaries\Spludlow\Spludlow.dll”.

NOTE: If you update Spludlow.dll in the future using “ObtainBinaries” then Visual Studio will copy from the newer version.

NOTE: When referencing DLLs (that are not part of .net) the default behaviour when Visual Studio builds is to copy the DLL to the bin directory. Although this means you end up with the same DLL in multiple places it is the simplest way of doing it and I would always recommend doing it this way, the alternatives (GAC) are just too much hassle.

Double click to open “App.config” in the TestForm project. Add the following line just below “<configuration>”:

NOTE: In the video “Spludlow-Process.exe.config” is just used as a quick way of getting this line.

NOTE: You can still include your own appSettings as normal.

Test From is now ready to start using Spludow.

Using “Spludlow.Call.Now()” from Test Form to call your code as a web service

Within TestForm’s button1_Click method enter the following line:

result = (string) Spludlow.Call.Now("WSYS-BRAN-APP", "WeirdSystems", "WeirdSystems.HelloWorld", "SayHello", new object[] { "fred" });

Comment out the original locally referenced “SayHello()” call.

Run the Test Form and click the button, as you can see the code has been executed on the remote host, try changing the host.

Make a Web Service version of “SayHello()” in your DLL

Hopefully you can see how easy that was to run code remotely but obviously using “Spludlow.Call.Now()” in code is not very practical; the strings could easily contain spelling mistakes that the compiler won’t pick up, there is no type checking of the parameters, having to cast the result is scruffy, and it’s just a bit of mess. We can address this.

In the “WeiredSystems” project add a reference with browse to “C:\ProgramData\SpludlowV1\Release\Binaries\Spludlow\Spludlow.dll” just as we did above, so you can use Spludlow from your DLL.

NOTE: The DLL project does not need (or use) a .net configuration file, only the application that references it will have a .net configuration file.

In the “HelloWorld” class right above the existing “SayHello()” method add the following code:

public static string SayHelloWebService(string host, string name)

{

return (string)Spludlow.Call.Now(host, "WeirdSystems", "WeirdSystems.HelloWorld", "SayHello", new object[] { name });

}

Go back to TestForm’s button1_Click method and replace the existing code with the method you just created:

result = WeirdSystems.HelloWorld.SayHelloWebService("WSYS-BRAN-APP", "fred");

Run the Test Form and click the button. We have now created a much friendlier web service version of the “SayHello()” method.

Perform a Test on all 3 hosts

Replace the last line with:

foreach (string host in Spludlow.Config.Hosts())

{

result += WeirdSystems.HelloWorld.SayHelloWebService(host, "fred");

result += Environment.NewLine;

}

Run the Test Form, we just ran “SayHello()” on all the hosts.

Make a modification to “SayHello()” and release it to all hosts

Change the single line in the “SayHello()” method to put some bangs on the end of the result string:

return "Hello " + name + " from " + Environment.MachineName + " !!!";

Run the test again, notice the changes have not been made. This is because the 3 WeirdSystems DLLs have not been updated from the development version yet.

Rebuild the solution and go to the Intranet Release page click “Reset” and click the WeiredSystems link to select all 3 hosts, click the “Send” button and wait for the release to finish just as before.

Run the test again, notice the changes have now taken effect on all hosts.

Finial Thoughts on Getting Started

Hopefully you appreciate how simple it is to run your code remotely. Now everything is set up it should be simple to add more code to your DLL make web service versions or your methods and get them released out to the hosts where they will run.

We have only discussed “Spludlow.Call.Now()” that uses web services. There is another method “Spludlow.Call.Queue()”, that works in the same way as you saw here, used for running your code on message queues that will be discussed later. If you aren’t familiar with message queues believe me they are an essential part of robust distributed system.