Content Comparison

Custom Plugins is a very popular feature within Connexion. In Connection v15 we have added support for auto-generating Custom Plugin .nuget packages using standard build tools. With this you will be able to:

1. Package multiple plugins into a single .nuget package
2. Use 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 shown below.
   nuget.exe pack Nuget\Connexion.SampleDevice.nuspec -nopackageanalysis -Version 1.0.0 -OutputDirectory NugetUse Visual Studio to automatically determine the necessary dependencies for a Plugin. Harvesting the files from the bin/Release directory will ensure that all device dependencies are include in the device package.
3. Place larger shared assemblies into a well-know location so that overall size of the .nuget package to be distributed is reduced.

There is plenty of information on the web that describes the .nuget package structure and how to use the .nuget package creation tools so we will not cover those here. Please see:

What is Nuget?

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 that can be imported into Connexion.

A nuget package is a zip file container with some meta information describing the contents of the file. The full description of nuget can be found here. containing files and folders as well as additional meta data describing the package. Connexion uses a very minimal set of the .nuget package capabilities. In fact, it only uses the metadata section and Assembly Files section. 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 a Connexion Plugin management.

An example nuget package spec (.nuspec) for a set of Custom Plugins is shown abovebelow. It contains 2 sections: the "<metadata>" section which provides general version and descriptive information for the package; and the "<files>" section which contains directions to the nuget packaging tool where to place the assembly files during the build process.

...

<?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="..\..\Plugin1\bin\$Configuration$\*.dll" target="Assemblies\Plugin1" exclude="**\Connexion.*.dll;**\Newtonsoft.Json.dll"/>
    <file src="..\..\Plugin2\bin\$Configuration$\*.dll" target="Assemblies\Plugin2" exclude="**\Connexion.*.dll;**\Newtonsoft.Json.dll"/>
    <file src="..\..\Plugin3\bin\$Configuration$\*.dll" target="Assemblies\Plugin3" exclude="**\Connexion.*.dll;**\Newtonsoft.Json.dll"/>
    <file src="..\..\Plugin4\bin\$Configuration$\*.dll" target="Assemblies\Plugin4" exclude="**\Connexion.*.dll;**\Newtonsoft.Json.dll"/>
    <!-- Add large assemblies that should be associated with every Plugin-->
    <file src="..\..\library\*.dll" target="Assemblies\Shared" />
  </files>
</package>

An example nuget package generated from the above nuspec would have the structure below.

Here are some basic rules about the package structure for Connexion Plugins:

1. Each plugin should have its own folder (eg. Plugin1, Plugin2, etc) under the "Assemblies" folder
2. Each plugin should include all its dependent dlls (with the exception of dlls placed within the Shared folder) that are required by the plugin at run-time.
3. Any large assemblies, required by ALL Plugins can optionally be placed in the Assemblies/Shared folder to save space.
4. Assembly files that your plugin does not require should be excluded. In particular you do not need to include any Connexion assemblies. In the example above the .nuget package is explicitly excluding any Connexion assemblies as well as the Newtonsoft.Json.dll since the latest version is included with Connexion.

ConnexionSample.nuget
|   ConnexionSample.nuspec
|   [Content_Types].xml
|   
+---Assemblies
|   +---Plugin1
|   |       Hl7.Fhir.STU3.Specification.dll
|   |       Hl7.Fhir.Support.dll
|   |       Hl7.FhirPath.dll
|   |       MModal.AdtHl7FhirProcessor.dll
|   |       System.ValueTuple.dll
|   |       
|   +---Plugin2
|   |       Connexion.Edifact.Hipaa.dll
|   |       EdiFabric.Core.dll
|   |       EdiFabric.Framework.dll
|   |       Hl7.Fhir.STU3.Specification.dll
|   |       Hl7.Fhir.Support.dll
|   |       Hl7.FhirPath.dll
|   |       MModal.837ClaimsFhirProcessor.dll
|   |       System.ValueTuple.dll
|   |       
|   +---Plugin3
|   |       Hl7.Fhir.STU3.Specification.dll
|   |       Hl7.Fhir.Support.dll
|   |       Hl7.FhirPath.dll
|   |       MModal.FhirSender.dll
|   |       System.ValueTuple.dll
|   |       
|   +---Plugin4
|   |       Hl7.Fhir.Support.dll
|   |       Hl7.FhirPath.dll
|   |       MModal.SiuHl7FhirProcessor.dll
|   |       System.ValueTuple.dll
|   |       
|   \---Shared
|           ConnexionDevicesCommon.dll
|           Hl7.Fhir.STU3.Core.dll
|           
+---package
|   \---services
|       \---metadata
|           \---core-properties
|                   b61692f050fd4dc5be95bc1fed53df7b.psmdcp
|                   
\---_rels
        .rels