You may consider an other addition to that...
I'm creating my libraries in a totally different solution (no as part of my main development solution) than create a local nuget package from the outcome and add it as reference - that handles me all the necessary dependencies an updates every time I update the util libraries...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
Similar to Eliyahu, I prefer a Utility library for such code. I'd write one file for each type which gets extended by an extension method (my way of code organisation). Similarly, other utility methods get grouped into files by their underlying business object.
First, one be sure that the shared code really should be shared. The fact that it seems like it is common functionality doesn't necessarily mean that it will remain that way. (Really a bad idea to start adding conditional logic to control different logic flows due to different applications.)
Second, how is the rest of the business applications structured. Primary if you have two applications X and Y that you want to use your common code M, do X and Y have their own delivery schedules or are they always delivered together. If they have their own deliver schedules then a common library MUST have its own delivery schedule as well. That is the only way to insure that X is using the version of M that it was developed with and Y is doing the same.
Third if different deliver schedules are needed then one must deal with different versioned apps, and if one must deal with git as the source control system then one has a problem since git only deals with that via different repositories.
There are additional issues depending on what language is being used and how applications are delivered.
I have a separate project in my solution that contains such code i.e. code that is shared across other parts of the application. This can then be distributed as a self contained assembly. If using .NET then you have the option of placing this assembly in the GAC where other applications can also use the same functionality.
We have probably all developed those Visual Studio applications which rely on additional DLLs and static libraries containing our favorite snippets of code. My question is how best to manage this kind of project which is not all neatly contained in the project folder. If we add our library paths (elsewhere on the disk) to the project then we can be sure that we are linking with the latest versions of the libraries but archiving this arrangement is a nightmare. Another alternative might be to copy all the libs to a 'lib' folder within the application that we are developing. This would provide a self-contained project which could easily be archived but we may not be using the latest version of our libs.
I would be very interested to hear what other developers do. Is there a better way!
but we may not be using the latest version of our libs.
However you will in fact be using the same one in development, QA and production. And be more likely to label it in source control so you can keep track of it.
Thus if a problem occurs in QA or production then you are more likely to be able to reproduce it. And when you do update to new versions as part of a development and business decision then development and QA can more fully verity that it continues to work as expected.
Application life cycle includes various steps involved to have the system ready for use. For example, waterfall method is one famous software life cycle which includes
There are similar life cycle steps for other systems/applications.