Documenting MSI
Typical of most developers, the documentation comes after the development.
I want to hand over the MSI development over to someone else but obviuosly not just show them the project file and say "get on with it!"
In your opinion, what would be the best way to document this information?, flowcharts are normally good but with having 50 odd custom actions runnning under various conditions could prove to be a nightmare to write.
Also, apart from the obvious Microsoft office suite are there any CASE tools or alike which could handle this well?
Regards
Paul
I want to hand over the MSI development over to someone else but obviuosly not just show them the project file and say "get on with it!"
In your opinion, what would be the best way to document this information?, flowcharts are normally good but with having 50 odd custom actions runnning under various conditions could prove to be a nightmare to write.
Also, apart from the obvious Microsoft office suite are there any CASE tools or alike which could handle this well?
Regards
Paul
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
jmcfadyen
16 years ago
I use a standard for creating custom actions.
By prefixing properties, CA's, File / Reg variables you can use code to parse the MSI and extract anything that matches the prefix. This way you can automate the creation of tables containing the customised sections of your app.
I use the MS Office object models to generate doco. (ie Word.application) I can send some sample document templates that show how to setup a document to receive data pushed in from external sources.
By prefixing properties, CA's, File / Reg variables you can use code to parse the MSI and extract anything that matches the prefix. This way you can automate the creation of tables containing the customised sections of your app.
I use the MS Office object models to generate doco. (ie Word.application) I can send some sample document templates that show how to setup a document to receive data pushed in from external sources.
Posted by:
danr29
16 years ago
Posted by:
deploy.no
16 years ago
I'd appreciate it if I could have a look at those templates, John ..
This discussion is interesting as I'm working with developing better docu standards myself at the moment. We use a similar approach but as we don't like MS Word we output the data to a plone site instead :-) This far it seems we got quite a job to do when it comes to cleaning up stuff we did BEFORE setting the standards (I know, thats not the way it should have been, hehe).
One thing worth mentioning is that we are now considering moving from using setacl.exe to setacl.ocx and custom tables, like documented here by a post from nheim. The extra tables kind of makes the ACLs more self-documenting, I feel.
Edit: nheim credited for the link
This discussion is interesting as I'm working with developing better docu standards myself at the moment. We use a similar approach but as we don't like MS Word we output the data to a plone site instead :-) This far it seems we got quite a job to do when it comes to cleaning up stuff we did BEFORE setting the standards (I know, thats not the way it should have been, hehe).
One thing worth mentioning is that we are now considering moving from using setacl.exe to setacl.ocx and custom tables, like documented here by a post from nheim. The extra tables kind of makes the ACLs more self-documenting, I feel.
Posted by:
jmcfadyen
16 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.