Q) What is best practice about registration of DLL and OCX files?

Selfreg table or Raw registry keys in registry table? Any experience with this kind of matter? Ans:)
Rex Goico Based on our experience and the best practice that we follow we always extract the COM info of DLL or OCX to a single component. We don't use self-reg table as sometimes it causes error like deleted registries after uninstall as you cannot set the attributes of it to permanent and self repair will not work if a key file is missing. And you will experience an error during repair if your dll or ocx are delivered in self-reg table. Mayur Makwana Hi Mattias, the best way to handle the COM registration for DLL and OCX files is through manually extract the COM information via inbuilt regsvr32.exe tool and include it in the corresponding component belonging to the DLL or OCX file.the reason for keeping the COM info with the related DLL or OCX component is that its intact and COM information is registered correctly.There are many disadvantages of using a selfreg table as it is indicated in the MSI SDK.one possible cause is that the DLL registers twice on the targetmachine which leads to invalid DLL count and while uninstalls the reg info is still their which causes mismatch in reference count. Sainath Kanamarlapudi Selfreg and ISSelfreg tables cause issues while deploying through SCCM. So raw registry keys is best.

1) This is regarding batch file running via msi custom action I want to execute the batch file from users system during uninstall of msi but at the beginning of uninstall means before removal of files.
1.How i will implement?? 2.what would be the sequence of custom action?? 3.what would be the condition?? 4.what would be the processing 'immediate or deferred"?? ANS)
Mattias Melkersen Kalvg 1. Use VBscripting instead of batch. 2. Put it after Install Initialize in you execute Deffered 3. Condition; Remove="ALL"

Gautam Gupta Hi Mattias, Thanks for your response. Actually I thought of vbscript only , but the thing is that , the content will create in vb scripts is quite complex then the content of batch file. Let me tell you , what i am doing through batch file.batch file would kill some task as well as delete different groups added during installation to localgroups of machine.

Mattias Melkersen Kalvg Hi Gautam You Can just Call cmd.exe /c (batch command here) It will make your life much easier. You cannot run batch otherwise in msi. Oh ofcourse you can place the batchfile among the other files in the msi and call the batch during the installation.

Gautam Gupta Thank you Mattias and Dan for your response. I have completed the task successfully using batch file. Mukesh Gandhi Hi Gautam, Firstly store the batch file in a installation location. Create a VBscript custom action --------------------------------------------------------------On Error Resume Next

dim ws:Set ws = CreateObject("WScript.Shell") cmdline:cmdline = "<Path to the batch file>" ws.Run (cmdline,,True) --------------------------------------------------------------deff execution in system context Remove = "ALL" after installinitialize

Follow Vivek

2)

Hi All, I need a clarification regarding Application isolation Concept. Is this technique still used in Microsoft Windows Platform or else its usage has been stopped with Windowd XP.

Ed Tippelt No it has not ceased with XP, and application isolation remains a valid technique where multiple versions of the same DLL need to be available concurrently. However, now that developers have generally raised their game, the need for isolation is much less frequent.

3)

Vivek Anand Hey thank u so much. And I have one more query. When I gone through various websites I came across that using of Assembly and Manifests is the most recommended method of Isolation in WindowsXP. What is the reason for that and is there any demerits in using Assemblies and Manifests.

Ed Tippelt The problem with having DLLs isolated is that there is only one registry, so you cannot have each of the isolated DLLs registered at the same time. The only way around this is to provide an equivalent method of exposing the DLL functions and using a manifest is the most reliable solution. Assemblies are associated with the .NET framework so are a separate topic altogether. The problem with isolation by manifest is that very old programs do not have their DLLs written in a way that can be isolated this way. However, most modern apps are written in a much better way (yes, even programmers are capable of learning new things) and isolation is not something I encounter as a requirement these days. One thing I would mention in respect of Windows Installer behaviour which is buried quite deep in the SDK, is that if you try and isolate a DLL to a non system folder and an identically named DLL is not present in the system32 folder, then windows installer will copy the isolated DLL to System32 and register it there. This can cause a problem if you later install an application that relies on a newer version of the DLL being registered in System32. Encountered this once at a client who wanted everything isolated, and in that scenario, the order of installation became critical.
Follow ramesh

4)

How to set a shortcut to install only on Windows7? any help

Markus Wehrle If you are using advertised shortcuts, it is required, that the shortcut is in same component as the file it refers to. One option would be to create 2 components with the same file and and create a shortcut for one of them. You can then place a condition on the components. VersionNT < 601 for OS lower win 7 and VersionNT >= 601 for win 7 and above or what ever condition you require for the shortcut.

Ed Tippelt If there is no requirement for a shortcut to be advertised, you can create a non advertised shortcut using a vbscript custom action with the appropriate condition based on VersionNT. If you do need an advertised shortcut, one other approach is to always install the shortcut but add a custom action to delete the shortcut if VersionNT<6.1, sequenced in deferred after the action that creates shortcuts.