That would be an interesting trick. Especially since I just stated that the #Directives# still work during Regen-mode. This would also imply that #ApplyPatch# should work... just need to figure out a way to get a copy of the Patch archive (or folder) from the source during install-mode. Something like so: <Assembly>#DOS# Copy Patch.7z %AppPath% /y >nul:#ApplyPatch# And no, I have no idea if something like that would work both for Install-mode and Regen-mode
Right. It would be nice if this could somehow be done (to work both in Install and Regen modes) because it would make ppApps pretty darn solid and 'permanent' lol
Just did a simply test, and it seems very plausible that you could do that. I'm just not yet sure why someone would want to do that. LOL
@RON - <Assembly> does get processed during Regen-mode. But only the #Directives#. This way one can customize the order of the regen process
LOL, I think we're not all on the same page. What I was talking about was ppApps that *require* certain files (like .xml's, .ini's, etc.) in the AppData or ProgramData folders, or those app will not be activated/registered. It's absolutely no problem to achieve this when install these as ppAppsInstalls ("Install mode"). What I was talking about was a way to make any such "patch" archives or files run also in Regen mode, toward the goal of activating/registering that app again (in case you reinstall your OS but have the ppApps folder on a non-system drive). As it is now, such ppApps won't get activated/regged again. For ppApps that rely on reg tweaks or files to be present in the app's own folder, this is of course no problem. It is those apps that require a certain file(s) in the Users folders or ProgramData folders that lose their activated status in the case they are Regen'd. Example is FairStars Audio app. It needs the regging .ini file in the AppData\Roaming\App.Name folder. So you can use a patch archive to write the .ini to that location. But upon Regen this won't happen again so you're stuck with a non-regged ppApp after you reinstall your OS.
To be clear: some apps rigidly look for a certain .ini file in a ProgramData\App.Name location. If that .ini is not there and filled in properly with user name, serial, etc., the app won't register. Those apps can't be activated through the registry or by having a license file present in the app's own (app destination) folder. They will only work if the activation/registration files (usually .ini or .xml files) are present in the required locations. Usually there are: ProgramData\App.Name or AppData\Local\App.Name or AppData\Roaming\App.Name.. You know what I mean, right, Freezer?
Probably the safest rule of thumb is what RON said and that is to use <Assembly> for Install-mode only. All the other stuff: <Script>, <Registry>, <Extensions>, <InstallFonts>, <RegisterDLL>, <ShortcutS> are for both Install-mode and Regen-mode. And <Script> seems to be the real workhorse here. Especially if you throw in the use of the %Component% tools
OK, well I was mentioning it in case you were interested in adding in a solid method to re-activate said apps through Regen mode. Personally I have no problem with the way things are because I have my ppApps installed on the system drive. This is why I never use Regen mode (although I guess ppAppsLive fall under that category). But it wouldn't seem impossible or even that hard to have the patch archives apply at Regen stage as well. Or, I would need to learn how to do the Assembly extract trick in the Script section. But as you know my coding isn't my strength
That <Assembly> hack I posted here might actually do what you want; but I didn't want things to get even more confusing than they already were becoming Perhaps play around with it a little. If it works, great -- we've got another way to do it. If not, well -- we've got another way to do it. LOL
Don't worry about it Just trying to help but it looks like not many people ran into those particular apps (and there aren't that many app like it to be frank). But if you're interested, look at that Auto.Shutdown ppApp. It requires a file in the Users\{Username}\AppData\Local folder (an .ini) or it will not run. EDIT: man we keep posting at the same time, that doesn't help whoever is reading this thread lol EDIT: just re-read my above ramblings, and to be honest is sounds more like a covert request for you to apply your mad skills to that app and make it work in Regen mode as well But it's OK if you don't want to do it.
Or better yet, something like this: <Assembly>#RunScript##ApplyPatch# <Script>Copy %SourcePath%\Patch.7z %AppPath% /y >nul: Nice thing about this is if %SourcePath% is the same as %AppPath% then it will simply skip over the "Copying" (effectively ignoring it).
Hmm, I was previously relying on the %Extract% "Patch.7z" -o"%UserProfile%..... etc. under <Assembly> to apply the file inside the Patch.7z archive. But if I do #ApplyPatch# then how does it know where to write the file, since there won't be a path mentioned like there is in that %Extract% line. Or is there? For example, now I have: <Assembly> %Extract% "Custom.7z" -o"%UserProfile%\AppData\Local\AutoShutdown" And a Custom.7z archive with the required .ini file inside it. The %Extract% line gives the location where to write the .ini to. But if I use #ApplyPatch# how would I tell it where to write it?
FYI, this is what #ApplyPatch# looks like: %SourcePath%\%Extract% "%SourcePath%\Patch.7z" -o"%AppPath%" So, I'm thinking that because it'll be in Regen-mode then %AppPath% is the same as %SourcePath%. So it should work. I've not actually tried it though. LOL
I don't think this works... All I get is the Custom.7z to copy to the AppPath (ppApps\AppName folder) but it won't apply it, it only copies the archive itself (this is in Install mode). I have this: #RunScript# #ApplyPatch# %SourcePath%\%Extract% "%SourcePath%\Custom.7z" -o"%UserProfile%\AppData\Local\AutoShutdown"<Script> Copy %SourcePath%\Custom.7z %AppPath% /y >nul:
We were trying to both have the archive (or file) to apply during Install-mode as well as Regen-mode. I can get it to apply any file anywhere from Install-mode, but the trick is for it do this both in Install-mode and Regen-mode. Is that also what you are talking about there?
I never used Custom.7z as an example (Trouba did) A couple things here... 1. #ApplyPatch# takes on no parameters nor arguments (you've tried that before, Trouba! LOL)2. #ApplyPatch# only looks for and extracts archives called "Patch.7z", or "Patch.rar", etc. -- also folders called "\SetupS\", "\ssApp\", or "\ppApp\", or "\ppGame\" which simply get copied to the %AppPath% from the %SourcePath%.So maybe try again only make sure to rename "Custom.7z" to "Patch.7z". That's the key.
I got the impression because you wrote: This is what I was trying to do: a) I need the program .exe to go to %ppApps\AutoShutdown. b) I need the Configuration.ini to %UserProfile%\AppData\Local\Autoshutdown. ^^I have already achieved this part long ago though, so I can already do the above. This is what I'm trying to do now: - Do the above (a&b) - Upon Regen, have the Configuration.ini (which I'll also include in ppApp.7z so it will be in the ppApps destination folder as well) write to %UserProfile%\AppData\Local\Autoshutdown again. I would think since in both cases the .ini file is effectively in %SourcePath% it should do this. (I'll have it both outside and inside the ppApp.7z archive in the ppAppsInstalls folder) But how to Copy or Extract from the <Script> section so that it makes the AutoShutdown folder? I was successful in writing the Configuration.ini via the Copy command, but it won't create the AutoShutdown folder at %UserProfile%\AppData\Local\ If this is possible (one way or other) then all ppApps that need activation info in User folders can remain just that: pp (permanent portable) apps. If not, you reinstall the OS and those app won't be regged/activated anymore. So you'd have to reinstall them, even tho the remains will be in the ppApps folder and Regen will make shortcuts for them. But they won't be registered/activated. So I have Printer's Apprentice, AutoShutdown, FairStars Audio, FolderSizes, etc. that all require this.
Another possible hitch is that if it thinks it's a ppAppsLive type of install then it'll delete the "patch.7z" file from the %AppPath%. Which means you might see the archive disappear afterwards. As I've said, I've not tested any of this, so who knows if it'll really work? Anyway, kudos to you if you can get it to work. And cheers for at least trying
You don't need a Patch archive if done the way I explained. You typically only need ini's or xml's, so there is no size element involved usually. So i was thinking to add the actual ini files to the ppApp, both outside and inside the ppApp.7z. So there will ALWAYS be one of these files considered in %SourcePath%, but only 1 in relation to the .app file of course. So this should work but I don't know how to write the files to User folders when those folders don't exist yet (how do I give Path info for the ini's, etc.).
It's OK if you don't want to do it, but much lesser features have been added to SetupS, which is why I can't understand the resistance. Actually I don't think you understand what I'm talking about at all (which is probably my fault lol). Do you understand what I mean? It means Regen won't work for any apps that require activation through User folder files. That would seem not a ... small deal, right? I know exactly what I want to achieve, but I can't technically do it. But I just know you can But I don't think you understand what I'm trying to do. Or do you?
Let me try to explain: We add the .ini's or .xml's or other files (needed for activation or configuration) in an archive. Let's call it "Custom.7z" to differentiate it from "Patch.7z" which cannot help with this. This "Custom.7z" archive will be added to the ppApp in question BOTH inside and outside the ppApp.7z archive. This means that there is a "Custom.7z" present whether SetupS runs in Install-mode or in Regen-mode. We don't need any extra directives under <Assembly> but only need the following line in the <Script> section of the .app file: <Script> %Extract% "%SourcePath%\Custom.7z" -o"%UserProfile%\AppData\Local" ^(In the case you want to extract to the AppData\Local\ directory of course, for example.)^ When we install the app as a ppAppsInstalls (Install-mode), the 'outer' "Custom.7z" archive gets called on because it is considered to exist in %SourcePath%. The .ini file inside the Custom.7z archive gets written to the desired location (AppData\Local\). When we reinstall the OS but have our ppApps on a different partition, after OS install we can run SetupS Regen-mode to create shortcuts for all ppApps again and reg/install them. But the above-mentioned .ini file is no longer in the AppData folder because the OS got reinstalled and the User folders wiped. But, Regen-mode will run the same <Script> command again and since we added "Custom.7z" archive inside the ppApp.7z archive as well, it will be present in the ppApp folder and it will extract the Custom.7z contents just like in Install-mode and the app is regged/activated again.
So the "Custom.7z" archive is both inside and outside the "ppApp.7z" archive. See the pic: Here, take a look at the app itself so you can see better what I mean: http://www.lastos.org/team/Trouba/ppAppsInstalls/Auto.Shutdown_v1.0.0.42_ppApp.apz Now, try regular (Install-mode) install. Then, remove the "AutoShutdown" folder in Users\Administrator\AppData\Local\. Then, run the .app file inside your X:\ppApps\AutoShutdown folder. It should create the AppData\Local\... folder and the .ini inside again. This would be Regen-mode, as it were.
