dazinator / dnnpackager

Automate the packaging logic for your DotNetNuke projects, deploy to your IIS from within Visual Studio.

DnnPackager

Build	NuGet Release	GitHub Release

Available as a NuGet package here: https://www.nuget.org/packages/DnnPackager/

To get started, follow this: http://darrelltunnell.net/blog/2015/12/01/dnnpackager-getting-started/

For more information about what this does, features etc, read this: https://github.com/dazinator/DnnPackager/wiki/What-does-the-DnnPackager-NuGet-package-do

Why?

Many people use visual studio DotNetNuke project templates for their Dnn development. I have a number of issues with project templates - which I describe: https://github.com/dazinator/DnnPackager/wiki/Why-not-use-a-DotNetNuke-Project-Template!%3F

I have tried to eliminate the need for project templates, and instead take advantage of NuGet and the Package Manager Console to streamline Dnn development. This is the same principal that Entity Framework Code First uses.

dnnpackager's Issues

Automatically include assemblies with CopyLocal = true in package

At the moment, DnnPackager will include your target assembly, but for example if you need to include additional assemblies, then you need to modify some msbuild properties to tell DnnPackager about the additional assemblies to include.

It would be better if DnnPackager could automatically include all assemblies in the your project references, that are set to "Copy Local = true".

I haven't found any decent msbuild documentation for getting a list of these assemblies but this looked interesting: http://blog.alexyakunin.com/2009/09/making-msbuild-visual-studio-to.html

Auto spin up local Dnn instance, with module on page, and debugger attached - to streamline local debugging!

At the moment, there is a small bit of additional effort that a developer must go through in order to have a working dev environment. There is also a small bit of effort that a developer must go through before they can test / debug each module for the first time.

Per Dev Environment:

• The developer has to install a DNN website locally first.

Per Module being developed:

• Must configure a page on the DotNetNuke website to display their module. This is the page you would browse too and typically "refresh" when testing module changes.
• Must attach VS to the websites process each time you want to debug the module.

How this feature will work

When a developer is ready to run / debug a module they will run a command in the package manager console window:

Run-Module -Config "Debug" -Website "MyWebsite" -DnnVersion "7.4.1" -PageName "TestPage"

This command is fairly lengthy, so the developer would probably just hit "up" on the keyboard and then "enter" to re-rerun it within the package manager console whenever required.

The result would be, they would be presented with a browser window displaying their module on a page, and with the VS debugger attached. This would be the equivalent in a Website project to clicking the "play" button in vs.

To explain this command:

1. First it will Build your module according to the build configuration specified by the -Config argument - in this case Debug mode - this will produce the installation zips.
2. It will then check to see if a website exists on your local IIS, with the name provided by the -Website argument - in this case MyWebsite.
   • If the website does exist:
     -. It will compare the DotNetNuke version of that website to the to the -DnnVersion argument - in this case 7.4.1 to make sure it matches. If it doesn't match - an exception will be raised explaining the problem - i.e it's the wrong version of DotNetNuke.
   • If the website doesn't exist:
     -. The install package for the specified version of DotNetNuke will be automatically downloaded and the website created automatically. This saves the developer having to set up a local DNN website manually.
3. It will then Install the module's zip/s into the DotNetNuke website using the standard DNN extension install procedure. If there is a problem with the module's installation package then this step will fail with an appropriate exception message at this point. Typical issues might be for example that the developer hasn't given their module / extension a name or title in the manifest file.
4. It will then check to make sure that a page is created in the DotNetNuke website with a name matching the -PageName argument - in this case TestPage.
   • If it doesn't exist, it will be created.
5. It will then check to make sure that the module in question has been placed on the page (page configuration)
   • If it hasn't, the page configuration will be amended to display the module.
6. It will then:
   • Launch the specified page in a separate process in the default browser.
   • Attach Visual Studio to the process ready to debug.

Speed

First time - vanilla environment.

The first time this command is run on a vanilla environment it will be slower due to having to perform those one time costs that a developer would previously of had to do manually:

