Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You can also make a unit test project that works in Delta Shell. To do so, install the DeltaShell.TestProject package into your test project. Take notice of the Default Project in the Package Manager Console, because you want the DeltaShell.TestProject to be in your test project and not in your application plugin project.

The test project also adds some extra lines to App.config.These lines make sure that your unit test can find the framework and the plugins.

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

Auto-Restore Packages

You don't have to add the packages folder to svn, because TeamCity and Visual Studio already know how to handle and download the packages.

...

Why, you ask? Because they already have their own output folder and you don't want these dlls to be doubled in your bin directory.

 

Image Added

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.

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.

 

 

Now you may press the compile button. Have a look in your bin folder next to your solution folder. You will see that there are two folders. One is for the framework, the other contains all the plugins.

...

Just builds the solution and returns a zip as artifact that can be downloaded. Actually uses a .proj file to run MSBuild. You will have to add a .proj file next to your solution in order to make this work.TODO: Elaborate

The template performs the task BuildRelease on the . proj file and therefore can do something like the following example. It shows that it first builds the solution as visual studio would. Then it removes the pdb and pssym files, so that the zip file artifact will be as small as possible for users to download.

Code Block
languagexml
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <BuildPath>$(MSBuildProjectDirectory)</BuildPath>
    <SolutionDir>$(MSBuildProjectDirectory)\</SolutionDir> 
  </PropertyGroup>

  <Target Name="BuildRelease">
    <MSBuild Projects="Unibest.sln" Targets="Build" Properties="Configuration=Release;SolutionDir=$(SolutionDir);" />
    
    <ItemGroup>
      <PdbFiles Include="$(BuildPath)\bin\**\*.pdb"/>
      <PsSymFiles Include="$(BuildPath)\bin\**\*.pssym"/>
    </ItemGroup>
    <Delete Files="@(PdbFiles)" />
    <Delete Files="@(PsSymFiles)" />
  </Target>

</Project>

 

Build MSI via MSBuild

This template actually requires one more thing at the moment. The product must be in the svn of the trunk in order to find it. The split of the setup has not yet been done completely and is still under construction. How to set up your installer is not discussed in this document, but can be found in the examples in the delta shell trunk.

Once we have changed the wix installers so they can be stand-alone and used by all products via a nuget package, we will edit this document right away.TODO: Elaborate on making wix