Miscellaneous

Interesting!
You mean something like Ziff-Davis' In Control but produces some MSI at the end?

hmmm been working with "professional" packaging tools I would say that at a first glance using a "simple" repackaging tool would be used during "debugging". Sure it could be nice to have if you don't want to utilize advertising such as for "COM/ActiveX components" but used in a packaging "factory" to create MSIs? I don't know.

I would sure want to know how to implement snapshot/capture myself to get notice on added, changed or removed files, registry, INI-files... and take care of these. I guess listen to write and delete API calles would help.

I'm in progress of creating an MSI "analyzing" tool in C#. I'm trying to add functions that I miss from Wise and ORCA. It's first going to be a read-only tool but will add some editing in the end. It will handle filtering functionality similar to Process Monitor, search (of course), "jumping" through related tables and/or columns. The registry related "jumping" to go from ex. typelib to class and so on. Registry sanitary for "bad" registry referencing from the MSI to the existing registry on the computer. Could be used to clean up some registry junk on a machine where the application hasn't been installed yet. ICE correction both automatic/manual and tips on how to solve them fromout the info from the MSI. Just have to learn how threading works so I don't freeze the whole tool/OS during heavy load.

I'm thinking more of a simple before/after snapshot comparison (pretty standard). The difference would be that the focus on contents would be isolated to files, registry and shortcuts. It would certainly not replace tools like AdminStudio, but neither does ORCA which sees plenty of use.

For example, you mention INI files-- this "simple" solution would not use the INI table but would simply include the entire changed file in the package. This and a lack of support for things like services or activeX controls could mean that it supports "most, but not all" applications.

Does this make sense?

It most certainly makes sense and this is the single most interesting post here since .. well since AngelD helped us all doing selfsigned driver packaging ;-) I'm eager to know more about how you want to achieve this and what your main goals are.

And if I were to dream .. an open source project built on top of WiX .. modular code .. in NET/C# and PowerShell .. oh sweetness :-)

Lots of the building blocks are already there - and if you go the open source route, count me in!

It most certainly makes sense and this is the single most interesting post here since .. well since AngelD helped us all doing selfsigned driver packaging

Well, I would say the InstallShield merge module replacement instead of ISScript.MSI requirement :D

Thanks Jib. The goal would be to provide a helpful tool that could be offered free. To achieve this, it would have to be kept relatively simple which is what I'm thinking that focusing only on files, registry and shortcuts could buy me. I was hoping for feedback from some experienced packagers on what percentage of applications we can expect such a tool to be successful with. I would hate to get it done and then find it didn't support enough applications to be a helpful tool.

Perhaps it could check the package contents for items that may require attention or repackaging with a commercial application-- such as the existence of an INI file.

I have been looking at WiX and how it might be leveraged. At this phase I'm still drafting requirements so if this does come to light it won't be soon ;)

To achieve this, it would have to be kept relatively simple which is what I'm thinking that focusing only on files, registry and shortcuts could buy me.

Building on top of WiX gives you exactly as much while keeping the kitchen sink just down the hallway. If what your tool would generate at some point is xml for WiX to handle then something like a pre/post snapshot plugin architecture would be easily doable.

I was hoping for feedback from some experienced packagers on what percentage of applications we can expect such a tool to be successful with. I would hate to get it done and then find it didn't support enough applications to be a helpful tool.

These are numbers off the top of my head and order summaries,

Customized vendor-provided msi packages - 40%
Packages based on snapshots with merge modules, com/dll-registering, advertising and/or advanced custom actions/scripting - 35%
Packages based on "clean snapshots" or manual builds purely on a file/registry/shortcut basis - 25%

That last category is where a tool like this could start out. Depending on its design it could also possibly evolve .. hehe I'm getting ahead of myself.

Perhaps it could check the package contents for items that may require attention or repackaging with a commercial application-- such as the existence of an INI file.

Items that may require attention .. yes thats a good idea. Suggest a commercial application, which one are you going with? *laughs* But yes it could bring value if it would provide some sort of basic explanation as to why this and that isn't supported.

Well it sounds like a cool concept. Back in the days, I used to use Picture Taker from LANovation. I still have a copy of it. Nice and portable, runs off a USB drive - I love it. Plus, it still does the job to this day! ( Ok, only for some apps and settings :P )

I'm not saying it's up to snuff with where packages are these days, especially when dealing with MSI files. But yeah, I really loved the simplicity of being able to take a picture of where your system was before and after an app was installed and have it work almost all of the time.

These days, the snapshot utilities are getting smarter, excluding folders that don't need to be captured, using existing MSI's to modify settings, applying MST's, etc. Picture Taker isn't something that's practical anymore, but it would be great to have an app that's smart enough to be used kind of like that but in a new-age MSI format.