1. Download and Install a DNN website
2. Configure a test page, add the module to it.

Subsequent runs

Subsequent times this command is run though, it should be speedier:

1. It sees the website allready exists (quick) and that it's the correct DNN version (sql operation is quick)
2. Sees that a test page exists and has the module on (should be pretty speedy operations due to indexes on the tables queried)

Every run

Things that occur every time the command is run, and may vary considerably in time:

1. It will install the module into the Dnn website. The time this takes will vary depending on the size of the module and the specs of the developers machine.
2. It will launch a browser to display the test page. Dnn website may take varying amounts of time to spin up and display the page, guessing specs of developers machine makes a big difference.
3. It will Attach VS debugger to the w3w process. The time this takes may vary based upon the developers debugging settings, especially around symbol resolution / symbol servers etc.

VS2015 and DnnPackager

Darrell, We have upgraded to VS2015 and are starting a new DNN Module package. I want to use your DNNPackager because I subscribe to the same thought process you do. But VS2015 projects are so different. I added the DNNPackager nuget package, but I dont see the added files you reference on your gitgub page. Does it not work with VS2015 yet?

Also what is the best way to contribute to your project? Do you have any Dev guidelines?

Support for installing a sources package via package manager console

Now that both a sources and ordinary install zip are being produced, when you do an Install-Module from package manager console in VS - it needs to know which version of the package to install.

I'll make it so that by default it will install the non sources version of the package as before. If you need to install the sources version, because you use dynamic compilation etc, then you can call Install-ModuleSources which works in exactly the same way as Install-Module and has the same arguments (for attaching etc) its just it will select the sources package as the one to deploy.

Solution Nuget Package version number - allow it to be set explicitly

At the moment, BuildVersionNumber is used for the last digit of both:

1. The individual module nuget packages (if you are producing those)
2. The solution level nuget package version number (if you are producing that)

However for 1) - its assumed to be a integer and is appended as a 4th segment, to the existing 3 segment version in the module manifest - to produce a valid 4 segment nuget package version number.

But for 2) it's just used as is, in which case a single digit number isn;t a valid NuGet package version - so attempting to produce a solution nuget package won;t work unless you pass in a BuildVersionNumber like 1.0.1 or something valid.

Rather than using the 'BuildVersionNumber' for both those scenarios, I'm going to change it so that the BuildVersionNumber is only used for 1)

I will introduce a seperate msbuild property that must be set in order to control the solution level nuget deployment pacakge version number.

Run the following to replicate the problem - i.e 12345 isn't valid for the NuGet solution package version number

msbuild "G:\Test.sln" /p:CreateSolutionDeploymentPackage=true /p:NuGetExeFilePath="packages\NuGet.CommandLine.2.8.2\tools\NuGet.exe" /p:BuildVersionNumber=12345

Attribute based manifest system

as discussed in #58

We should add a new feature to DnnPackager to allow an attribute based Manifest system.

Following is current suggestion of the fundamentals for how this can work:

1. Install DnnPackager to your project as usual. Everything remains the same as before.
2. To start using the attribute system, In the Package Manager Console type Install-Attributes
   • This will add the source code files for the packaging attributes to your project so that they get compiled within your own assembly which eliminates the need to distribute a third party assembly / dependency with your module.
3. You can now prefix your classes with the appropriate attributes (yet to be defined)
4. During build, DnnPackager will reflect through the classes in the output assembly, discovering the attributes (by attribute typename) - and it will then suppliment the existing manifest file with that information.

The information from attributes will suppliment the existing manifest file, not replace it completely.

For example, if you have an existing manifest with a package xml element in, and then you use the attributes system to declare another package - this result in a manifest.xml file with both packages in.

UPDATE: Another possiblity, rather than adding the attribute source code to the project, is to use a Fody Weaver, like JetBrains does for resharper: https://github.com/Fody/JetBrainsAnnotations

Support Xdt config transforms on manifest file

Build config specific versions of the manifest file is a cool idea (debug / release / client) but it means you have to maintain duplicate versions of the file.

