如何防止在辅助类中引用的未使用的 dll 被复制到项目中？

Question

I have this class library called 'Helpers' where I put some re-usable code in. Most of this code is used in most of my projects and usually there are no special requirements.

A while back I had some re-usable SharePoint code that required me to add a reference.

using Microsoft.SharePoint.Client;
namespace Helpers
{
    public static class SharePoint
    {
        public static List<ListItem> GetItems(List list, CamlQuery query = null)
        {...}
    }
}

Every class has it's own file but resides in the same namespace 'Helpers'. Only this SharePoint class has the 'using Microsoft.SharePoint.Client'

A project that references my Helper library now holds Microsoft.SharePoint.Client.dll.

Even when this class is seperated into another namespace, it's copied. There is a Copy Local switch on the reference but this will prevent the dll to be copied even when used.

Is there a simple way to prevent this dll to be copied locally when not used and copied locally when used?

Answer 1

When you create a library you have to think of it as a public API. That library has no idea what functions/classes that are in it are going to be used by the calling library or not. In your case, it sounds like both the library and the caller are in the same solution so you're thought is "why can't it check what functions I'm using?" Well that's incredibly difficult, if not impossible to do (I'm leaning toward impossible). Why? What if I have a program that is a console application that asks the user "what function do you want me to execute?" The user types the name "Helpers.SharePoint.GetItems({"a","b","c"}, null)"

Then through some rather complex parsing and Reflection, you call this method. How would Visual Studio know that at compile time? It wouldn't have a clue since it's 100% user driven. It's an obscure example for sure, but it's an example of why the compiler has no idea whether or not you might need that library.

As a result, it's going to copy it for you since it can't know for sure what is needed and what isn't. It believes it's needed because you told it it was when the reference was added.

If you want the dll to be removed, you can create a post build step to manually delete it after doing a build, but Visual Studio isn't going to do it for you and that's a good thing. Personally, I'd say just let the dll exist. The only harm is disk space and the maybe 500KB that dll takes up is pretty much of no importance in the world of 2TB hard drives!