1. New Project (.csproj)

Whenever you create a new project, make sure you edit the csproj file to include the following import:

TestProject.csproj
<?xml version="1.0" encoding="utf-8"?>
<Project ...  >
...
 <Import Project="..\..\..\..\build\DeltaShell.targets" /> <!-- ADD THIS -->
</Project>

This imported targets file takes care of several build steps (such as running PostSharp and copying dependencies).

2. Normal Projects: Dependencies (Auto-copy)

Test Projects: For test projects the external dependencies are not automatically copied from the corresponding lib directory! See section 3 below on how to explicitly force a dependency copy.

Visual Studio typically takes care of copying any managed references you have. For other dependencies several options are available, but the following is recommended (also for managed references).

  • Any dependencies you share with other projects should be placed in the lib folder directly (not a subfolder):

    .\DeltaShell\lib\

    Files here are automatically copied to the Loader bin directory on build.
  • Any dependencies your project has (whether managed DLLs, native DLLs, license files or other assets), that are not shared with other projects, should be placed in the corresponding lib directory of your project file.
    The corresponding lib directory can be found at the same path as your project, but with lib instead of src. Thus, for a given project TestPlugin:

    Example (TestPlugin):

    Project directory

    .\DeltaShell\ src \Plugins\TestPlugin\DeltaShell.Plugins.TestPlugin\

    Corresponding lib directory

    .\DeltaShell\ lib \Plugins\TestPlugin\DeltaShell.Plugins.TestPlugin\

    Any files in the corresponding lib directory will automatically be copied to your output directory (eg: .\bin\Debug) on build.

2.1 Plugins

Add the following entries to the project's csproj file to mark the project as part of a plugin (IsPluginComponent=true). The PluginName property is used to indicate which plugin this project is part of. For deployment, all output binaries and resources from the different projects belonging to the same plugin are copied to a single directory, based on this PluginName property.

TestProject.csproj
<?xml version="1.0" encoding="utf-8"?>
<Project ...  >
...
  <PropertyGroup>
    ...
    <IsPluginComponent>true</IsPluginComponent>
    <PluginName>TestPlugin</PluginName>
  </PropertyGroup>
</Project>

3. Test Projects: Dependencies (Custom)

You typically do not need to use this in a normal project (see section above on auto-copy)

In a test project (unmanaged) dependencies are not automatically copied to the output directory of your test project. Instead it is possible to manually define an external dependency folder in the test project's csproj file. In case you have a tree with external dependencies instead of a single file, you can use the double-asterisk wildcard (**) to account for those recursively, as shown for TestPluginB below. (In the DeltaShell.targets file, the attribute %(RecursiveDir) is then used to maintain the folder structure.)

TestProject.Tests.csproj
<?xml version="1.0" encoding="utf-8"?>
<Project ...  >
...
  <PropertyGroup>
    <ExternalDependencies>lib\Plugins\TestPlugin\DeltaShell.Plugins.TestPlugin</ExternalDependencies>
    <ExternalDependencies1>lib\Plugins\TestPlugin\DeltaShell.Plugins.TestPluginA</ExternalDependencies1>    
    <ExternalDependencies2>lib\Plugins\TestPlugin\DeltaShell.Plugins.TestPluginB\**</ExternalDependencies2>
    ...
  </PropertyGroup>
</Project>

Note: In general, the Platform Target in the project properties Build tab should be 'Any CPU'. However, if your test loads plugins that on their turn load native DLL's, you may get a System.BadImageFormatException when running the test. In that case, the Platform Target in your test project should be set to x86 (take care to do this for 'All Configurations').

  • No labels