What would be more awesome, is to make it work like web.config files, where the build specific ones just use xdt (transformations) to transform the original file. This should be relatively easy to do because there are open source libraries available for running these transformations. Good info on those here: http://gigi.nullneuron.net/gigilabs/transforming-config-files-and-xml-documents/

Remove weird BuildVersionNumber formatting

When passing in the msbuild property /p:BuildVersionNumber - this number is appended to the version number in your module's manifest file, to produce the version Number for the NuGet package that is produced for your module.

The idea is, that you can pass in an incrementing number, from a build server for example, and the NuGet deployment packages that are produced will automatically have an incremented version number, even if a developer has forgotten to update the version in the module's manifest file. This ensures each build generates uniquely identifiable deployment packages that can be traced back to said build.

However, there is some logic currently that treats this property as a cruise control build number i.e 1.0.12345.A
and reformats it to extract the 5 digit changeset number - i.e the 12345.

This is all specific to Cruise Control and needs to be removed.

Remove this formatting logic, and honour the build number passed in.

This does mean that people will have to pass in a number that is valid when appended to the version number in their modules manifest, for a NuGet package version number.

Dnn version numbers are max 3 digit, so the typical scenario would be to use 3 digit version numbers on the dnn manifest file, and then an integer value for the build number - which would produce a 4 digit numbered NuGet package, where the last digit is the build number.

Consider a companion module with a web api, listing available packges.

The tab on extensions page in dnn that shows modules on the dnnstore is nice, but it only works with the public store.

What about small teams that develop highly bespoke, internal modules. They typically do not and should not be published to the dnn store. The usual route is that the team manually installs the module on dev, uat, production system as required. To enable a smoother workflow for this could:

1. Create a companion module for dnnpackager that has a webapi and can be installed into a dnn site.
2. Add a publish command to dnnpackager so a developer from within VS (or the CI build server) can publish the install zip to the companion Dnn module.

The companion module then should behave like the available extensions tab, showing the newly available zip with an install option.

Could start to add some interesting features around this companion module.. like the ability to "promote" a module from one dnn instance to the next (i.e dev --> test --> live)

Big project though, will leave this as one to think about after the dnn project system is out the door.

Auto Attach Debugger

Having to do the ctrl + alt + p milarky to attach to the correct workerprocess to debug is time consuming.

I am going to extend the Install-Module command with an additonal Attach argument that will automatically attach your vs instance to the website worker process after the modules are successfully deployed.

So to use this feature, in the package manager console, you'd type something like:

Install-Module "MyDnnWebsite" Debug Attach

Installation issue with project templates using NuGet wizard

When creating a VS project system or a VS project template, you can use the NuGet wizard with your project template to "pre-install" NuGet packages with your project when its created in VS via "Add New Project" dialog.

When this is done to "pre-install" DnnPackager NuGet package with a new project there is a strange error.

Theinstall.ps1 script inside the NuGet package is executed, and uses this technique to access the msbuild project, so that it can then import the additional targets to the project, however the current project is not in the LoadedProjects collection in this scenario. Therefore the install script errors.

I can only assume that NuGet is executing the install.ps1 script before the project has been fully loaded - which might make sense as its in the process of being created still perhaps.

The solution would be to amend the install.ps1 script, so that if the project is not yet in the loaded projects collection, it listens for the "ProjectAdded" event (on the ProjectCollection object) signalling that the project has finished loading, and then installs the targets!

Multiple Modules in One Solution

I've been working on creating a single solution that contains all the modules that I frequently update.
It makes it a lot simpler for me rather than having multiple instances of VS running.

What would I need to modify in the powershell scripts so that DNNPackager looks at the Module Projects rather than the entire Solution?

Install-Module fails due to new security measures implementated

@dazinator we now have an issue related to the new security measures implemented in DNN. See Critical Security Update. Starting with DNN 08.00.03, ~/Install/Install.aspx no longer exists. That said, there is obviously still a mechanism by which to install modules because the "Available Modules" still works via Host > Extensions. Perhaps some additional research is in order.

Create a VS project system / flavour

