First things first. There is no overall DeltaShell solution file anymore that contains both framework and products. That means that a framework developer cannot easily check which classes are actually used by the products. This is a flaw in our work process and should be fixed as soon as possible.

For now, we can develop the framework via Framework.sln and make sure to not change the API of the framework as much. Although, when we decide that something should go, there is nothing to stop you, since the product using that functionality has pinned its version of the framework and can work along just fine.

NuGet Specifications

The NuGet specifications can be found in svn under trunk/Framework/sdk. I'm not going into detail at the moment on how these specifications work. There is enough reference material on the interwebz. There are two folders in the sdk folder. packages and tools. The tools folder contains some utility functions that can be useful during the install.ps1 script that is run when the NuGet package is installed into the csproj.

Building and Testing NuGet Manually

You can create an example NuGet package that the build server would normally make via trunk/Framework/sdk/nuget pack commands.bat. It will generate your packages that you can then install in one of the products for testing purposes.

To install a package that is not on the TeamCity feed in a product, you will need to add a local NuGet feed to visual studio and then update the package. Go to the Package Manager Settings and go to package sources. Add a new package source that points to your svn checkout.

After doing so, you can simply update the already installed packages with the following commands:

Update-Package DeltaShell.Framework -Source "local trunk"
Update-Package DeltaShell.ApplicationPlugin -Source "local trunk"
Update-Package DeltaShell.TestProject -Source "local trunk"

This ensures that the packages are uninstalled and re-installed in all projects. After that has been done, you can perform local unit tests to see if your new NuGet package is a success or not.

TeamCity

TeamCity helps us with a couple of things. It performs automatic unit tests of the framework tests themselves and it also performs automatic unit tests for the product tests when you made changes to the framework. These product tests are triggered when a new successful NuGet package was built. It is then updated onto the product and the tests are run.