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. See issue TOOLS-23541 - Getting issue details... STATUS for more information.

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.

Building and Testing Debug version of Framework

Usage

If you have changed the framework and want to test this with a product you can use the following steps to verify the change in the framework for your product:

1. You have changed something in the frame.sln solution and you have build the solution succesfully
2. Open the product (NGHS.sln) you want to test / debug your new framwork with
3. Restore all packages for this product
4. Close the solution
5. remove the generated bin folder for this solution
6. Open powershell
7. In Powershell go to the folder where you checked out the framework
8. In Powershell goto subfolder sdk (so: svn://trunk/Framework/sdk)
9. Run powershell script : ./copy-framework-bin-to-product.ps1 [PRODUCTNAME] [BUILDCONFIGURATION]
   1. This will copy the just build dlls from the frame work in the packages folder of the product
   2. Like: PS D:\svn\trunk\Framework\sdk> .\copy-framework-bin-to-product.ps1 NGHS Debug
   3. for more help on script use:  
      1. get-help .\copy-framework-bin-to-product.ps1
   4. for more examples: 
      1. get-help .\copy-framework-bin-to-product.ps1 -examples
   5. for more detail: 
      1. get-help .\copy-framework-bin-to-product.ps1 -detailed
10. Open the product solution file again with visual studio
11. Build your product with latest locally build framework

Design

Create a button in visual studio to run the dev script

1. In Visual studio goto Tools > External Tools ...
2. Press Add button
3. Fill in the following:
3a. Title: Update to Dev framework
3b. Command : D:\NGHS\trunk\Framework\sdk\copy-framework-bin-to-product.cmd
3c. Arguments : NGHS Debug
4d. Initial Directory : D:\NGHS\trunk\Framework\sdk\
4. Check "Use Output window"
5. Check "Prompt for arguments"
6. Move it completely up, so it is the first command
7. Ok / close the popup
8. In one of the toolbars of visual studio click on the 'show more buttons' button
9. Click on the Add/Remove button > Customize (customize popup appears)
10. Click on 'Add Command'
11. In Categories select 'Tools' In Commands select 'External Command 1'
12. Press Ok > Ok, you button will now appear in the tool bar

Troubleshooting

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

When you change something in the framework and you want to see if the supported products don't have any issues, you will have to manually update the supported products on your local machine. Then run a couple of tests or let TeamCity run the tests as a personal build. You don't want TeamCity to build your NuGet packages every time. It is way faster when you do it locally.

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.ApplicationPlugin -Source "local trunk" -FileConflictAction Overwrite 
Update-Package DeltaShell.TestProject -Source "local trunk" -FileConflictAction Overwrite 
Update-Package DeltaShell.Framework -Source "local trunk" -FileConflictAction Overwrite 

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.

• Please verify DeltaShell.FewsAdapter.csproj file if all libraries paths are updated to the new version
• In project DeltaShell.FewsAdapter set reference DelftTools.Shell.Core property Copy Local to True!

Checklist for developing the framework

As a summary, this is the checklist of what to do when developing the framework:

1. Make an edit to the framework
2. Build the framework via visual studio

3. Run script:

   create nuget package of framework in trunk folder

   folder:trunk/Framework/sdk/
   file:nuget pack commands.bat

4. Open NGHS and/or a couple of other products (Unibest, Habitat, etc..) SEE WARNING BELOW IF YOU GET ERRORS! (OR LOOK AT BEFORE YOU UPDATE THE FRAMEWORK)
5. Perform the Update-Package commands in the PackageManagerConsole
6. Run a personal build on the build server

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.

The automatic updates of product tests are still under construction. TOOLS-23763 - Getting issue details... STATUS . We hope to get this working soon with the latest 3.4 release of NuGet, so that it will be easier for framework developers to see if they forgot anything or if backwards compatibility is broken. Another workaround would be to make our own PowerShell script, but this would be very cumbersome, since it won't be stable at all.

Framework Release Management

There are no concrete agreements for releasing a framework (pinning it on TeamCity). There are a couple of things you could think of.

• First, pin the build on TeamCity.
  • At this moment, TeamCity is the only place where this NuGet feed lives. It could be the case that ICT is not aware of the importance of TeamCity. It could be possible that we need a better place to store the released framework versions. For example, in SVN.
• Then, update the version numbers in the csprojs of the framework for further development.
• Maybe we should make some release notes.
• Make an announcement about the release.
• You could update the supported products to the latest version of this released framework. Make sure that all the tests still succeed.
  
  

Building and Testing new Framework with all products in TeamCity

Description

For all our products we have pinned a framework version for it. We also have a specific test project (Updated Trunk tests) which checks the product with the latest checked in framework so not the pinned version! To do this we have setup some powershell script to dothis for us.

Design