Create a Vs extennsion that adds a new project system to VS for creating DotNetNuke Extensions. This means it will show as a Project Type on the VS new project page.

This is not a project template, this will be a fully blown project system / flavour.

The benefit of creating a project system over a simple project template is that I can integrate with VS to handle 'Run' and 'Debug' commands from the vs environment.

This will mean a developer will be able to run their vs extension project by clicking the usual play button in Vs and watch as the dnm extension is packaged up and deployed to a dnn host website and the debugger then attaches.

This new project system will still include a dependency on the DnnPackager nuget package which will contain all the custom build and deployment logic used by the project during builds to package up the dnn extension zip correctly etc. This has the benefit that I can still roll out improvements to these build tasks via releasing a newer nuget package, and people need not create new projects to get the latest build / deployment improvements, just update using nuget.

Links to resources for developing vs project systems to follow

Think about a "watch" mode for dealing with content

This might be an alternative approach for the problem of updating client side files to #38

Similar to gulp-watch, think about whether some sort of watch mode that will make DnnPackager "listen" for changes to client side files (js, css etc) in a project (new files, modifications, deletions) and automatically deploy an incremental package update containing the change to the dnn site.

For example, if the developer installs a package:

1. Install-Module [SiteName]

And then they want to "sync" changes to content files, they would do something like

1. Watch-ModuleContent [SiteName]

This would start DnnPackager "watching for file changes in the project.

1. Developer would change somefile.css

DnnPackager would detect the change as it's watching.

I then need to think about the best way to deliver that change to the DnnWebsite. The two approaches would be, either by some way of installing incremental zip packages, or, bypassing Dnn completely and doing file modifications directly in particular dnn folders.

Could I deliver incremental updates purely using zip install packages? If I install a newer version of the install zip package without the assembly dll, does Dnn then delete the original assembly / dll that was installed from the older version of the package (i.e as it works out is no longer part of the module definition?)

This idea needs some more thought and research.

SolutionBuildPackagesFolder is never removed

The CleanPackages target in before.JE.D2D.Modules.sln.targets doesn't appear to be called at all.

Handle when there is no push nuget feed url specified for pushing the solution nuget package.

If you specify /p:CreateSolutionDeploymentPackage but don't also specify the url to push that package to, the build fails - as it goes on to try and push to a blank url.

To replicate:

msbuild "G:\test\test.sln" /p:CreateSolutionDeploymentPackage=true /p:
NuGetExeFilePath="packages\NuGet.CommandLine.2.8.2\tools\NuGet.exe" /p:BuildVers
ionNumber=12345

The error:

Build FAILED.

"G:\test\test.sln" (default target) (1) ->
(CreateAndPushNugetPackage target) ->
  G:\test\after.test.sln.targets(41,5): error MSB3073: The command ""packages\NuGet.Comm
andLine.2.8.2\tools\NuGet.exe" push G:\test\\*.nupkg  -s  " exited with code 1. [G:\test\test.sln]

Enable dnn manifest tokens

• Blocked by #15 Done.

Rather than the developer having to explicitly replace some values (in square brackets) in the DNN manifest file, I could automatically set them using properties of the project. For example, rather than the following manifest file:

<package name="[YourPackageName]" type="Module" version="0.0.0">
      <friendlyName>[FriendlyPackageName]</friendlyName>
      <description></description>

It could instead contain variables that I will automatically substitute with appropriate values:

<package name="$projectName$" type="Module" version="$manifestVersionNumer$">
      <friendlyName>$assemblyTitle$</friendlyName>
      <description>$assemblyDescription$</description>

These values will come from the corresponding project properties

One important thing to note will be that when you use a variable in the manifest for the version number (like below), then by default it will be set according to an MsBuild property named $(manifestVersionNumber) which by default, will be set from the AssemblyInfoVersion (Major.Minor.Build). You could optionally override this variable with your own version number - i.e perhaps a version number based on the Team City build counter etc.

<package name="$projectName$" type="Module" version="$manifestVersionNumer$">

Support for producing "Sources" package.

Currently, the install package produced does not contain source code files.

