Does this finally allow reading string literals from files and include them into the binaries?
I've seen a Go project that was heavily using https://pkg.go.dev/embed for loading some template files, and got a bit jealous. Back in the days of .NET Framework it was common to compile file contents into resource files, but it was always quite cumbersome.
Then you can read that file from the assembly with:
assembly.GetManifestResourceStream
I'm not sure what's awkward about that, but it's nothing new.
Discoverability for this is in visual studio, if you go to file properties there's a drop-down where you choose between Content, EmbeddedResource, Ignore, etc.
That determines what happens in compile, whether it is copied to output directory, compiled into the binary, etc.
The Stream is awkward. It needs to be processed either once at startup or lazy on access, or every time it's used (allocations!). Also discovering multiple files is awkward.
Yes, you can. But it's a bit cumbersome. The API to read them is not really intuitive, they are only accessible as a Stream, so they need to be either read every time into a string (new allocation, slow), or you need a helper that reads them once and keeps them in memory. I think there are also a lot of gotchas around naming and listing them.
In modern code I don't see them that often anymore.
I see your point and I don't necessarily disagree but better API for embedded resources is just a couple of simple extension methods away. I wouldn't even bother adding an external package for it.
I've seen a Go project that was heavily using https://pkg.go.dev/embed for loading some template files, and got a bit jealous. Back in the days of .NET Framework it was common to compile file contents into resource files, but it was always quite cumbersome.