Correct. I more often than not just deploy my shared libraries as a separate solution, and force the assumption that the references made in development persist to production. There could be some tricky ways to ensure it using a receiver, but I haven’t had the need to enforce it that heavily as of yet.

Generally, when using third party controls (DevExpress, Infragistics, etc.) this is the approach that I take.

I usually just dump all the third party crap into one solution, since rev cycles are spread thin and it kills all birds with one stone.

“Package and deploy the shared library mutually exclusive from any specific component. Developers are allowed to assume that they can reference that assembly locally during build phases and it will exist in later cycles regardless of where code is moved / deployed.”

Does the above mean you deploy the Shared Library as a solution. Then in solutions that use the shared library just assume it is deployed and available. Obviously resulting in exceptions if it isn’t?

Secondly is this the method you use for deploying third party code? E.g. throw there dll’s into a solution and assume they’ll be there for use in any future solution that needs them?

Lastly if yes to the above. Is a solution per component the best, or 1 shared solution that all 3rd party dll’s regardless of their component/supplier.

Thanks for your time and thoughts.