There should be the option to also produce a sources version of the install package.

This can work in exactly the same way as in it would include everything the regular install package includes, but it would also need to include source code files - which is currently any file in the project with one of the following extensions:

1. cs
2. vb

Support CPS based project systems

I need to adapt the nuget install script to support the new CPS based VS project systems in which the project is not in the GlobalProjectCollection see here for details

Add module.css file

@dazinator it would be great for DnnPackager to add module.css initially for module development. I suppose this would not be relevant for theme development, so not sure what to recommend there. :)

Build error

After adding the nuget to my project and building, I get the following error:

Description: The imported project "...\packages\DnnPackager.1.0.2.build\MSBuild.Community.Tasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. ...\packages\DnnPackager.1.0.2\tools\DnnPackager.targets

File: ....nuget\NuGet.targets

The .build folder is in the folder with my solution file, not in the packages\DnnPackager.1.0.2 folder.

The project seemed to build and I have a zip file in the InstallPackages folder.

Licence file, not included in package when changed from .lic

Need to investigate the following, raised via Skype Chat:

I had changed the name of the file to License.md (to follow the GitHub convention) and that in turn breaks it (switches Build Action to "None")
changing it back to "Content" does not resolve the issue either

Setting the Build Action to "Content" should always result in the file being included in the install zip - so I need to investigate whether there is an issue with this.

Auto-build manifest file

@dazinator not sure if you have looked into this possibility or not, but thought I would at least log it for consideration. I ran across some work being done by XCESS here and thought it was a great idea. It would be nice to not have to manually maintain the manifest file. Your thoughts?

Package / Manifest Validation

DnnPackager is in the unique position to do some validation on your manifest / install package at build time, and perhaps output warnings during the build.

Some checks that it could do might be:

1. Have you included a release notes file?
2. Have you included a licence file?
3. If you have specified the above files in the manifest, have you actually included those files in the package / your project - because otherwise DNN will fail the install.

Team City Artifacts

During a build, use stdout to inform team city of the Dnn installation zip file that was produced - this means it can automatically show up in the artifacts tab in the team city build (without having to do any config in Team City itself)

It's envisioned that most of the time you won't want to capture the zip file as an artifact - instead you will probably want to capture the NuGet deployment package. Therefore by default this functionality will be switched off, but could be turned on by passing in an MSBuild property:

/p:DnnPackagerPublishDnnInstallZipToTeamCity=true

DnnPackager build targets disabled by default for additional build configurations

DnnPackager msbuild targets (the msbuild logic that handles producing install zip when you build) are only enabled by default for Debug and Release builds, if you create a new msbuild configuration then DnnPackager build targets do not run automatically. To make DnnPackager run you currently have to set the msbuild propery:

RunDnnPackager

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Client|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    /// shortened for brevity
    <RunDnnPackager>True</RunDnnPackager>
  </PropertyGroup>

This will catch people out. Change it so that DnnPackager always runs by default, but people can instead disable it if they want to.

Enable Publish to a Store?

Investigate possiblity of publishing your module to the DNN store (or my own??) via something like:

Publish-Module [ModuleName] [AccessToken / Username / Password]

This would build and then upload your package to the store.

I have a feeling the DNN store may not have an API for this kind of thing. So potential to create a basic store website on azure, that allows people to mamage their packages similar to NuGet.org but for DNN modules / extensions.

NuGet package doesn't update `before.` and `after.` targets files on installation.

The NuGet package doesn't deal with updating those 2 special targets files when it's installed.

It does however create those 2 files if they don't exist in the first place, and this happens in init.ps1 (which runs whenever you open the solution). This ensures that if you change the solution name, the files will be regenerated with matching names when it is next opened - which is better than nothing.

So the only way currently to deliver fixes to these files (i.e when a new version of the NuGet package is released), would be to ask the end user to delete the existing before / after targets files, so that they can be recreated at the latest version.

This needs to be fixed. Suggest adjusting Install.ps1 (which only runs on install of the package) to add some logic that searches for the existing files and overwrites them.

