Develop Reference

Why are some nuget package references required by applications?

I have a question that has been bothering me for awhile. I ran across this problem a few years back when I was dealing with writing a generic logging wrapper around some hosted provider instances using log4net.
The idea was simple enough, I wanted to write a logging and metrics that hid all the implementation in a separate visual studio project so when you wanted to add any telemetry support to another application you could just include the project, new up an instance of the logger and start logging using generic calls. If you ever switched providers or tweak logging settings, it wouldn't require any changes to the host applications.
This creates a strong decoupling point, where the main application used an interface in a logging class library, but would know nothing about the packages or providers that the logging class library was using to do the real work.
When I did this and tried out using Loggly's nuget package and log4net, I found that the calling application had to have a ref to the nuget package or else the dependent assembly would not be copied to the build directory. At the time I just wrote this off as something odd that they Loggly engineers were doing. But I have since encountered the same behavior in some, but not all other packages. (DogstatsD doesn't have a problem, Raygun does, etc..)
I have noticed that some nuget packages in assemblies are automatically copied into the parent output directory, but when I look for the setting that controls this, I cannot find it.
I have written dozens of class libraries over the years, and I have never had a problem with 'chained dependency assemblies (a refs b, b refs c, etc.) resolving when I build. It only seems to be some nuget packages that are a problem.
How do I force nuget packages referenced by a class library project to copy into the build directory without an explicit reference in the application?

Ok, I figured this one out.
This is a problem only for the Log4Net & Loggly wrapper assembly combo in particular because it is referenced entirely at runtime. Log4net loads up its required log appenders at runtime, and because .net doesn't see a ref to the assembly at build time, it assumes that it isn't being used and omits copying the required assembly to the bin directory. The solution when you know this is simple, just write an empty dummy method in the referenced library that you can call in the main application. This will cause .net to include the assembly in the build.
While this problem is specific to the Log4net library, it could occur anywhere that you are using an assembly that is only used with runtime reflection.

Library Structure Convention

According to Names of Assemblies and DLLs, your library should be named by the following convention: <Company>.<Component>.dll. The problem is when you library incorporate projects like WPF Effects (special project that provide the effect build action) or WPF Custom Controls. Should you break the convention and have DLLs as follows:
MyCompany.MyLibrary.dll
MyCompany.MyLibrary.MyEffects.dll
MyCompany.MyLibrary.MyCustomControls.dll
Is there a way of combining all the different projects into a single DLL?

As mentioned in comments, you might be happy with putting all the code into one project and just namespace it accordingly.
In case it is your requirement to have separate assemblies you can merge it using Microsoft's ILMerge or with opensource ILRepack.

How to pack referenced libraries into a new libarary

When creating a new library MyAPI.dll, I am referencing many other (non-standard) libraries such as RestSharp.dll, Newtonsoft.dll,MyUtilities.dll, etc. My library works fine in my development environment because I've downloaded all of those other libraries and they're sitting in my project's bin folder, but as soon as I try to publish that library and use it in a new location, it fails because the referenced libraries cannot be found.
How to I set up my MyAPI.csproj project so that these dlls/libraries get packaged into my published .dll file, and future users of MyAPI.dll don't have to worry about downloading and referencing those dependencies?
Thought this would be simple, but my google-fu is weak today. Setting those external references to CopyLocal = False removes them from the /bin/ directory, giving the illusion that they are getting packaged into MyAPU.dll, but really Visual Studio is just adding them to my Global Assembly Cache (GAC), which doesn't help future users of the API.

There are two options (as far as i know):
ILMerge
Embeded Resource and Assembly.Resolve (see Jeffrey Richter)
First you can use ILMerge, which is comamndline program that can merge multiple .NET assemblies together, creating one output file. It cant merge WPF projects. Can be added to postbuild events to make the merge automatic.
Second is adding library as embeded resource to your project, and then registering to Assembly.Resolve event and loading assembly when its needed from resources. Article from Jeffrey Richter about this method: Jeffrey Richter.
The second method has major drawback, it doesnt work with merging multiple libraries into one (it can only be used for adding libraries to executable), at least in c# without another tool. To add library to library you have to use another tool, which is mentioned in Jeffrey's article comments at second page: (Module initializer injection).The problem with embeding library into other library is that you cant (at least in c#) register to Assembly.Resolve event before the embeded library is needed, so you need to inject the registering to module initializer using the Module initializer injection. It can also be set as build event, which is written on the apge with the tool. It may sounds complicated, but once you set it up its easy.

