First manifesting your application has nothing to changing your code to C# and you don't just want to start converting your code to C# for only a year later to still have exactly the same functionality as you did before. If your code base is working for you then stay with it. There is no downside.......only an upside. I have to manifest controls made by codejock into our executables, so how do I go about it? I use Visual Studio (You could use the Express Version) and create a dummy Winform project, onto the form I drag the required OCX controls but mark them as "isolated", this tells Visual Studio to create a manifest. SO you start hunting down your project sub folder to locate it. I then edit the manifest, for example the codejock control I want the exe to use are in the applications subfolder called controls.I also take out the checksum information as on occasion we have had a fixed version of the codejock control where the version number has not been changed but the file size has. Once I have a complete manifest it's then built into the executable. NON of the testers or QA staff are allowed to have the Codejock controls registered on their machines.....then we test the applications. I implemented this when Visa was released and UAC introduced. It's still worthwhile you pursuing this technique, it would allow you to have different versions of your product running on the same machine (if COM was the limiting factor). I also have certain DLLS where COM extraction does not work in InstallShield or other tools and I resorted to handcrafting the manifest at great pain.....but its worth it. ... View more

I am not aware of a transient table or view that contains a list of registry entries actually written during installation. However, you could jump through some hoops to arrive at the same list by cross-referencing components' action and Registry table. ... View more

Also note: When rebuilding the msi package with updated ActiveX files using the same msi component codes, same basic msi project def., if we specify the previous msi package as a reference for a MinorUpgrade item, the IS2014 IDE *does* warn about registry entries that will be orphaned, as shown below : ISDEV : warning Val0009: A registry entry has been removed from the component 'AlphaBravoCharlie.dll.v1.0'. This key must be added to the RemoveRegistry table, otherwise it will be orphaned by an upgrade. '0|interface\{64973099-33b4-4701-b72f-64ce94df2604}\typelib|'. c:\abctest\sources.v1.1\kit.previous\abcinstallermsi.msi Since the build engine is aware of the specific registry keys that will be orphaned, having a provision to automatically add these keys in the RemoveRegistry table would have been the definitive solution to the problem... Could InstallShield not implement this? ... View more

Actually, our COM components do unregister themselves when uninstalling - there is no trace of them left in the registry after the uninstall. As for the COM-extract best practice, this can only be done for the Key file; our files are added using a Dynamic Link (w. best practices), so this solution is not feasible for us. Also, the COM-extract process results in registry entries that are somewhat different than the component's self-registration process: the COM component is usable by programs but "invisible" for referencing in VB6 or searching through our registry utility. As for coding standards, our COM components are all "Binary Compatible", and we never break an interface. Adding new methods/properties to an existing interface does not break it, it just "versions up" and remains fully backward compatible with every program that used the previous versions. Said previous programs can use the new version without even being recompiled. If you *change* and existing method or property signature, then you are breaking the interface and are indeed creating a 'new' component', thus requiring a new GUID. You really should not just lightly assume we don't know how COM works, nor imply we're not using best practices. ... View more

Hello, Our company is trying to migrate some setups to MSI projects and we are being faced with these exact problems. Because this is the official flexera community forum, i'd like to know if it is possible to get a somewhat official response about what can and can't be done in MSI projects regarding this dynamic links issue in minor upgrades? The migration from InstallScript to MSI is starting to look like a downgrade and a dangerous liability for our company, if things like the case of a DLL or a simple subfolder in dynamic links break a minor upgrade. This isn't something that can be explained to a paying customer easily... We have a lot of dynamic links with sub-folders, mainly for "blind" distribution of folders and distribution of localized resources. Things that will change our work methods and increase wasted time handling the setups, if they need to be changed... Thank you for your help. ... View more

Thanks Robert!! I don't have the time to try this out right now, but I'll keep a sticky on this and update when I try it: it looks like it should solve the problem nicely! (and thanks to chrislynn5 for bumping the thread! 😄 ) ... View more

DebbieL wrote: Have you tried SETUPEXENAME? The path and file name: [SETUPEXEDIR]\[SETUPEXENAME] THANK YOU !!!! THAT'S EXACTLY IT!!! 😄 (Seems rather obvious now, in retrospect... why did I not think of that myself?:o ) Tx for the quick reply! ... View more