Missing iconFile node in manifest

The manifest file is missing the iconFile node.

Unable to deploy

Hi,

Not sure if it is just me but I cannot seem to deploy my module Running the command Install-Module Fidelity(my website name in IIS).

Keep getting the following:
PM> Install-Module Fidelity
Executing build --envdteversion 14.0 --processid 6316 --configuration --name Fidelity --websitename Fidelity
Could not parse arguments:
arg 0, value enclosed in double asterix: build
arg 1, value enclosed in double asterix: --envdteversion
arg 2, value enclosed in double asterix: 14.0
arg 3, value enclosed in double asterix: --processid
arg 4, value enclosed in double asterix: 6316
arg 5, value enclosed in double asterix: --configuration
arg 6, value enclosed in double asterix: --name
arg 7, value enclosed in double asterix: Fidelity
arg 8, value enclosed in double asterix: --websitename
arg 9, value enclosed in double asterix: Fidelity
Dnn Packager
DnnPackager 2.0.6+2.Branch.master.Sha.e50957a2c76e82b58f563ad53fff78bded5c57c1
Copyright c Darrell Tunnell 2015

--deploy Deploy packages to a local DNN website in IIS.

--build Build a visual studio project and deploy the packages to
a local DNN website in IIS.

--install-targets Install the DnnPackager targets to a visual studio
project file.

--help Display this help screen.

Where am I going wrong here?

Set up docs site, on ReadTheDocs

More friendly error message if not running VS as Admin

As encountered by @nvisionative and others, when running the Install-Module command, DnnPackager uses the WebAdministration library to query IIS to get info about the Dnn website. However this errors if not running VS with sufficient permissions. Raise a friendlier error message when this is the case asking the user to "please ensure you are running VS as Administrator"

As a secondary task, find out if its possible to set things up.in IIS in such a way that running VS as Admin is not necessary.

TFS pending changes incorrect

When adding the NuGet to a project already in TFS, two files getting marked with the add pending state, but are not present on the file system:

1. MSBuild.Community.Tasks.ReadMe.md
2. rename.nuspecc

This will cause a checkin to fail, and one has to undo the pending add for these two files.

Furthermore, the following files are not added to TFS:

1. after.JE.D2D.Modules.sln.targets
2. before.JE.D2D.Modules.sln.targets

Lastly, Build.proj shows up in the Solution under the .build folder, but doesn't appear there on the filesystem (unlike the MSBuild.Community.Tasks.* files).

Move msbuild xml logic into a C# Custom Build Task class and Create Unit Tests

The MSBuild scripts are getting quite complicated which makes things harder to maintain and pretty impossible to test.

I should create a custom build task class instead - written in C#. I can move most of the logic out into that custom task. This will then be possible to unit test and easier to maintain in the long term.

Move location of output packages (Install/Source) from \bin to \install

This will be a more intuitive location for output packages. The \bin directory is a special one and should be reserved for typical files (*.dll, *.pdb, etc.).

Register DNN Web Controls like the TextEditor ?

How would one reference a DNN user control like TextEditor that normally is registered by referencing DNN controls folder like so:

<%@ Register TagPrefix="dnn" TagName="TextEditor" Src="~/controls/TextEditor.ascx"%>    

Remove dependency on MsBuild Community Tasks

Currently depend on this package to provide msbuild tasks for creating zip files etc.
However it get's dragged into peoples solution when they add DnnPackager NuGet Package (because we currently need it) and it pollutes the solution by adding a .build folder and all sorts. This can be scary for people, and I also don't like it.

With #15 we are implementing all of our build / packaging logic in Unit testable, C# build task classes, including the zipping logic. This hopefully means we can get rid of MsBuild Community Tasks as a dependency.

Install-Module command not building project.

Testing has caught a problem introduced by the latest merge from development branch. Need to fix this prior to publishing NuGet release. The issue is that when doing a Install-Module command in the package manager window, it isn't trigerring a new build of the project so it ends up installing the old zip eachtime to your dotnetnuke site and not an updated one.

Rework install of targets files

