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

[dazinator]

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.

[dazinator]

@nvisionative - Ok I have replicated this issue. It's due to the fact that setting the build action to "content" only adds the file to the "resources" zip that's within the install zip. However, licence files, (like release notes files, and sqldataprovider files etc) must be directly inside the install zip for the DotNetNuke installer to find them, so simply including them in the resources.zip by setting a build action to "content" doesn't actually help.

The reason it works for "licence.lic" files is because the current packaging logic treats ".lic" and ".sqldataprovider" files (and ReleaseNotes.txt) as special files that it knows by default should be included directly in the install zip:

 // find any
            // .sqldataprovider files 
            // .lic files
            // "ReleaseNotes.txt" file
            // and copy them to the same relative directory in the packaging dir.            
            ITaskItem[] specialPackageContentFiles =
                FindContentFiles(t =>
                    Path.GetExtension(t.ItemSpec).ToLowerInvariant() == ".sqldataprovider" ||
                    Path.GetExtension(t.ItemSpec).ToLowerInvariant() == ".lic" ||
                    Path.GetFileName(t.ItemSpec).ToLowerInvariant() == ReleaseNotesFileName.ToLowerInvariant()
                    );
            CopyFileTaskItems(ProjectDirectory, specialPackageContentFiles, packagingDir, false, true);

This means that if your licence file doesn't end in ".lic" it won't be included in the install zip anymore by convention.. However there is a way to force any file to be directly added to the install zip.

1. Open the DnnPackageBuilderOverrides.props file that is in your project:

1. Add an entry like below to include your file - i.e Licence.md

    <!--ADD ANY ADDITIONAL CONTENT FILES YOU WANT TO BE INCLUDED IN YOUR ZIP PACKAGE HERE"-->
    <!--<PackageFiles Include="$(MSBuildProjectDirectory)\..\..\lib\Business\Mappings\**\*.zip" />-->
    <!--<PackageFiles Include="$(MSBuildProjectDirectory)\MySpecialFile.special" />-->   

    <PackageFiles Include="$(MSBuildProjectDirectory)\License.md" />

Now, when you build the project, if you look in the zip, you will see its also including this file:

This mechanism is the current way to tell dnnpackager to include any arbitrary files in your zip package.

So based on this, I will close this for now, however I believe that #51 will improve this situation in the future, by ensuring that problems with missing files in the package are validated during build and result in build errors / informative messages, rather than going unnoticed until deployment / install time.

[david-poindexter]

HA! You beat me to it! :) Thanks for looking into this and for providing the work around. Do you think this warrants a pull request or more of an individual preference thing? If you want, we'll be happy to make a pull request.

[dazinator]

Thanks! Hmm I'd say for now, I don't think the Dnn install wizard at present supports rendering markdown format (.md files) as HTML (like GitHub and other services do), and so if using a markdown file (.md) for the dnn licence file, even though by its nature markdown format still remains fairly readable, the install wizard won't present it with any HTML formatting at all. So it will be pretty inferior to what can be achieved using a HTML file for example.

I'd say without some more official support for rendering markdown files nicely within the Dnn Install Wizard, i'd be hesitant to add any conventions around ".md" files to DnnPackager..

So, i'm going to park this one for the time being, and hopefully you are ok with the workaround for now? I appreciate it's not absolutely ideal!

[david-poindexter]

Excellent point - good call!