Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Custom Plugins is a very popular feature within Connexion. In Connection v15 we have added some smarts to allow development teams to auto-generate Custom Plugins using standard build tools. This article describes the layout and requirements of the .nuget package file to be properly handled by Connexion.


There is plenty of information on the web that describes the .nuget package structure and how to use the .nuget package creation tools see:

Quickstart: Create and publish a package

.nuspec reference

so we will not cover those here.  Rather, we will look at the specifics of building a .nuget package that contains 1 or more Custom Plugins.

A nuget package is essentially a zip file with some meta information describing its contents. Connexion uses a very minimal set of the .nuget package capabilities. In fact, it only uses the metadata metadata section and Assembly Files. Connexion does not use any of the dependency information, framework version, or any of the other features .nuget provides as they are mostly not applicable to Connexion.


Sample .nuspec for Connexion
<?xml version="1.0"?>
<package  xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>    
    <id>Connexion.SampleDevice</id>
    <version>$version$</version>
    <authors>Nick, Jon</authors>
    <licenseUrl>http://hl7spy.ca/wp-content/uploads/2011/11/Eula.pdf</licenseUrl>
    <projectUrl>https://conevity.atlassian.net/wiki/spaces/CON/pages/14057474/Releases</projectUrl>
    <iconUrl>http://www.hl7spy.com/downloads/logo.png </iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>This is a sample of how to build a Connexion Device</description>
    <releaseNotes></releaseNotes>
    <copyright>Copyright 2019 Conevity Solutions Inc.</copyright>
    <tags>Connexion Device</tags>
    <summary></summary>
  </metadata>
  <files>
    <!-- Add assemblies from each Plugin separately at the end of the build-->
    <file src="..\..\SampleDevice1\bin\$Configuration$\*.dll" target="Assemblies\SampleDevice1" />
    <file src="..\..\SampleDevice2\bin\$Configuration$\*.dll" target="Assemblies\SampleDevice2" />
    <file src="..\..\SampleDevice3\bin\$Configuration$\*.dll" target="Assemblies\SampleDevice3" />
    <file src="..\..\SampleDevice4\bin\$Configuration$\*.dll" target="Assemblies\SampleDevice4" />
    <!-- Add large assemblies that should be associated with every Plugin-->
    <file src="..\..\library\*.dll" target="Assemblies\Shared" />
  </files>
</package>



I have attached a sample .nuspec that will create a nuget package with multiple devices. The pertinent section of the nuget package is the <files> section.

This demonstrates creating a structure within the nuget package that would place each plugin and all its dependent assemblies into its own folder. Here is why I think this would be a good approach.


  1. Supports packaging multiple plugins into a single package
  2. msbuild/nuget.exe can be used to generate the nuget package in a standard build process. For example, running the following command will generate the nuget package.
    nuget.exe pack Nuget\Connexion.SampleDevice.nuspec -nopackageanalysis -Version 1.0.0 -OutputDirectory Nuget
  3. Visual Studio has become very good at determining and pulling in the necessary dependencies for a project. Harvesting the files from the bin/Release directory will ensure that all device dependencies are include in the device package.


One downside is package bloat which could result if plugins within the .nuget package share a large number of large assemblies (like the Aspose.dll). One way of dealing with this would be to have a option in Connexion to "shrink" the .nuget package, by building a new nuget package that consolidates duplicate assemblies and adds a  Plugin Manifest that describes the plugin assembly dependency tree.  

  • No labels