idletekz · January 23, 2018 17:00
diff --git a/gac b/gac
 https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q123550_.htm

 https://social.msdn.microsoft.com/Forums/en-US/78f31e59-0250-438b-a9d2-3a4cd6440198/why-cant-we-add-reference-an-assembly-from-gac-created-by-the-user?forum=csharplanguage

 The significance of the GAC and shared assemblies exists only at deployment time, not at build time.

 Suppose you are developing a solution that contains two executables - for example, a Windows service and a client console application.  Both of these executables rely on a library assembly.  You ship this product to a customer and decide not to use GAC deployment, but you put these two executables in different locations on the drive.  Since the shared library is used by both executables it would need to sit along side both of your executables for each to work, which means you'd have two copies of the assembly.

 Now suppose you find a bug in your shared library and you need to issue a hotfix.  Now you need to instruct your customer to copy your hotfix in two locations instead of one.

 And then there's versioning.  The GAC allows you to put mulitple versions of the same assembly in one "location" - C:\windows\assembly, which in reality is a complex directory structure that is visible if you use a command prompt and the dir command.  You can't put two versions of the same assembly in a physical folder on a hard disk because the files would have the same names.

 The GAC is meant to solve these problems.  The GAC has nothing to do with how you build the actual software (sans the software's setup, which may choose to install to the GAC).

 The reason that you can't add a reference to a file in the GAC directly is a choice the Studio developers made and it's a good one.

 You're adding your own assembly to the GAC and then wondering why you can't reference it from there.  But why should you?  You are building the assembly.  The preferred way to establish a reference would be a project reference.  If A relies on B, then B should be in the same solution as A and A should add a project reference to B.  This is ideal since every time you build A, you're also guaranteed to have the latest-greatest version of B.

 

 If, for some reason you can't do that, then you should be adding a DLL reference to B's output location.  This is significantly less ideal for a lot of reasons that I won't go into here, but one of them is the fact that since B is in its own solution you will need to remember to open that solution first and build B to make sure that the assembly exists so that A will compile.

 Now suppose Studio allowed you to add assembly references in the GAC.  Now, not only would you need to remember to build B, you'd also need to remember to put it in the GAC.  You can do this as part of a post build step, sure - but that does not immunize you from a pretty big issue.

 Since B is a component that is built separately from A, let's envision this scenario.  A adds a reference to B in the GAC.  Remember, for an assembly to be in a GAC it is identified by its name and its version.  So A adds a reference to B, version 1.0.  Then some developer decides to change B's version to 2.0.  If you look at your GAC, you'll see an entry for B 1.0 and another one for B 2.0.  But A still references B 1.0, which is probably not what you want.  It might be, but it probably isn't.

 The sheer amount of confusion and frustration this would cause is enormous.  The Studio devs could allow you to do it, but you'd see dozens of threads on these forums complaining about how one project "isn't getting the changes" from another one, and when the dust settles on those threads it would turn out to be the exact scenario I just described.

 Allowing GAC references is just a bad idea.  Once in a blue moon you need to reference a 3rd party assembly and the only place they put their assembles is in the GAC.  That is frustrating because you need to extract the assembly out of the GAC manually (with the command prompt).  However, this is rare, and it's really just a flaw in the 3rd party' s deployment job.  If they intend (or don't prevent) someone from using their assemblies as a component (like an SDK), then they should provide a copy of any assembly they put in the GAC specifically for that purpose.

 But this is never a problem for assemblies that you build yourself.
	https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q123550_.htm

	https://social.msdn.microsoft.com/Forums/en-US/78f31e59-0250-438b-a9d2-3a4cd6440198/why-cant-we-add-reference-an-assembly-from-gac-created-by-the-user?forum=csharplanguage

	The significance of the GAC and shared assemblies exists only at deployment time, not at build time.

	Suppose you are developing a solution that contains two executables - for example, a Windows service and a client console application. Both of these executables rely on a library assembly. You ship this product to a customer and decide not to use GAC deployment, but you put these two executables in different locations on the drive. Since the shared library is used by both executables it would need to sit along side both of your executables for each to work, which means you'd have two copies of the assembly.

	Now suppose you find a bug in your shared library and you need to issue a hotfix. Now you need to instruct your customer to copy your hotfix in two locations instead of one.

	And then there's versioning. The GAC allows you to put mulitple versions of the same assembly in one "location" - C:\windows\assembly, which in reality is a complex directory structure that is visible if you use a command prompt and the dir command. You can't put two versions of the same assembly in a physical folder on a hard disk because the files would have the same names.

	The GAC is meant to solve these problems. The GAC has nothing to do with how you build the actual software (sans the software's setup, which may choose to install to the GAC).

	The reason that you can't add a reference to a file in the GAC directly is a choice the Studio developers made and it's a good one.

	You're adding your own assembly to the GAC and then wondering why you can't reference it from there. But why should you? You are building the assembly. The preferred way to establish a reference would be a project reference. If A relies on B, then B should be in the same solution as A and A should add a project reference to B. This is ideal since every time you build A, you're also guaranteed to have the latest-greatest version of B.



	If, for some reason you can't do that, then you should be adding a DLL reference to B's output location. This is significantly less ideal for a lot of reasons that I won't go into here, but one of them is the fact that since B is in its own solution you will need to remember to open that solution first and build B to make sure that the assembly exists so that A will compile.

	Now suppose Studio allowed you to add assembly references in the GAC. Now, not only would you need to remember to build B, you'd also need to remember to put it in the GAC. You can do this as part of a post build step, sure - but that does not immunize you from a pretty big issue.

	Since B is a component that is built separately from A, let's envision this scenario. A adds a reference to B in the GAC. Remember, for an assembly to be in a GAC it is identified by its name and its version. So A adds a reference to B, version 1.0. Then some developer decides to change B's version to 2.0. If you look at your GAC, you'll see an entry for B 1.0 and another one for B 2.0. But A still references B 1.0, which is probably not what you want. It might be, but it probably isn't.

	The sheer amount of confusion and frustration this would cause is enormous. The Studio devs could allow you to do it, but you'd see dozens of threads on these forums complaining about how one project "isn't getting the changes" from another one, and when the dust settles on those threads it would turn out to be the exact scenario I just described.

	Allowing GAC references is just a bad idea. Once in a blue moon you need to reference a 3rd party assembly and the only place they put their assembles is in the GAC. That is frustrating because you need to extract the assembly out of the GAC manually (with the command prompt). However, this is rare, and it's really just a flaw in the 3rd party' s deployment job. If they intend (or don't prevent) someone from using their assemblies as a component (like an SDK), then they should provide a copy of any assembly they put in the GAC specifically for that purpose.

	But this is never a problem for assemblies that you build yourself.