I've experienced inconsistent results. The global install of STSADM is
certainly broken. Just how broken is hard to define. Thus far I've had a
difficult time  defining the steps necessary to overcome the brokenness.
However, it is overcomable as I've done it many times. Just not
consistently.

For a while I thought the steps were to fully qualify the assembly in
the DWP and manually delete, redeploy, and reset IIS on each change to a
Web Part. However, that didn't work the last time I demoed it. Arrrrgh.

One of the problems with the global install for STSADM is where it references
the assembly from. You can look in the windows/assembly folder  to see which
assemblies are in the GAC, but this does not mean that the dlls  are actually
stored there - if you look at the properties for each one you can see where the
original CodeBase really resides. When you install a webpart by using the
global install of STSADM, it references the codepath to your local profile,
which for obvious reasons will not work for everyone -- It may work for you, but
then others try to use your webpart and it doesn't work. If you create  an
install file (.msi) you can then install the dll into the program files
directory (Microsoft's recommendation) and then when you install it to the GAC,
it should work better. (That is the setup of your purchased webparts)

Back to your original question... your virtual  folder should most likely be
created in the site  root (general recommendations made by others).

Thanks monty. If there is a problem  with stsadm tool, Is it ok to use
GACUTIL.exe to install the assemblies  on GAC?
I want to give the flexibility to the user whether they want to
install the webpart on GAC or BIN directory. Here I am
facing problem is after installing the webpart in GAC, suppose if I
uninstall the webpart and if I try to install the webpart
in BIN directory, its giving  problem. its(dlls) not removing from the
GAC other than the webpart dlls...(dependency dlls)

You can use GACUTIL or drag  the dll from the Program Files folder  to the
Assembly folder, and it will install and set the codebase to the program files
location. I'm not sure, but you may have to check that the applicaiton pool
account has access to the DLL (Program Files).. I haven't done it for a while,
so I don't remember if this was a requirement.

I have not found  a way to really clean webparts out of the system if they don't
uninstall properly.. I've gone and deleted them from the GAC, deleted the
resource folders, deleted them out of the web.config, but STSADM still says they
are installed. If anyone has a way of completely cleaning these left-overs out
of the system, please let us know.

As you said, stsadm.exe tool always keep the Codebase location for
assembly as Local_folder. which may not have permissions to others.
I thought I can follow the second approach which you have sent. How do
I add the permissions on those assemblies  when the dlls  are installed
on
program files\bin directory.

But I am not sure how do I check the following link which you have indicated.
"you may have to check that the applicaiton pool account has access to
the DLL (Program Files).. "

If you can provide me how do I check/add this permissions, that would
be really great!.

Did you also delete the Dashboard Web Part (dwp) file from the
wpcatalog?

Yes, deleted the dashboard webpart also from wpcatalog.