Deprecated

This document is deprecated since the transfer to NuGet packages. Projects are not in DeltaShell.sln anymore, but are separated per product. You can find up-to-date information in HOW TO: Creating Delta Shell Products and Projects with NuGet.

Most of the actions that were required before NuGet was used had to be done manually, but these actions have been put in DeltaShell.ApplicationPlugin.

 

There is a new sheriff in town and this document shows you the new laws of project management.

Don't

  • Add DeltaShell.targets to your project via <Import>. It is removed.
  • Add <ExternalDependenciesX> to your project. It is removed.
  • Trust on automatic build magic that copies a lib folder to your output.
  • Look into yourproject/bin. It is removed.

Adding a new source project

In order to create a new project. Just add a new csproj in the way you would normally do. Add it on the correct location. For example: Right click... on Products/NGHS/src and select New Project. Than you would probably select Class Library as type. Set the location to where you want the project to be in the svn source tree (Products/NGHS/src). A simple project has been created.

Now, open the csproj file in a text editor. We are going to change some settings that are not supported in Visual Studio. Once you have changed the output path, you are in full control of what should go to the output. Always confirm that what is in your output path, are the files you actually need. There should be no extra dll's in the output folder that your csproj doesn't own.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <OutputPath>$(SolutionDir)bin\Debug\plugins\$(AssemblyName)</OutputPath> <!-- Change the outputpath! -->
  ...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  ...
  <OutputPath>$(SolutionDir)bin\Release\plugins\$(AssemblyName)</OutputPath> <!-- Change the outputpath! -->
  ...
</PropertyGroup>

Next, add your project to the Project Dependencies of DeltaShell.Gui.

 

Don't edit the outputpath via Visual Studio

Changing the OutputPath in visual studio will break the $(SolutionDir) and change it into a relative path when you save it.

 

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <OutputPath>$(SolutionDir)bin\Debug\plugins\$(AssemblyName)</OutputPath>
  ...
</PropertyGroup>

 

 

Adding Project References

You can add project references to parts of DeltaShell or other plugins as normal. But, to make sure that your project doesn't copy over the project dlls to the output directory, you should set the property of the reference to Copy Local = False. This makes sure that there will be no duplicate dlls in the final result.

Adding Dll References

Sometimes, you just need a reference to an external library that is already compiled. You can add those too. But remember that adding a reference comes with the responsibility of copying it or not.

Adding Native Libraries or Other Content

If you require other files, like native libraries that are not referenced, to go to your output folder; add them as content to the project. The folder structure that is used in the project is mirrored to the output folder. For example, if you have a folder called myNatives in your csproj, there will be a folder called myNatives next to the final dll. Set the content that you want to add to Copy if newer, so that it will be copied to the output folder.

Adding New Test Projects

Test projects require a similar approach as source projects, but have a different output path and some extra rules attached. First, change the output path of the test project. It is directly in the bin folder and this is on purpose, as you will discover later.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <OutputPath>$(SolutionDir)bin\Debug</OutputPath> <!-- Change the outputpath! -->
  ...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <OutputPath>$(SolutionDir)bin\Release</OutputPath> <!-- Change the outputpath! -->
  ...
</PropertyGroup>

Set all references to Copy Local = False. Because the dlls are already on their place.

In order to find the dlls, add an App.config file to the project. This file shows your test project where to look for the dlls of DeltaShell and the plugins, because dll search normally only searches in the direct folder of the test project. Now, it will also search in these subfolders.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="DeltaShell;plugins;"/>
    </assemblyBinding>
  </runtime>
</configuration>

And add a Project Dependency to DeltaShell.Gui

 

It could be that your test still cannot find some of the native dlls. This is an inefficiency in the current design and we hope to fix that once. If you are missing dlls like: RainfallRunoffModelEngine.dll, try adding extra privatePaths.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="DeltaShell;plugins;plugins\DeltaShell.Plugins.DelftModels.RainfallRunoff;"/>
    </assemblyBinding>
  </runtime>
</configuration>

Adding Test Data

Since the tests are built directly into the bin folder, there is no knowledge on where to find the test data anymore. We resolved this by adding a symbolic link for each test-data folder. You can do this as well for your project by adding the following command to the post-build event.

cmd /c $(SolutionDir)build\mklink-test-data.cmd $(TargetDir) $(TargetName) $(ProjectDir)test-data

The final argument $(ProjectDir)test-data tells the cmd-file to look for a folder in the project directory called "test-data". So, add a folder in windows explorer in the project folder and call it test-data. This folder will then be referenced by a symbolic link and can be found via $(SolutionDir)bin\Debug\test-data\TestApplicationTests.

test-data folder inputtest-data folder in output

Use DelftTools.TestUtils.TestHelper to get your test-data files.

  • See TestHelper.GetTestFilePath(string) to find files in your own test-data.
  • See TestHelper.GetDataDir() to get the test-data folder itself.
  • See TestHelper.GetTestDataPath() to get the test-data folder of another project.

 

 

 

  • No labels