When you create an InstallScript project, and even before you have added files to the project, a default component will be created, and it's Shared property will be set to No.  When you create a Basic MSI project, there are no components created by default, so you have to add at least one file (let's say an executable) to the project in order for a component to be created.  When you add this assembly to the project, InstallShield will ask you if you want to scan for dependencies.  If you say "No to all", then a component will be created for the assembly, and it's Shared property will be set to Yes, by default.

In both types of projects, the Shared property of a component is looked at in the same way.  If it is set to Yes, and that component is installed on the user's system, then a reference count will be created in the registry, if it does not already exist, and then incremented.  Actually, the installer will increment an existing reference count, no matter whether the Shared property is set to Yes or not.  If no reference count exists, the installer will only create one if you set the Shared property to Yes.  So, what does all this mean?

Well, you need to at least be aware of it.  The problem I see is if the Shared property of a component is set to Yes, and yet no sharing is being done, then you will sometimes have a registry entry left behind during an uninstallation (the reference count), when you actually want the entry to be removed.  If you have done a lot of installing and uninstalling, the reference count might not be accurate, and left behind during an uninstall, and thus cause you to have the component's file left behind on the user's system.

Just be aware of this, especially in Basic MSI projects, where the assembly component is set to Yes by default.