How to deploy a dll that is constantly changing?

Question

I have created several small applications that use my own DLL. The problem is that this DLL is constantly changing. My current solution to this problem is that I have an installation project in a class library solution that creates and registers a DLL. In all my applications, I need to open the solution and re-reference the newly created / registered DLL. Then I need to recompile my installation projects, uninstall the old applications, and then install the new application again.

There must be a better way, and I'm just not sure, because I'm pretty new to this. I looked in ClickOnce, but I don’t think this will solve my problem as I cannot publish the class library. I looked at the version numbers, but I have to do something wrong, because it does not work either.

I understand that as soon as a DLL is created and used in an application, it should essentially not be touched. I do not have such an opportunity in this situation. It is constantly updated. Done.

So is there a better way? It would be useful to evaluate the item in the direction of the manual or related question / answer / forum.

Change The DLL does not constantly change at run time, but is constantly evolving to provide more functionality and detail in other applications. Also, one big thing, I think I should have mentioned, is that the public interface is constantly alternating - usually adding new methods.

Answer 1

Make sure the links to your DLL indicate SpecificVersion = false. Then just deploy each new version to the GAC, and this should do the trick. In the end, you can also manually force versions using Redirect bindings .

Answer 2

The solution you can try is to use a single solution for your project and refer to the project wherever it is needed.

Answer 3

Check out NuGet

You can create an internal Nuget repository (this is actually just the folder where nupkg files are stored). Then, when you create a new DLL, you can update applications as needed in the studio. This would ensure the availability of the latest version. They do not need to be reinstalled unless DLL errors are detected.

Answer 4

One solution:

• Physically separate the interface from the implementation. for example, AssemblyA is an interface, an application (AssemblyB say) only knows the interface at compile time. The implementation (AssemblyC) also knows / references AssemblyA, of course. The fact is that AssemblyB does not refer to AssemblyC. This will require you to use an IoC container (for example, MS Unity 2.0, but there are many others) to allow and instantiate your concrete at runtime.
• Write an update process that finds the new AssemblyC.dll, replaces the local copy, and uses reflection along with IoCContainer to “load” the new implementation at any desired time, usually launching the application.

The above depends on the stability of your interface. If not, you can write a (more) stable Facade .