Hacker News Reader

Hacker News

Comment by mcs_ | Hacker News Reader

Full thread

mcs_

probably an "awesome" collection should contains some more attributes. You look at the list, click a link and:

- no test are available,

- no dependencies are specified (in .net world today ...)

- no licence

- no type (API, lib, bin)

of course some (maybe many) of those projects contains that information, but the lack of these attributes, makes the list not suitable for the research of an ideal component to include into a project.

View on HN

.net libraries tend to be either self-sufficient or come with their dependencies, or otherwise have a readme saying what to run in nuget

You normally list dependencies in the nuspec, which will download the dependencies for you.

I find it a lot more convenient when everything is just vendored

There's no such thing as just vendored. If you include a 3rd party library in a nuget package, and the developer using that package also includes that 3rd party library. It can cause problems.

One example of that I have run into at work is mismatched versions of json.net in dependencies. It becomes a mess when you realize one requires an older/newer version and you don't have the source to modify it or will take some time to have the developer of the dependency update their project.

So long as the newest version of the assembly is backwards compatible with the previous ones (i.e has same interfaces, etc) - then this is easily solved using Assembly binding redirection[1] in your .config file.

eg I have JSON.NET 8.0 installed, and a library I'm requires an earlier version then this will do the trick:

      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
      </dependentAssembly>

Nuget takes care of this for you automatically.

[1] https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110)....

Reply on news.ycombinator.com