-
Notifications
You must be signed in to change notification settings - Fork 3
What does the DnnPackager NuGet package do
Update: For an introduction to DnnPackager - read my blog post
When the DnnPackager NuGet package is installed, it adds the following files to your project:
- manifest.dnn
- licence.txt
- relasesnotes.txt
- DnnPackageBuilderOverrides.props
It also add's a custom msbuild .targets file to your project, containing the necessary build logic to do the wonderful things that it does.
Lastly, it also extends the package manager console in VS, with additional commands that you can use to help streamline your development workflow.
From now on, when you build your project, it will be packaged up into a DotNetNuke Installation Zip. Check your projects output directory for that installation zip file.
1. Update the "manifest.dnn" file in your project appropriately.
You can deploy your module to a local DotNetNuke website (hosted on your local IIS) very easily.
1. In VS, Open up the "Package Manager Console" window, and select your project from the projects dropdown.
2. Type: `Install-Module [name of your website]` and hit enter.
3. Watch as your module project is built, packaged up as a zip, and then the zip is deployed to your local Dnn website!
For example, if your Dnn website is named "Dnn7" in IIS, then you would run:
Install-Module Dnn7
Note: This will build and install the module for your active build configuration. You can override this by using:
Install-Module [name of your website] [Build Configuration Name]
e.g if your current active build configuration was debug, but you wanted to install the release build of your module, you could type:
Install-Module Dnn7 Release
For debugging, you can automatically attach the debugger! Run:
Install-Module [name of your website] [Build Configuration Name] Attach
e.g:
Install-Module Dnn7 Debug Attach
That will install your module, and then attach the debugger for you.
Note: To save time in future, you can hit "up" arrow key in Package Console Manager to get the last command you executed to save you having to type if every time. So typically you can just hit "up" and then hit enter key, and you will be debugging your module in no time.
A file named "DnnPackageBuilderOverrides.props" was added to your project. This file allows you to override the default packaging logic for your project. For example, you could include additional files in your zip file etc. Please take a look at the contents of "DnnPackageBuilderOverrides.props" - it has commented out sections that demonstrate properties that you can override if you want to. It shows how to include additional files, dll's etc etc.
When doing a Debug build, wouldn't it be handy if the Dnn zip installation package (and manifest file) included pdb's? When doing a release build however, wouldn't it be handy if the zip installation package (and manifest file) didn't have those pdb's included? DnnPackager supports this scenario, by allowing you to have multiple manifest files in your project, one per build configuration. If one is found for the current build configuration then it will be used. For example, if you have a manifest.debug.dnn in your project, then when doing debug builds, this manifest will be included in the zip file. This means you can have a seperate manifest.debug.dnn and a manifest.release.dnn, and include things like pdb's in the debug version, but not in the release version of the install package.
Warning this feature is being deprecated as of version 1.1 which is currently in pre-release. I may bring it back in a future releases, but it will most likely be implemented differently in that instance.
Each project in your solution that you add DnnPackager too, will have an installation zip file produced when you build the project.
By default those will appear in the standard output directory for the project - i.e bin\release etc.
However sometimes it's useful to be able to grab all the installation zip packages together.
DnnPackager automatically creates a folder on disk, named "InstallPackages", alongside your .sln file.
(You can change this if invoking MSBuild.exe, by passing in the msbuild property: /p:SolutionBuildPackagesFolder "yourfolderpath") and the installation zip files will be additionally copied to that directory.
When MSBuild is invoked, the "InstallPackages" folder is cleared right at the beginning of the build, so that only modules that are built appear in that folder, and not the results from previous builds.
Warning this feature is being deprecated as of version 1.1 which is currently in pre-release. I may bring it back in a future releases, but it will most likely be implemented differently in that instance.
DnnPackager supports OctoPack: https://github.com/OctopusDeploy/OctoPack
If you add OctoPack (available on NuGet) to your project, then you will find that the NuGet deployment packages that OctoPack produces:-
- Will contain your module's installation zip file.
- Will have NuGet package metadata (Id, version number, etc) derived form your Dnn manifest file.
This allows you to maintain the version information in one place - the dnn manifest file (and have OctoPack package up your module installation zips in a nice NuGet deployment packages, ready for automated deployments via Octopus Deploy: http://octopusdeploy.com/)
DnnPackager supports creating individual NuGet deployment packages per module / project, as well as creating a single NuGet Deployment package, containing all the module installation zips in your Solution.
The msbuild properties to enable / disable project level, and solution level nuget packaging are:
/p:CreateDeploymentNugetPackages=true - when true, and when OctoPack is present, each module will have a NuGet deployment package containing it's zip.
/p:CreateSolutionDeploymentPackage=true - when true, and when OctoPack is present, a single NuGet deployment package will be produced, containing all the module installation zip's in the solution.
You can then control which NuGet feeds those NuGet deployment packages get published to, by setting the following msbuild properties:
p:OctoPackPublishPackageToHttp = "http://somefeed.com/api" - individual module NuGet deployment packages are pushed to this feed.
/p:OctoPackPublishApiKey = "some nuget api key" - This is the API key for that feed.
You can also control which NuGet feed the solution level nuget deployment package is pushed to, by setting the following msbuild properties:
/p:PushSolutionPackageTo = "http://someotherfeed.com/api"
/p:PushSolutionPackagesApiKey = "some nuget api key" - This is the API key for that feed.
NuGet.exe is used in the process of packaging and pushing packages. By default, the path to Nuget.Exe is resolved to your NuGet packages directory, but if for some reason you store NuGet.exe somewhere different, you can tell DnnPackager where NuGet.exe is, by setting the following msbuild property:
p:NuGetExeFilePath="C:/NuGet.exe"
DotNetNuke does not support SemVer for it's extension version numbers, However, if you would like to use a Build Number for the 3rd digit (patch version) of your Dnn Extensions, then you can pass in the build number by setting the following msbuild property:
p:BuildVersionNumber="12345"
Any resultant module installation zips (and NuGet deployment packages), will then have the version number: Major.Minor.12345 - where Major and Minor are what you have specified in the module's manifest file, and 12345 was the value passed in for the BuildVersionNumber msbuild property.
I hope this helps you. If you do have any feedback, raise an issue and we'll discuss.
Darrell Tunnell (Dazinator) http://darrelltunnell.net/