Is it a bad practice to include a large number of scripts as an embedded resource to a project?

Question

I'm designing a Visual Studio project that will use a potentially large number (up to ~300) of script files of various types. These files will not be shared with other projects, i.e. they are exclusive to the project. Is there any good argument against including all these files as an embedded resource (by setting their build action) and then using Assembly.GetManifestResourceStream() to retrieve them at run time? Or would this be a misuse of embedded resources, and a filesystem directory holding these resources as files should be used instead?

The benefits of using embedded resources appear to be:

• the produced assembly is easy to share and deploy (single file deployment without having to worry about missing script files or invalid paths);
• isolation and convenience: all the resources can be accessed from within the VS project.

The arguments against this approach are usually:

• you can't modify the resources without recompilation and redeployment of the assembly. However, even for a project with many text-based resources, the resulting assembly will be rather small and just as easy to redeploy as overwriting e.g. a single filesystem-located script file would be. And theoretically, it should be possible to replace just the changed part of the assembly (hence smaller update), but I'm not aware if any such existing diff/merge tools exist.
• The produced DLL will be larger, eventually perhaps significantly so; but then again, the total size of the program to deploy would be the same if you created a lean assembly without embedded resources, and deployed the resources separately to a directory.

Are there other considerations? More generally, is there a reason that project resources - regardless of what they are - should not be included as embedded resources, other than the required assembly recompilation in case of modification?

Answer 1

I can give you some insights from a complex environment perspective.

If your application is anywhere near critical or significant to your organisation and you need to minimize incident response time then it is of course better to have all scripts as separate files. Even though it might be very easy to recompile your assembly, in a structured corporate environment hotfix release usually requires number of hoops to jump through even in an emergency. Besides, this requires a dev person while support person should be good enough for changing a script file.

Other consideration could be if (at least some) scripts do not run properly when streamed from resources. They may need a place to write intermediate or result data. There might also be some dependencies between scripts (one calls another etc.)

One other factor is that having resources separate allows for quick review when you do not have access to project source. This adds some transparency to your application (which might be desired or not). It also might be useful to help determine what is happening with your application in case of problems and potentially make a quick change/fix (somewhat similar to my first point).

Generally I would say it depends on your requirements. If you need to be able to make frequent changes to your scripts (or other non-compilable resources) then having them separate is much better. If they don't change too often and you like to have neat, simple and compact file structure then embedding is a good choice.