Would like to see a "recipe" version

[wlscaudill]

I love this library and would like to see a recipe version to not require a package reference that is passed downstream. A recipe will install the CS file as content and compile the logic in while continuing to allow for updates and bug fixes to be distributed via NuGet.

I publish both a dll package and a recipe/cs package for one of my libraries Naos.WiRM(https://github.com/NaosProject/Naos.WinRM) if you would like to look an example of editing the file to support both.

I have created a wrapped version of this in a NuGet package already to allow for my using it while having this conversation; (https://www.myget.org/feed/naos-nuget/package/nuget/Naos.Recipes.ByteSize). I would rather have this published here for ease of getting updates.

Please let me know if this is something you would consider providing.

Thank you,
Lawson

[omar]

Hey Lawson,

This looks interesting. I think many people would benefit from a recipe. I'll look into this and add it to my to do list.

Thanks

[omar]

Hey Lawson,

I'm not sure when I'll get to this, but If you have something already, maybe you can open a PR and we can work on it together to build some momentum for this feature.

[wlscaudill]

Do you publish your packages by hand? If so then you just simply need another nuspec file (ByteSize.Recipe.nuspec let's say) with a new ID (ByteSize.Recipe) and in the file list you would specify a single file:

  <files>
    <file src="ByteSize.cs" target="content/45/.ByteSize.Recipe/ByteSize.cs" />
  </files>

Then pack and push that new package. NuGet will automatically put this in a folder (.ByteSize.Recipe) in Visual Studio and the period prefix is just to denote that it's not used or make the directory hidden if you have that enabled...

Feel free to message me if you have any issues or questions.

[sandrock]

IMO, your request looks like a hack of nuget principles. Is there a documentation somewhere that recommends this practice?

Can you also investigate Paket: GitHub dependencies? Then can you tell us why this "recipe"-thing is better than using Paket?

[julealgon]

IMO, your request looks like a hack of nuget principles. Is there a documentation somewhere that recommends this practice?

Thought exactly the same thing when I first saw this "recipe" thing. Where did that come from? Source should really not be distributed as content in .NET.

[wlscaudill]

I worked at Microsoft for many years and while I was at Windows Azure I was exposed to this pattern. There are multiple teams there that, to my knowledge, still use this strategy to share compile-in code. While it might be a mild 'hack' of NuGet, it is a very easy and reliable way of distributing and managing versions of code that either needs to be in-assembly for reflection purposes or is sufficiently stable and small that the value of an additional assembly reference is questionable.

…

On Tue, Jun 15, 2021 at 7:45 PM Juliano Leal Goncalves < ***@***.***> wrote: IMO, your request looks like a hack of nuget principles. Is there a documentation somewhere that recommends this practice? Thought exactly the same thing when I first saw this "recipe" thing. Where did that come from? Source should really not be distributed as content in .NET. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMVNET4ZSPJKLSD7SKFY63TS6NVHANCNFSM4CXLVEPA> .

[julealgon]

Thanks for clarifying @wlscaudill .

Still, this introduces so many complications though. What happens if you reference a file, and then try to update it from inside Visual Studio? This is like using a scaffolding mechanism, updating the results, and then running the scaffolding again on updates. What happens when you attempt to update the NuGet package?

It is such an outlandish concept to me... I assume it was used exclusively internally at Microsoft? I've never seen a "standard" package employ this approach. It seems like a way to "package a 'Shared Content' project type".

[wlscaudill]

I completely understand your points, this is a balance between functionality and complexity for sure... If you modify a file in the "recipes" directory then the logic will be out of sync with the package version, if you update a package after a modification it will prompt for an overwrite, otherwise the updates are transparent but will show up during commits in the diffs. This requires some amount of understanding for a convention based approach and certainly opens up space for issues when developers are not aware of the pattern. Here is an example of an external package that was used internally in Azure: https://github.com/jonsequitur/Its.Log/tree/master/Recipes. I'm not sure if it is still used internally as Jon moved on to the .NET console parsing grammar some time ago. It is definitely used only in specific circumstances like the example version sensing logic. I also make use of it for managing distribution of items like stylecop settings and code analysis rules in my project 'Naos' ( https://github.com/NaosProject/Naos.Build/tree/master/Analyzers). I have been using the pattern in the Naos project for many years now and while it is certainly unconventional I have found it to be a very workable solution for these niche problem spaces.

…

On Wed, Jun 16, 2021 at 12:01 AM Juliano Leal Goncalves < ***@***.***> wrote: Thanks for clarifying @wlscaudill <https://github.com/wlscaudill> . Still, this introduces so many complications though. What happens if you reference a file, and then try to update it from inside Visual Studio? This is like using a scaffolding mechanism, updating the results, and then running the scaffolding again on updates. What happens when you attempt to update the NuGet package? It is such an outlandish concept to me... I assume it was used exclusively internally at Microsoft? I've never seen a "standard" package employ this approach. It seems like a way to "package a 'Shared Content' project type". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMVNESDQ5EYGHP6QZUL723TS7LVRANCNFSM4CXLVEPA> .