Ben.Demystifier
Ben.Demystifier copied to clipboard
benaadams
Make it a source-only Nuget package
It means that my library, framework or component can take a dependency on your package without having to bother my consumers with another dependency. This blog post provides some of the rationale for that. If you want to see an example, see FluidCaching
I like the idea; include the code so any dependency changes you make in your app aren't blocked by the dependencies of a package. 👍
Was wondering how name collisions worked:
#if PUBLIC_FLUID_CACHING
public
#else
internal
#endif
So src package uses internal and library uses public?
This would be super useful if distributed as a single source file that could be dropped into any library or application. On a side note, I am the the author of the LightInject DI library and we have been providing source and binary packages for years now. source packages are internal types for the most part, binary package has public types.
btw, where is the code for this ? :)
https://github.com/damianh/LibLog by @damianh works similarly. It's just a single file which can be copy and pasted in, or included via nuget.
That said, Dapper was also a single source file, but moved away from that approach as the maintenance burden made that impossible.
In FluidCaching I decided to keep the files separate for easy editing and then "compiled" them together before I build the Nuget package.
The single file was to reduce the noise on the consumers solution explorer. That was the old nuget content package way.
With the new sdk package reference, the files are not copied directly in the cs proj folder. As such, I will break down the file for easier maintenance.
Difference between LibLog's and Dapper's needs is that LibLog becomes part of your library's API. It uses a namespace transform (.pp) file to achieve that. I don't think Dapper, FluidCaching nor this has the same need.
@benaadams Does the source for this exists somewhere? I'd love to take it for a spin :)
If it would help to see a very simple example of a source package, see https://github.com/adamralph/liteguard - it does do the .pp name transformation. However it also produces both source and binary packages, and until now, I haven't found a good way to generate the .pp from the .cs, given the platform-specific #ifs, so I simply hand crafted the .pp files from the .cs and committed them. The code is very small and almost never changes, so it's easy in this case.
@dennisdoomen do you have an example of how/where you'd use it; then I can expose it correctly...
Difference between LibLog's and Dapper's needs is that LibLog becomes part of your library's API. It uses a namespace transform (.pp) file to achieve that. I don't think Dapper, FluidCaching nor this has the same need.
I think you probably want a namespace transform regardless. Even if it's going to be internal only, you'd probably still want a single top level namespace in your assembly. LiteGuard.Source is internal and still has the pp namespace transform.
I just want to be able to add a nuget package that will add the files as .cs files to the project. I'd use it everywhere!
