CommonServiceLocator

This project has been relocated to GitHub. It is no longer owned by the patterns & practices team.  

Rated 4 Stars (out of 5) - There is no version history (list of changes )

Rated 4 Stars (out of 5) - There is no version history (list of changes )

Rated 1 Stars (out of 5) - There is no version history (list of changes )

Rated 1 Stars (out of 5) - There is no version history (list of changes )

Hi,could you please help me find out what are the exact sources corresponding to the content of the NuGet package 1.3.0?[https://www.nuget.org/packages/CommonServiceLocator/1.3.0](https://www.nuget.org/packages/CommonServiceLocator/1.3.0)I could not find it out in "Downloads" view, nor (with confidence) in "source code" history.Thanks.

Hi,could you please help me find out what are the exact sources corresponding to the content of the NuGet package 1.3.0?[https://www.nuget.org/packages/CommonServiceLocator/1.3.0](https://www.nuget.org/packages/CommonServiceLocator/1.3.0)I could not find it out in "Downloads" view, nor (with confidence) in "source code" history.Thanks.

@Bouldraak's comment is spot on, however, I would note that CSL makes it's possible to use DI containers whether or not the dependencies being placed in the container are DI aware, thus, there is no need to rely on coding conventions as @junglemole ... [More] notes "is first and foremost good design by itself". While it may be true that adopting DI coding conventions on every codebase is a good design decision, what we've seen over the last 30 years are systems which rarely make "good design first and foremost". Quite the contrary, we often see tightly coupled components that don't support composition, DI nor IoC but instead behave more like monolithic systems which only ever exist in a single configuration. [Less]

@Bouldraak's comment is spot on, however, I would note that CSL makes it's possible to use DI containers whether or not the dependencies being placed in the container are DI aware, thus, there is no need to rely on coding conventions as @junglemole ... [More] notes "is first and foremost good design by itself". While it may be true that adopting DI coding conventions on every codebase is a good design decision, what we've seen over the last 30 years are systems which rarely make "good design first and foremost". Quite the contrary, we often see tightly coupled components that don't support composition, DI nor IoC but instead behave more like monolithic systems which only ever exist in a single configuration. [Less]

Bouldraak's comment is spot on, however, I would note that CSL makes it's possible to use DI containers whether or not the dependencies being placed in the container are DI aware, thus, there is no need to rely on coding conventions as @junglemole ... [More] notes "is first and foremost good design by itself" (while that may be true, what we've seen over the last 30 years are systems which rarely make good design first and foremost. on the contrary, we often wish original authors had adopted interfaces and used a factor, or DI container and an IServiceLocator adapter.) [Less]