sade055

It is very easy and simle to create a device driver based application from Installshield. I am using Installshield 2012. You need to make sure that the driver is a signed driver. If the driver is not signed, then you need to sign the driver first. It is good to have your driver signed, but you can install and unsigned driver as well. Check an option later. Go to Installshield Wizard in Installation Designer and click on Project button on top an then Device Driver wizard. Click Next -> Select the path to your .inf file on your machine. Choose the system architecture. I am choosing x64 as I am packaging for 64 bit machines. Click Next-> Next-> Select the options as per your requirement. I have chosen the above ones. Click Next-> Click Next-> You will get the summary and then click on Finish. It will add the settings in your component of INF file. Hope this helps you create device driver easily with Installshield.

Many times while running a script/application exe from a network we get an error that the application is not from a trusted source and if we want to install the particular application or not. This error comes because the source is not digitally signed and the Operating System prompts to ask from user if it is a known source to user or if something malicious is being run from network. This is just to protect the end users from the malicious software or Virus attack. Technically, This behavior was introduced in Windows XP SP2 because of the addition of the Attachment Execution Services (AES). Every program that is run by using the ShellExecute() API passes through AES. AES considers the downloaded update file to be from the Internet Zone. Therefore, AESdisplays the Open File - Security Warning dialog box. AES examines the file to see whether the file has a file stream of the type Zone.Identifier. Then AES determines what zone the file is from and what level of protection to apply when th...

Windows XP/Windows 7 works under a locked down environment in most organisations. The MSI authors generally have to provide permissions to the installation directory, so that the users without admin rights are able to access and write data into the installation directory. When you set permissions, you are specifying what level of access the user has to the folder and its files and what users can do within that folder such as save, delete, or read files. If you would like to know how to set permissions through Powershell Script, then I would recommend you to read my new blog entry here: http://msiworld.blogspot.com/2012/01/my-first-powershell-script.html There are six standard permission types which apply to files and folders in Windows XP/Windows 7: Full Control Modify Read & Execute List Folder Contents Read Write Each level represents a different set of actions users can perform. See the table below for more information. For folders you can also set your own unique permission...

Self Heal and Repair are two different concepts in Windows Installer which people many times consider to be the same thing, however there is difference in these two. Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application. When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature , if any of the key paths is missing it will launch Repair. Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched. Repair of an MSI can be triggered by Repair button in Add/Remove programs Giving the command line msiexec /f{other option} {MSI name} Self Heal by advertised shortcut or other advertising information. Active setup Once the repair of the package is triggered, even with Self Heal, then the whole of the MSI is reinstalled. Then it does not see tha...

Generally you would have read that after isolation is done, we should not modify the MSI. So how to do .local and .manifest in the same MSI. Actually you would be thinking: "What is the need to do both types in the same MSI?" This is because, recently, I came across a situation in which we needed to do isolation of a file for installation of application in Windows 2000 through .local method and for installation in Windows XP and Vista through .manifest method. This was needed to be done through same MSI. This is the solution. Create a .msi file with .local isolation method for windows 2000. Then create another .msi file with .manifest isolation. Note the visual difference of .manifest isolation file and the base MSI. Make all the differences seen in this to the .msi which was created with .local isolation. Then compile it. This will not get corrupted. Only the ones with .manifest isolation if recompiled again get corrupted. So take care of this and you can then conditionalize...

Exclusion List • Manual Checks: Exclude (delete) any unwanted files and folders. Some common file extensions that should usually be excluded are listed below. If the resource you are deleting is a keypath (indicated by the key symbol) you must ensure the related component has been assigned a new keypath. If the component is now empty it can be deleted. Common Items: HKEY_USER_SELECTABLE\Software\Shortcuts Event log registries. All VCache Entries Shutdown Entries Uninstall Entries Your Username if Captured *.log-app specific services / hosts – These must be handled appropriately Folders/ Files referring to Wise Folders/ Files referring to InstallShield Any cookies Any file from the dependency applications that has got captured must be excluded. Cache Temp Tmp Bag Log – Examine in notepad to see if they are relevant or not. • Files *.REG files _isreg32.dll setup.exe install.log install.exe install.ini unwise.exe Uninstall.xml Upgrade.exe Update.exe uninstall.cif uninstall.cfg / uninstall...