3 ms·

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

by mcs_ 10y ago

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.

jimmaswell 10y ago
.net libraries tend to be either self-sufficient or come with their dependencies, or otherwise have a readme saying what to run in nuget
- UK-AL 10y ago
  You normally list dependencies in the nuspec, which will download the dependencies for you.
  - jimmaswell 10y ago
    I find it a lot more convenient when everything is just vendored
    - UK-AL 10y ago
      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.
      - yareally 10y ago
        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.
        will_hughes 10y ago
        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).aspx https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110)....

by mcs_ 10y ago

jimmaswell 10y ago

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

UK-AL 10y ago
You normally list dependencies in the nuspec, which will download the dependencies for you.
- jimmaswell 10y ago
  I find it a lot more convenient when everything is just vendored
  - UK-AL 10y ago
    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.
    - yareally 10y ago
      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.
      - will_hughes 10y ago
        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).aspx https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110)....