1

I have inherited a project which deploys a "common" assemlby (DLL) to the GAC. In the Setup project, the Properties window of the Primary output from Common specifies the Folder property as Global Assembly cache.

However, when I navigate to the GAC in Windows Explorer, I cannot find any trace of that assembly.

I have to assume it is there, because it contains the DAL and the database is being hit.

In the project itself, I note that in the AssemblyInfo.cs file, the following lines are commented out: [assembly: AssemblyKeyFile("")] and [assembly: AssemblyKeyName("")]

But on the signing tab, there is a key specified and the Sign the Assembly checkbox is checked.

I just want to understand why it is not listed in the GAC (via the shfusion.dll - viewer). I have fixed a few bugs and would like the confidence that the updated dll was deployed to the GAC without having to manually do so.

[edit] I finally found that dll in the GAC and using Decompiler, have ascertained that it does not include my changes. I guess this means the installer does not work and I need to manually install it.

Cheers

onefootswill
  • 3,707
  • 6
  • 47
  • 101
  • Are you looking in the right GAC? There's more then one these days. One thing to try is drop to DOS and go to %WINDIR%\Assembly and do a dir /s yourassembly.dll and see if you get any hits. – Christopher Painter Nov 08 '12 at 22:10
  • @ChristopherPainter Thanks Christopher. I managed to find the Common dll in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Common\v4.0...[really big number] I achieved my goal by incrementing the AssemblyVersion (as distinct from the AssembyFileVersion) by 1. I went back and checked and confirmed that after deployment, the new DLL has been installed. Incrementing the AssembyFileVersion was not enough to force the dll to be replaced using the msi. Thanks. – onefootswill Nov 08 '12 at 22:54
  • 2
    There must be something wrong with your installer because if you update the AssemblyFileVersion then it should get updated in the GAC. This has to be done carefully because you must ensure that the new assembly is 100% compatible with the old one. This is what .NET Framework Service Packs do. They update core base class libraries such as System.Windows.Forms with the same strong name contract as the original so that applications will use the updated versions. Changing the AssemblyVersion is defining a new side by side unique version and should go into a component with a new GUID. – Christopher Painter Nov 09 '12 at 02:02
  • @ChristopherPainter Thanks. There was a problem with the installer. I have it now sucessfully installing the fresh dll with the AssemblyFileVersion incremented accordingly. – onefootswill Nov 09 '12 at 04:34
  • 1
    You're welcome. Post the explanation of what was wrong with the installer as an answer. :) – Christopher Painter Nov 09 '12 at 12:14
  • @onefootswill Yes, post the problem you had in installer with explanation on the fix as the answer. It may be useful to others. – Alexey Ivanov Nov 11 '12 at 10:18
  • @AlexeyIvanov Truth be told, I'm not 100% sure what was wrong with the msi. In order for me to get it working, I had to manually remove and re-add the Project outputs of the 3 projects which were being deployed with the 1 msi. There were 3 separate projects, each using individual config files and referencing the one Common dll. When I first incremented the FileAssemblyVersion, as far as I am aware, it should have deployed the updated dll. The only value the FileAssemblyVersion added was to let me know that the old dll was still in the GAC. So, I guess the fix was manually re-adding the dll. – onefootswill Nov 11 '12 at 22:10

3 Answers3

1

Have a look at this here, it will show you how to properly install in the GAC.
The example code is using WIX.

Community
  • 1
  • 1
CheGueVerra
  • 7,849
  • 4
  • 37
  • 49
1

Adding a DLL to GAC can be easily done with Installshield tool, to do this it is only needed to add a component and making a feature associate to the component and change the destination field to [GlobalAssemblyCache]YourComponyName. The only important notice to remember is that your DLL must have a "strong name" to avoid conflict naming with other DLL in GAC.

Matrix Buster
  • 299
  • 3
  • 9
-1

Just closing off this thread because the discussion in the comments of the original question covers everything off.

onefootswill
  • 3,707
  • 6
  • 47
  • 101