I have built a .NET Assembly and have registered it to the GAC I find it in
"C:\Windows\Microsoft.NET\assembly\GAC_MSIL" after it is installed with the MSI installer.
Now on my development computer when I build a project which uses this Assembly what reference should I be using. I know if the Assembly is registered then it takes precedence so on my development machine it is not registered. I use a simple path to the the BIN folder of the Assemblies project.
But my question is: can this then cause problems or even slow things down later when my main project (that references this .dll) is deployed and of course the path I was using is no longer valid?
I know that the Assembly is still found in the GAC, but Im interested to know if this can lead to problems.
The GAC is a deployment detail. It nice for a company like Microsoft so they can reliably deploy security and maintenance updates for .NET Framework assemblies and be sure that there are no stray copies of the assemblies in a folder somewhere that they can never find back and update.
Using the GAC yourself on the dev machine often leads to tears. It is just way too easy to make an update to your source code and completely forget to change the [AssemblyVersion] or to re-register the updated assembly. Which causes your program to load the stale DLL that doesn't have the changes, you'll lose an hour of your life trying to figure out why the changes don't appear to work.
The reference assemblies of a project should never be an assembly in the GAC, always a copy that you keep around somewhere. Either generated by building a project (the very common case) or checked-in to source control. Just like the .NET reference assemblies, its copies are located in c:\program files\reference assemblies.
Even on the user's machine you should think twice about using the GAC. DLL Hell is always an issue that should worry programmers. If you have two programs that both use a single DLL in the GAC then it is pretty easy to deploy a bug fix for the DLL that fixes an issue in one program but plays havoc on the other program. A problem you don't have when you use local deployment, putting a copy of the DLL into the same directory as the EXE.
Maybe you have the same update concerns as Microsoft has, the GAC certainly is useful to reliably find a DLL back. That however isn't very common. Local deployment should almost always be your first choice.