Why reference DLLs stored in EXE
I am having problems with the DLL being copied to the exe folder referencing it. As far as I understand, the reason I have to make a DLL is to use reusable code. Thus, if I create a DLL that is referenced by 25 applications (thus using "reusable code"), then when I need to add change functionality to the DLL (say by updating something that happens behind the scenes) I need to go open and recompile all 25 applications to make sure they get the new functionality.
In a specific example, I have a DLL responsible for creating printable work order forms. The form and appearance of the work order form have changed, but none of the information contained has changed. In this case, I only need to make some changes to the code for creating the base form, but no changes in the implementation of this code (the same methods and properties are used). I would not have thought that I would need to rebuild the DLL and then rebuild every application that references it, but it seems to be the case. If I don't rebuild, then the applications continue to use the old version of the DLL.
Is there a way to get around this? Am I thinking about it wrong? Should I be doing something else? Am I just completely misunderstanding the whole thing? Thanks for any help you can provide.
source to share
Is there a way to get around this?
Yes - install the library in the global assembly cache (GAC) . This method can be used by many applications.
Read How Runtime Locates Assemblies to better understand how links are loaded. The practical reason that DLL files should be deployed from EXE is to enable "XCOPY deployment". In addition, it allows you to create "dropdown" libraries from NuGet and other sources that can be added without "installing" them. Bolt-on app extensions are also much simpler as they can be simply copied and the app can dynamically load add-ons without having to register anything.
A lot of this stems from the pain in the COM world where every DLL has to be registered, and if you had multiple versions that were not compatible, you ended up in "DLL Hell" .. NET relaxed those rules by allowing the deployment of versions with the executable but still providing a mechanism (GAC) for sharing common assemblies.
You also read Simplifying Deployment and Solving DLL Hells with the .NET Framework for more information on how .NET uses assemblies to resolve versioning issues
In your case, it is possible to just copy the DLL into all new applications, but there are certain factors that can prevent it:
- If the assembly is signed
- If your app requires a specific build version
- and etc.
source to share
DLLs serve several purposes. One of the theoretical goals is to allow multiple processes to share the same DLL. And in fact, if you install a DLL in the GAC, it might allow .NET to actually load the DLL once in memory (i.e. multiple processes running at the same time using the same DLL do not force each get your own copy of the DLL in memory, as is the case with other DLLs).
But the other purpose is just for code reuse. In this case, the main DLL function should serve as a redistributable repository for some specific functionality. It doesn't matter that multiple processes can use the same DLL copy. Instead, it is only important that multiple processes have a convenient way to reuse functionality in the DLL.
Also note that changes to the DLL may or may not be helpful. Of course, everyone always hopes that the newer version of the DLL will be better. But changes in the code always mean the possibility of adding new errors to the code. A program that has been thoroughly tested with a given DLL version may or may not remain reliable when used with a newer version of the same DLL.
A newer version of a DLL is usually offered mainly for adding functionality. Of course, some bugs can be fixed along the way, but then again, if the program has been tested with an older version and is currently working, the new bug fixes are probably not critical. At the same time, a program written with an older version probably won't have a practical way to use the new features.
Disk space is cheap, and memory is almost as cheap. And giving each program its own copy ensures unexpected changes to the new version of the DLL that interferes with the program that was only tested with the older version.
Finally, note that even with the GAC, multiple DLL versions can be installed. Therefore, if the DLL meets the necessary requirements, it is possible to significantly reduce the problems with DLL versions.
source to share
It looks like you have a build automation issue (or lack thereof). If you have all your code in one container (TFS, GIT, etc.), then there is no reason why you cannot add all projects to one build solution and distribute the code that way. This way you just go in and recompile the main solution and the files go into all applications.
Another option is to use a shared bin folder and bring all projects into that main directory and execute them from there. This would require recompiling the DLL and other applications will pick it up right away.
The third option should be that at the stage of creating the DLL project, a post-builder is created that copies the file to all specified directories. I would not recommend this approach as it would be a maintenance nightmare.
None of this takes into account how you consume / deploy your applications and how many users / environments you have to take into account.
source to share
One of the less discussed benefits of using DLLs is that they help you structure your code.
Dividing the product into DLLs gives the developers of each component more control over accessibility since you now have public, private, and internal scopes. So, for example, you can have a tightly coupled set of classes in one DLL, preventing code in other DLLs from abusing interfaces that allow fat linking.
Dividing the product into DLLs also forces you to think about ordering when creating dependencies between components.
Of course, you can just be diligent and disciplined in keeping the layers at your high level of design, but nothing beats a build break to tell you when you've added a dependency that shouldn't be there. There are, of course, ways to do that, but dividing a project into DLLs and building them consistently forces you to be very explicit about adding dependencies that don't follow a simple layered model.
And if you plan on making your product extensible with third party plugins, it is often helpful to have a single DLL that defines the interface between the application and its plugins. This makes it easier for plugin developers to know what is / isn't in the supported API. And the same techniques can be useful even if you're just using the extensibility model to organize code developed by a large team (or set of teams) at the same company.
source to share