Accepted Solutions
I was afraid of that 
Wouldn't that be a useful technote ? I can imagine other ThinApp users would benefit as well.
True, but then again there will always be exceptions to a BP rule 
I was just thinking about some general concepts, that would avoid that packagers would have to reinvent the wheel each time.
And the remarks you just made would be useful exceptions to the general BP. At least people would know, or consider why, for example the Cookies folder would have to be kept in the package.
Thanks Peter, that was my idea as well.
Although my contribution will be minimal, I have no problem starting
When I'm creating a ThinApp package I have some fixed steps I run though to clean up the package.
- I prefer using something like ThinAppHelper, because it gives me a visual view on the Folders and the Registry entires
- Folders:
- I look first at the obvious candidates
- %Cookies%
- %Fonts%
- %Local AppData% for automation services (in our case RES),
- %Personal%
- %SystemRoot%\Installer
- %SystemRoot%\ServiceProfiles
- %SystemSystem%\Spool
- Then I browse through the other folders to find any obvious unrelated entries
- Registry: defenitely more intricate as the Folders. In fact I don't have any BP rules I follow, I just browse through the structure and remove the obvious branches.
It is obvious that somewhat with a lot more ThinApp packaging exprience would be able to give more concrete BPs (out of his experience).
.png "Squidly_Man"){kind=avatar}
Thanks for the answer and the links Dean, and for the constant flow of good ThinApp information you deliver to us.
Those 2 blog posts are in my Bookmarks since day 1 
My suggestion was to bring all that, somewhat dispersed, information together in one central location (beit a paper or a website).
The 2nd part of my suggestion was to have some kind of user experiences repository.
Something like ITNinja (the former AppDeploy) is doing with their Software Library.
