If it has the same version number as the referenced DLL, the GAC gets used.
If you increment the version number, rebuild the website referencing the new version number, put the new version in the /bin directory, then that DLL will be used.
If you do not want to change the version number, you're pretty much out of luck.
When .NET loads strong named assemblies, first it tries to decide what version number to use. It does this via the reference first, then it looks for publisher policies, then it looks for binding redirects in the configuration file.
After it does this, it looks for the assembly in the GAC, then in any codebase specified, then it probes various file system folders for the DLL. If at any one of those steps it finds the right version assembly, it stops.
If you are not changing the version number of your strong named assembly, .NET will find the original one in the GAC and stop looking. Note that because it stops when it finds one, and because looking in the GAC is first, specifying a codebase for your assembly will do no good unless you also specify a new version number.
Essentially two things:
This allows SharePoint's full trust assemblies to make use of those operating under partial trust (yours).
- Write a custom Code Access Security file and add it to the web.config for the SharePoint web application.
Writing your own CAS file can be tricky and error prone if you want to do it properly. If you use a tool such as WSPBuilder it can create one automatically for you, which I strongly recommend. Otherwise, there's a written-by-hand guide here. A "cheat" method is to write a CAS file that fully trusts your assembly, but that's going against the point.
Note: Certain SP artifacts such as event handlers must be deployed to the GAC.
Best Answer
As usual with best practices, it depends on your situation. Putting the dll's into the GAC means that they must be strong named, and will get full trust. This makes it nice and simple to deploy, but there will be no Code Access Security (CAS) checks on the code at all, it will be fully trusted. Assemblies in the GAC can also be re-used on other sites on the server without the need to deploy multiple copies.
Deploying to bin means that you need to understand the CAS requirements for your webpart, and if you need to do something that is not allowed in the trust level set in web.config, you need to either elevate the trust level to full trust (not recommended), or create a custom trust level with the appropriate configuration. More details on this can be found here: http://msdn.microsoft.com/en-us/library/cc768613.aspx
Back to the question, for intranet sites, where there are no external access to the site, and the data the web part is working with is not sensitive (salaries for example), I would deploy to the GAC, in order to keep things simple.
For an application that will be accessible from the web, or an internal applicaiton handling sensitive data, I would generally go with bin deployment for security reasons.