Update-Module command

[bradbamford]

90% of my in development updates are Javascript and CSS changes. After each change I execute "Install-Module websitename" and then refresh the browser to see and test the change.

The problem with this is, that it also copies over unmodified dlls into the websites bin folder causing IIS to restart the DNN application. This is an unnecessary wait.

Is is possible to add a new command "Update-Module" that only pushes over changed files? This would greatly speed up development testing time.

[dazinator]

Hello!

I did actually add a feature to dnn packager to help with this problem..

In your project, add a copy of your manifest.dnn file but call it manifest.debug.dnn.

The "debug" is just the name of a build configuration in visual studio that you intent to build with.

Remove the lines from the manifest.debug.dnn file that install any DLLs. It should just therefore include content files / resources etc.

When you run install-module, add the argument that specifies the build configuration (Or you can just make sure your active build configuration is set to debug)

You should find after this, that dnnpackager will use the build confoguration specific version of the manifest file when creating and installing the package - and as this one doesn't carry any DLLs with it, hopefully no restart will be caused.

I agree with you though that an update command would be nice. However this gets more into file sync territory or partial installs which is something I am keen to avoid with dnn packager.

If you do try this I would be interested to know how it goes.

[bradbamford]

"Update-Module": Since the Manifest tells us the installed module's foldername (in DesktopModules), couldn't we bypass DNN's now patched Install/Install.aspx?mode=installresources by just coping the files across the local filesystem?

It could copy over all changed files and would work for all updates as long as the Manifest itself hasn't changed.

manifest.debug.dnn: That's certainly interesting, but not exactly what I need. And for some reason, page refreshes seemed to take just as long even with the assemblies removed. May be just me, I'll see if I can find out why.

[dazinator]

So you propose that something watches for file changes and copies them over automatically when they change?

My only issue with disk based deployment (I.e bypassing dnn's installer logic and copying files directly) is that dnn's installer has different conventions around where it puts things when it processes the install package. It also ensures it's database tables are kept in line with respect to the package being installed and the components that the package contains.

This would be bypassing all of that install logic. However I dont see a problem with that as long as:

1. We only watch / copy over files that dnn has already installed.

In other words, after installing the module, this feature would watch the files that were in the package. If a new CSS or JavaScript file is added to the project, it wouldn't be watched. You'd have to do another install of the package with the file in for that new file to be watched.

I'd also say we just start by watching js and CSS files only.

What are your thoughts about that?

[dazinator]

Also, re the apparent site restart after a module install with no dll's - this is something that I think I've seen before, so I dont think it's just you. I think something about the dnn install wizard may just restart the site regardless - even when it doesn't need to, perhaps by touching the web.config file or sonething. I never chased it up though.

[bradbamford]

Yes, I agree anything that modifies the manifest or database would require running it through the DNN installer again, either through "Install-Package" or uploading directly.

However, why limit to just previously installed css and js files? What would it hurt to copy over everything in the Resources.zip and the controls?

For example, editing a control (Default.ascx or Default.htm) to add a new image in the html wouldn't break any assemblies and could easily be pushed over without requiring any server changes.

[dazinator]

What would it hurt to copy over everything in the Resources.zip and the controls?

That would be ok. I think DnnPackager will first have to inspect the manifest, to look at the package types, and component types defined. Then handle them on a case by case basis.

For "resource zip" components, DnnPackager could directly copy their contents accross, because AFAIK all Dnn does with them at install time is extract them to a location anyway - i.e it doesn't do any clever processing (except maybe file type blacklisting / whitelisting)

For module definitions, handling the user controls (ascx) also makes sense.

For other component types (skins, etc) I think we'd have to extend the logic on a case by case basis.

The way I would propose starting on this feature, would be to extend the DnnPackager.exe with a --watch mode. Then add this to the powershell script, so you can do a Install-Module --watch or something similar.

In terms of changes for DnnPackager.exe, it would just need to do a normal install of the module, but after that is finished, it would need to inspect the manifest to work out what files to copy and where too. In terms of where to copy files too - it already has the physical path to the dnn website folder at this point, so should be pretty easy.

I have already written a standalone library that enables us to load a manifest file, to give you a strongly typed representation of it: https://github.com/dazinator/Dazinate.Dnn

So all in all, I think this feature sounds faesible.

Now its just a case of finding some time to work on it. Something I won't have for a while - as I am working in a Visual Studio project system in my spare time at the moment.

[dazinator]

I will look to address this using a "--watch" style command after the 3.0 milestone.