16

When I create a simple SharePoint 2013 project in Visual Studio 2012 and I want to deploy it, it deploys fine, but Dll is not in the Global Assembly Cache. In Advanced tab, I have added project assembly to be deployed.

enter image description here

In different test I set Assembly Deployment Target option to GlobalAssemblyCache, and Include Assembly In Package to True, and removed dll from package described in first scenario.

enter image description here

Project .NET FW version is 4.5. Machine is virtual machine 64bit, Windows Server 2008. I have tried also to change project's platform target to X64 and Any CPU without no luck.

I have tried to add dll manually using gacutil tool, and it is not deployed as well. Could it be something related to 4.5 framework? I can't also deploy manually any Dlls made in 4.5 but all other work.

Any ideas? Thanks.

gradosevic
  • 4,809
  • 2
  • 36
  • 51
  • 1
    You have overwhelming evidence that the way you check that it got stored in the GAC is wrong. Which you didn't mention. It is not in c:\windows\assembly anymore. – Hans Passant Oct 22 '12 at 11:02
  • Thanks for the response. I'm checking it in c:\windows\assembly, it should be there, right? I did test with two explorer windows, one shows GAC, other shows my DLLs. I can move to GAC only DLLs which are not made in .net 4.5. When moving .net 4.5 DLLs to GAC nothing happens. It looks like 4.5 DLLs cannot be installed to GAC for some reason. – gradosevic Oct 22 '12 at 12:43
  • +1 for the effort into the Q, lots of details, listing what you have tried etc. – Ryan Oct 23 '12 at 08:11
  • Hi could you tell me what happens when we set 'Include Assembly In Package' to 'True' AND remove the DLLs from the package, please? – variable Mar 13 '14 at 09:27

2 Answers2

36

I'm checking it in c:\windows\assembly, it should be there, right?

No, that's the directory for the GAC in .NET versions 1.0 through 3.5. It was moved in .NET 4.0 and up, now located in c:\windows\microsoft.net\assembly. You can browse that directory with Explorer, the shell extension handler that flattened the view of the GAC directories is no longer used. If the assembly doesn't contain any unmanaged code then start in the GAC_MSIL directory, you'll have few problems locating the actual file from there.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

I had this issue, and I think an IISReset fixed it?

I made changes to my event receiver. In the package, I added the assembly from Project output like you have. I set the "Include assembly in Package" to False on the Project properties.

I deployed, but my event receiver changes did not look like they were happening.

I ran an IIS Reset, and could then see my changes.