nuget

[jeremysimmons]

I'm interested in using this project, but would like a nuget package. would you accept a pull request for a nuget package?

[FrozenCow]

Yes! A PR is very much appreciated.

[ronnieoverby]

Ditto

[jeremysimmons]

epic fail. I can't believe I never took you up on the offer for this @FrozenCow

[FrozenCow]

@jeremysimmons No problem, PRs are appreviated any and all times! ;)

I've just updated the project a bit to work correctly with VS2015. I've also removed the original References directory and used nuget to retrieve external dependencies (zip/7zip dependencies). That should make things a bit nicer.

I have little experience (none to be exact) with publishing Nuget packages to nuget.org, but I could give it a go. Let me know if you want to package it or if you have any suggestions for packaging?

[binki]

I’ll try creating a PR for creating nuget packages. Some of my thoughts on this:

1. Please be sure to stick to semver as it is an accepted best practice. Each release has to have a new version to be accepted by the nuget website. When coming up with a version number for a new release, apply the first matching rule:

   1. When releasing a new version of the nuget package which would break ABI (require programs to be recompiled) or change behavior in ways which require developers to rework their code, be sure to bump the MAJOR number and reset MINOR and PATCH to 0 before publishing to nuget.
   2. When adding new features which keep the ABI backward compatible, bump MINOR and reset PATCH to 0.
   3. When releasing only bugfixes which don’t require changing the ABI and should be compatible with any program using your library, just bump PATCH.

   For example, if you add a new member to the IFileSystem interface (which would break any existing libraries which provide IFileSystem implementations), this would match the first rule. If your current nuget version number is 1.2.3, you’d bump MAJOR and reset MINOR and PATCH resulting in 2.0.0. But if you were just fixing a bug that people are unlikely to encounter, you would hit the last rule and end up with version 1.2.4 as your next nuget version.

2. Never change AssemblyVersion unless you have a very good reason to. Nobody wants to deal with updating their references. Instead people use nuget itself to manage package versions. I think the only time it would make sense to update AssemblyVersion would be if you bump the MAJOR and you want to support people who want to use both the old and new version of your assembly at the same time in a single program… which is not likely something anyone wants to support.
3. I think it’d make most sense to have a separate nuget package for each publishable assembly you provide. Many people will want to be able to get just IFileSystem, PhysicalFileSystem, and MemoryFileSystem and not want the overhead of having 7-zip and its dependencies. You already put that archive support in a separate assembly because it is logically distinct from the core functionality provided by the SharpFileSystem and it is an example of how others might provide extensions to SharpFileSystem. So you will have 4 nuget packages: SharpFileSystem, SharpFileSystem.Resources, SharpFileSystem.SevenZip, and SharpFileSystem.ZipLib. And they will all be set up with dependencies on SharpFileSystem as appropriate. Of course, SharpFileSystem.Tests is meant for development of the sharpfilesystem project itself and shouldn’t become a nuget package.
4. When you finish creating and publishing the nuget packages, please put links in your README.md. This way you can endorse the packages as being official, making it much easier for developers to trust the packages and reduce the amount of time they waste on overhead/red tape type ;-). If you can create a nuget account matching your github user name that’d probably be good too ;-).

I’ll try to write up a PR with proper .nuspecs now… if I am ever unresponsive, I am on Twitter as ohnobinki and might be more responsive there ;-).

[binki]

See #6

[bobvanderlinden]

The project is now on Nuget. See https://www.nuget.org/packages?q=sharpfilesystem @binki's PR is used as the base for building the packages and AppVeyor is used to actually build and deploy the packages.