Distribute the libraries as a NuGet package about dsinternals HOT 4 CLOSED

Yes please! I pulled in the Replication libraries manually for now but yes a NuGet would be far nicer.

I understand the need for the PowerShell cmdlets but we wanted to "bake in" the DSInternals Replication library to our tool at a lower level.

from dsinternals.

OK, @nbevans. Then you could help me with these decisions:

1. How many packages to create? Should I pack all DSInternals.*.dll files into one package or split them into multiple packages?
2. Which framework(s) should I target? Do you think that 4.5.1 is sufficient?
3. Shall the package(s) be strong-name signed or not? When releasing the PowerShell module, I sign all my assemblies + the CryptSharp library, because the corresponding NuGet package is not signed. But as soon as I make it a dependency of the DSInternals package, I would not be able to sign it either. I have come up with these solutions:
   1. Distribute CryptSharp dll through the DSInternals package.
   2. Create and release yet another CryptSharp package, signed with my key.
   3. Persuade the author of CryptSharp to sign the package. This would of course be the ideal solution. I just wonder if you could try to contact him, as I currently have no time for that.

from dsinternals.

1. I would definitely split them since for example we only need the Replication library and it would be annoying if it had to pull in all the Esent dependencies and other stuff too.
2. I'm not 100% sure but 4.5.1 seems good enough to me.
3. I don't see value in signing the assemblies. It just causes the type of pain you've discovered :)

Thanks

from dsinternals.

Published, see NuGet Gallery! As it is my first experience with creating NuGet packages, I will be glad for any feedback.
I am already aware of a small bug: The DSInternals.Replication.Model assembly has to be manually added into References. I have already fixed it in the source code, but I do not want to do a new NuGet release yet.

from dsinternals.