There is a free nuget package "Costura.Fody" it packs dependency assemblies as resources into your assembly. The solution works with WPF and other managed assemblies.
If the dependency assemblies are not in the executing folder, the packed assemblies are taken automaitcally. It also configures your msbuild targets automatically for packing the dependencies during build. You do not have to add code in your assemblies.
It also lets you configure, which assemblies to pack or not in a xml file.
It uses a combination of two methos:
Jeffrey Richter's suggestion of using embedded resources as a method of merging assemblies.
Einar Egilsson's suggestion using cecil to create module initializers.
You can find documentation here: https://github.com/Fody/Costura/blob/master/README.md

It's not free (well there's a trial) but a friend of mine told me about a program called .NET Reactor, which has the ability to package an exe with dependent DLL's into a single executable, well worth a look.
I would say the next most straight-forward alternative would be ClickOnce, a good tutorial is here.

How do I add a reference to an assembly that wasn't built with the Silverlight Runtime?

I am looking for a possible solution where I can add ShapeMap.dll as a reference,
but when I try to add the reference I get an error stating:
You can't add reference to ShapeMap.dll, as it was not build against the Silverlight runtime. Silverlight projects will only work with Silverlight Assemblies"
What do I do now?

While Silverlight code may look and smell like good old .NET-backed logic, the runtime for Silverlight is different from that supporting regular .NET applications.
It is useful to think of the Silverlight runtime as a subset of the .NET runtime: Silverlight is meant to run in a "sandbox" whereby many the unsafe features such as direct access to the file system are not allowed.
For this reason, one can only add Silverlight assemblies to a Silverlight project.
The error you're getting is therefore as said: the version of ShapeMap.dll you have wasn't build for Silverlight runtime.
There are two ways out of this situation:
find or build a Silverlight-backed version of the DLL
somehow refactor the Silverlight application so that it leverages the features of the DLL by way of WebServices (if that makes sense, for the name ShapeMap.dll indicates that this may deal with UI objects which are hard/impossible to deal with remotely)
To get a Silverlight-backed version of the DLL:
First choice: It may just be that you can get the binary of the Silverlight version of the assembly where you found the .NET version.
Second choice: it may be that you can get the the source code of the [.NET targeting] DLL.
If so you can try -and I stress "TRY"- to make a Silverlight assembly out of it. The problem may be that the source code uses .NET-only idioms/API calls and you'll then need to convert these; several just .NET-to-SL "gotchas" can easily be converted, others are absolute roadblocks (eg. direct access to the file system, registry etc.), although, it may be possible to merely comment-out the offending sections of the code, if, somehow the Silverlight was not going to use the underlying features of the DLL.
Now... for sake of full disclosure...
there are a few techniques which allow "fooling" Visual Studio so that .NET assembly be accepted within a SilverLight project. See for example "Reusing .NET assemblies in Silverlight". Beware, however, that while very insightful as to the nature of the .NET and Silverlight runtimes, and possibly useful in some cases, these techniques are undocumented and, more importantly, depending on the subset of .NET API used by the DLL, may merely allow to get over over the build-time blocking, to fall into various run-time errors (when/if the application makes calls into the DLL to methods which in turn invoke .NET-only methods of the runtime).

If you have access to the source files for that assembly (dll), create a new Silverlight Class Library project and add all the existing source files to your new project. Then attempt to build the project. Depending on the amount of dependencies you may succeed in building a silverlight compatible version of the assembly.
If you don't have the source code, then sorry you're out of luck.

Silverlight works in a "subset" of the .net framework, some stuff is organized differently and works not like a regular WPF application (like that everything needs to be async in order to keep the UI responsive). You can see it as a "protected" .net environment, and therefor you may not reference or use non-silverlight dll's.
Like the previous answer states, use the source code and copy paste it into a SL library project, compile, and use that.

How to share libraries without using the GAC?

I have a library that is meant to be used by many websites. The way I am doing it now is in the library's properties, I set the "Post-build event command line" to: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite\bin\$(TargetFileName)"
Every time I want a new website to use the shared library, I add a new line like this: copy "$(TargetPath)" "$(SolutionDir)\MyWebsite2\bin\$(TargetFileName)"
Is there an easy or better way to do this besides using the GAC?

In my opinion your problem here is a lack of control about how this library is produced and used by other projects. If I were you (which I'm not :) I'd set about developing the library through a unit test co-project where new functionality can be developed and tested independently. Once that functionality has been implemented and tested to be working within your unit test parameters manually copy the assembly into a "library" folder of the web project that the required the extension of the library in the first place (this folder holds all your compiled assemblies used by that project).
Even better would be to maintain a version system in which you tag the new version of the library so as to keep track of the exact source revision that it's using.
The reason I suggest what may seem like a cumbersome methodology of working is that your current practice makes your existing websites quite brittle as a change made in the library for one site may in fact break one of the other sites... and as the amount of sites you have increases you can't be forever retro testing new versions of the shared library against the existing sites.
It's also for these reasons that I don't recommend using the GAC either.