4

When working on a VS2005 project that involves referencing Microsoft.SharePoint.dll, building the project causes Microsoft.SharePoint.Search.dll to be copied to my bin folder. Why is this? Okay, maybe it's just a bug, but I want to know the mechanism.

[Edit: Copy local is most definitely turned off -- Microsoft.SharePoint.dll is not copied. Microsoft.SharePoint.Search.dll is not in the GAC but it wouldn't matter if it was.]

Hafthor
  • 16,358
  • 9
  • 56
  • 65

8 Answers8

3
  • It's not in the GAC
  • It's being used by one of the Assemblies you reference (i think Microsoft.Sharepoint.dll references it)
  • Since you don't reference it, you cannot set Local Copy to FALSE as far as I know
  • I've changed my build/deployment scripts to just delete it.
Michael Stum
  • 177,530
  • 117
  • 400
  • 535
  • That's strange that you got down voted when your answer is the closest to what's happening. I've upvoted it but I want to understand why this happens. It can't just be the referenced referencing causing the copy... this hasn't happened elsewhere AFAIK. – Hafthor Oct 13 '08 at 21:36
1

What worked for me is to

  • add reference to Microsoft.SharePoint and Microsoft.SharePoint.Search (even if you don't need it)
  • set Copy Local to false for both references.

When you build the project none of them gets copied to debug/release/whatever directory.

  • sorry that took so long - it does work - accepting, although I'd still like to know why this is happening. Shrug. – Hafthor Jul 07 '09 at 18:27
0

Did you try turning off 'Copy Local' in the properties for the reference to Microsoft.SharePoint.dll ?

Kev
  • 118,037
  • 53
  • 300
  • 385
0

may be because it is not in GAC, because other files which are in GAC are not copied there.

TheVillageIdiot
  • 40,053
  • 20
  • 133
  • 188
0

Its probably a dependency, and you have copy local enabled.

I'd keep copy local enabled though, as it really eases deployment pains.

FlySwat
  • 172,459
  • 74
  • 246
  • 311
  • I don't agree that copy local is a good move for MS assemblies. What if a hotfix has been deployed to the server and your solution is referencing (and copying) an unpatched version? Mayhem! – Alex Angas Oct 14 '08 at 13:48
0

If you machine (host) where you are compiling an assembly that is a x64 architecture and you have the x64 version of SharePoint installed (with the references set to those assemblies) during "add reference" it will set Copy local to false.

So, if the assembly is AMD64 and you have "Any CPU" set, then the "add reference" set's the copy local = true, regardless. If you change it to false, but you then reference this project from another that also has it's target set to Any CPU or NOT x64, then the reference get's copied through as well.

Take a look a custominzing the MSBuild as needed in this link: How do I override CopyLocal (Private) setting for references in .NET from MSBUILD

Community
  • 1
  • 1
Shawn Cicoria
  • 594
  • 8
  • 14
0

Ok, I just wanted to add to the answer with this explanation:

1) In my project, I had references to: Microsoft.SharePoint Microsoft.SharePoint.Publishing

2) On an x64 virtual moss 2007 server when I compiled my project, I got the following files added to my bin/debug: ssocli.dll, Microsoft.SharePoint.Portal.SingleSignon.dll, Microsoft.SharePoint.Search.dll, Microsoft.SharePoint.Search.xml, Microsoft.Office.Server.Search.dll.

Interestingly, I did not have this issue on my x86 virtual server.

3) All these files can be found in the c:\program files\Common Files\Microsoft Shared\Web Server Extensions\bin\ISAPI.

4) According to an answer I found on a MSDN forum, the referenced dlls probably reference or depend on the additional dlls. Because of this, they are added to the bin/debug folder.

5) To prevent this from happening, you can reference the dependent dlls in your project and set copy local to false.

https://social.msdn.microsoft.com/Forums/sharepoint/en-US/192fa94c-b588-401d-8ca8-845c3fe15f60/could-not-load-file-or-assembly-microsoftsharepointsearch-version12000-cultureneutral?forum=sharepointdevelopmentlegacy

AdamantineWolverine
  • 2,131
  • 1
  • 17
  • 14
0

One of our customers experienced this problem and it appeared to be due to the Office Developers Tools for Visual Studio option available at the Individual Components section of the Visual Studio 2019 installation wizard, e.g.

enter image description here

The solution is to uncheck it and to uninstall the addon. Therefore, the SharePoint related assemblies should not be added to the project when compiling it.

I hope that this information might be of help to somebody.

Rumen Jekov
  • 1,665
  • 2
  • 17
  • 19