It would be difficult to create a complete and definite xsd for install.xml since its plugin based and anyone can add their own FragmentInstallers that uses their own undocumented xml markup. I can tell a bit how we do it here in Acto though.
We're packaging up all our websites and modules at build time using some simple file copying mechanism. This works well as long as you always make sure to use Static datatypes and File based functions and templates like UserControls, Razor and Masterpages. Using Xslt functions and xml templates is completely out of the question. When you make sure to follow this paradigm, creating packages becomes very easy.
del "$(ProjectDir)\Package\package.zip"
"$(ProjectDir)...vendor\7z.exe" a "$(ProjectDir)\Package\package.zip" -tzip -r "$(ProjectDir)\Package*
Now, there is a one shortcoming here which is that we're not able to delete a file during package installation. This is sometimes necessary when a function/template should be removed or has been renamed and you want to delete the old file. This can be handled by either uninstalling the package before installing it again or add the functionality as a fragmentinstaller or create some upgrade-code that gets run at ApplicationStaturp. Something like Migrator.Net (https://code.google.com/p/migratordotnet/) is good for handling Install/Unininstall via code.
One thing to keep in mind if you uninstall the package, since we're copying in folders, these folders will also be deleted again. This can be a problem if the customer is allowed to add their own functions in production, since these files will then be lost. One workaround to this, is to create multiple folders for ie. Razor functions and register them individually in composite.config. This way you can have a folder the customer can add and delete whatever they want, and a folder that only you have access to.
To sum things up, creating a deployment package is simple as long as you stick to the xcopy paradigm. Just copy all your functions, templates, css, js, images and you're good. Composite C1 from version 4.0 really don't need any registration of things but automatically picks all the files you copy to it.
We're packaging up all our websites and modules at build time using some simple file copying mechanism. This works well as long as you always make sure to use Static datatypes and File based functions and templates like UserControls, Razor and Masterpages. Using Xslt functions and xml templates is completely out of the question. When you make sure to follow this paradigm, creating packages becomes very easy.
-
First you identify what folders you're interested in deploying. Usually its something like ~/App_Data/Templates, ~/App_Data/Razor, ~/bin, ~/App_Data(Composite/TreeDefintions etc.
-
If you do changes to .config files, make sure to identify those as well
-
Now, create your install.xml and add all the folders and config files like this https://bitbucket.org/burningice/compositec1contrib.formbuilder/src/379a38eb25219557d73549193a0700def0dec903/FormBuilder.Dynamic/Package/install.xml?at=default. We're using two types of fragment installers here
- FilePackageFragmentInstaller
-
XmlFileMergePackageFragmentInstaller
-
At build time, creating the package is as simple as creating a zip file containing all the files and install.xml in the root. We use this command
del "$(ProjectDir)\Package\package.zip"
"$(ProjectDir)...vendor\7z.exe" a "$(ProjectDir)\Package\package.zip" -tzip -r "$(ProjectDir)\Package*
Now, there is a one shortcoming here which is that we're not able to delete a file during package installation. This is sometimes necessary when a function/template should be removed or has been renamed and you want to delete the old file. This can be handled by either uninstalling the package before installing it again or add the functionality as a fragmentinstaller or create some upgrade-code that gets run at ApplicationStaturp. Something like Migrator.Net (https://code.google.com/p/migratordotnet/) is good for handling Install/Unininstall via code.
One thing to keep in mind if you uninstall the package, since we're copying in folders, these folders will also be deleted again. This can be a problem if the customer is allowed to add their own functions in production, since these files will then be lost. One workaround to this, is to create multiple folders for ie. Razor functions and register them individually in composite.config. This way you can have a folder the customer can add and delete whatever they want, and a folder that only you have access to.
To sum things up, creating a deployment package is simple as long as you stick to the xcopy paradigm. Just copy all your functions, templates, css, js, images and you're good. Composite C1 from version 4.0 really don't need any registration of things but automatically picks all the files you copy to it.