Support .dnnX manifest files

[dazinator]

See Wiki for how this works: https://github.com/dazinator/DnnPackager/wiki/Manifest-Files

Developers can create an install package that can be installed into multiple different versions of DNN. The format of the manifest file has changed slightly from version to version though. To allow developers to keep a single install package but take advantage of all the features of the manifest allowed for the target DNN version, DNN allows you to include version specific manifest files in the package.

See here for more details: http://www.dnnsoftware.com/community-blog/cid/134615/the-dnn6-extension-manifest-file

This means DnnPackager should support allowing not only a manifest.dnn file, but also version specific manifest files.

[dazinator]

I am working on this in dev branch for next version

[dazinator]

You can now also add manifest.dnn[VersionNumber] in your project, and these will be included in the install zip.

For example you could have:

• manifest.dnn
• manifest.dnn5
• manifest.dnn7

You can also add build config specific ones that will be preferred by default if they are present for current build config. So given the following manifest files in your project:

• manifest.dnn
• manifest.debug.dnn
• manifest.release.dnn
• manifest.dnn5
• manifest.debug.dnn5
• manifest.dnn7
• manifest.release.dnn7

If you then build in release mode, the install package would include:

• manifest.release.dnn
• manifest.dnn5
• manifest.release.dnn7

I you instead build in debug mode it would include:

• manifest.debug.dnn
• manifest.debug.dnn5
• manifest.dnn7

[dazinator]

Documented on wiki page: https://github.com/dazinator/DnnPackager/wiki/Manifest-Files

[david-poindexter]

Does DNN have an awareness to build config specific versions of the manifest file? If so, I was completely unaware of this. Guess you learn something new everyday! ;-)

[dazinator]

DNN doesnt't really care about debug or release manifests when you install the zip. It only cares about the manifest for the current DNN version (if there is one) ending in .dnn[version], or if there isn't a manifest for the matching DNN version then it will just use the manifest ending in .dnn.

The debug / release (build configuration) version of the manifest is purely about allowing you to include a different version of the manifest in the install zip based on what build config you build it under. Suppose you want to include additional pdb files in the manifest when you do a debug build of your zip, but when you do a release build you want a manifest that doesn' list those files, and perhaps it references a different licence file or something. In that instance you could create a debug version and a release version of the your manifest, and the appropriate one will be included in the install zip when you do a build.

Its a little bit confusing, but it came in as a handy feature for me on a few occasions, and its purely optional as you'd only create these manifests if you need the feature for some reason! :-)

[david-poindexter]

Ah, that makes sense now and is a great idea. Thanks!

On Mon, Dec 14, 2015 at 6:16 PM -0800, "Darrell" <notifications@github.commailto:notifications@github.com> wrote:

DNN doesnt't really care about debug or release manifests when you install the zip. It only cares about the manifest for the current version (if there is one) ending in .dnn[version], or if there isn't a manifest for the matching dnn version then it will just use the manifest ending in .dnn.

The debug / release (build configuration) version of the manifest is purely a DnnPackager thing that about which manifest file actually ends up in the install zip based on the build configuration i.e debug / release. The reason its there is in case you want the manifest to install different files depending on the build configuration its built under. For example suppose you want to include additional pdb files in the manifest when you do a debug build of your zip, but when you do a release build you want a manifest that doesn' list those files, and perhaps it references a different licence file or something. In that instance you could create a debug version and a release version of the your manifest, and the appropriate one will be included in the install zip when you do a build.

Its a little bit confusing, but it came in as a handy feature for me on a few occasions, and its purely optional as you'd only create these manifests if you need the feature for some reason! :-)

Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-164621388.