At the moment, there is a custom install.ps1 powershell script in the NuGet package that makes alterations to the project file in order to add the DnnPackager targets, and this has logic to detect octopack so that if octopack targets are present, then the DnnPackager target is added before the octopack target. This allows DnnPackager to automatically set OctoPack MsBuild variables if OctoPack is present so for example, it can set the OctoPack version number for the NuGet Package to be the Dnn version number in the module manifest.

However OctoPack is really not necessary for NuGet packaging and this is complicating the install process quite a bit. There are simpler ways to package up your modules as NuGet packages for deployment purposes, so lets look to remove this octopack stuff from the install script.

Can look to adopt the following to let NuGet handle installing the targets into the project instead? https://docs.nuget.org/create/creating-and-publishing-a-package#import-msbuild-targets-and-props-files-into-project

Zip file is not output to bin/debug or bin/release

DnnPackager is not using the intermediate output directory (/obj/ folder) for its packaging location, instead its doing it directly in the project dir. This means it leaves the zip file there. The zip file is not produced in your bin/debug or bin/release directpry (output dir) as you'd expect either.

Add support for SPA and MVC development for DNN 8

With DNN 8 launching very soon, it would be fabulous to add support for SPA and MVC development. Please see https://github.com/jbrinkman/DNN8Templates (temporary location) for more insight.

Move build to appveyor

I am currently using a private team city instance for CI builds of this project.
Move the build to AppVeyor instead, and update the ReadMe with a build status badge.

Get Team City CI build and Release build set up for NuGet release.

Set up Team City build.

CI Build --> Will use GitVersion for semver. Will update assembly infos with sem ver. Will create NuGet package release asset, using semver version approriate for NuGet. No unit tests to run currently.

Release Build (same build chain) --> Will nuget push the nuget package asset (from same build chain) to nuget.org. Will create release on GitHub, with auto generated release notes (using GitReleaseNotes) detailing issues closed (and PR's etc) since last release.

NuGetOuputDirectory - NuGet.exe pack -outputdir doesn't like trailing slashes

The msbuild property for the NuGet pack output directory is set:

$(SolutionDir)

however this has a trailing slash that causes NuGet.exe pack command to fall over when passing it through as the outputdir argument.

The solution is the trim the trailing slash:

$(SolutionDir.TrimEnd(''))

This problem with NuGet was recorded here: https://nuget.codeplex.com/workitem/901

Installing Dependent Modules

When you Install-Module if that module is dependent upon another project that also references DnnPackager, then the install zip for that other project should also be built and installed, so the complete dependency chain of projects are installed together.

This used to work in V1.

Package Zip and manifest validation on build

On project build, we can validate the manifest file (I already have a seperate library to do this) and fail the build if it's invalid. Can also write warnings and info for common things based on best practices (providing owner, license info etc).

If the manifest file is valid, can proceed to validate it against the contents of the zip. For example if the manifest has files specified that don't exist in the zip, we can fail the build with appropriate errors.

Support for Deploying a "Client" package only.

When making superficial changes to client side files like javascript, or ascx files, that don't require a new assembly / dll to be deployed, currently the only way to deploy them with dnn packager is to install the complete module zip, which includes the dll, and will cause the site to restart. This can be slooow and annoying.

Find a way of allowing the developer to just deploy a "Client" side version of the package instead, that will be the same as the ordinary zip package, just not include any dll files.

I think the best way to handle this might be to extend the Install-Module command to something like this:

Install-Module [SiteName] [BuildConfguration] [Attach] --Client

However this command line is getting a little bit verbose and I can see that people might need to easily be able to switch back and forth between deploying "client" files, and deploying a full package when they make changes to compiled code.

Ideas welcome.

One workaround for now, is whilst you just need to make tweaks to client side files, you can edit them directly from the website folder, but then copy them back into your source in visual studio when you are done, but I don't like that approach as editing directly in website is in my opinion a lazy solution to the problem that doesn't encourage clean seperation between source and host.

Create Unit Tests

I can do this in conjunction with #15

Support .dnnX manifest files

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.