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

Question

I am developing 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 a good argument against including all of these files in an embedded resource (by setting their assembly action) and then using Assembly.GetManifestResourceStream() to get them at runtime? Or would it be a misuse of the built-in resources, and instead use the file system directory containing these resources as files?

The benefits of using embedded resources are as follows:

• the created assembly is easy to split and expand (deploying a single file without having to worry about missing script files or invalid paths);
• isolation and convenience: all resources can be accessed from the VS project.

Arguments against this approach are usually:

• You cannot change resources without recompiling and re-distributing the assembly. However, even for a project with many text resources, the resulting assembly will be quite small and as easy to redeploy as rewriting, for example. the only script file will be. And, theoretically, it should be possible to replace only the changed part of the assembly (hence a smaller update), but I don't know if such existing diff / merge tools exist.
• The DLL produced will be larger, eventually, perhaps so significantly; but again, the total size of the deployed program will be the same if you created a lean assembly without built-in resources and deployed the resources separately in the directory.

Are there any other considerations? More generally, is there a reason that project resources - regardless of what they are - should not be included as built-in resources, except for the necessary recompilation of the assembly in case of modification?

Answer 1

I can give you some ideas in terms of a complex environment.

If your application is somewhere near critical or significant for your organization, and you need to minimize the response time to the incident, then, of course, it is better to have all the scripts as separate files. Although it can be very easy to recompile your build, a patch for a structured corporate environment usually requires a number of hoops to transition even in an emergency. Also, this requires dev, while the support person should be good enough to modify the script file.

Another consideration may be if (at least some) the scripts do not work properly when streaming from resources. They may need a place to record intermediate or resulting data. There may also be some dependencies between the scenarios (one calls the other, etc.)

Another factor is that sharing resources allows you to quickly see when you do not have access to the source of the project. This adds some transparency to your application (which may or may not be desirable). It may also be useful to help determine what happens to your application in case of problems, and perhaps make a quick change / fix (somewhat similar to my first point).

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

Answer 2

If this is a web project that you intend to use only on your own host, then it is better not to use it as an embedded resource, but as regular files. (you only need to install the project once, but it will be easy to make small updates)

If you want to create a dll that can be reused in other projects, then it is better to use the built-in resources - if you do some updating, you can update only one DLL in each project.