Adding dependency as DLL or adding as a project


We have an application written in mvc.

Now we have written common db context & entities module (2 projects/class library) which are required by this application. Same db context and entities would also be required /part of another application.

Now my question is how to add this common project to our applications.

Should we add it as a dll or should be add them as separate projects in each solution referencing the common project. Any pros cons of above approach. Or if there is a better approach to handle this.

Thanks Jas

Show source
|   | c#   |   | .net   |   2017-11-29 19:11 3 Answers

Answers to Adding dependency as DLL or adding as a project ( 3 )

  1. 2017-11-29 19:11

    Rather go with a separate project within the same solution, or at worst you could create a NuGet module with some custom registrations that you need to add to each project as you need.

    Currently what I do in my own project is something like this.


    ...where data is common to API & ServiceWorkers and then have our super generic modules that are also distributed (internally) via Nuget for re-use (but make sure they're able to function as isolated pieces)... to re-iterate as @masosn's comment suggested, don't just use the draw dll if you can avoid it.

  2. 2017-11-29 19:11

    It depends largely on how these applications are expected to grow together. How likely are you to make a change in your data application that will break the consuming code in your other applications? If this is likely to happen frequently, I'd keep all these projects in the same Solution and Repository, and use Project references. This makes refactoring much easier, since Visual Studio will be aware of all the usages of a given class or member in all of your down-stream dependencies.

    However, if the data layer is pretty well hardened at this point, and you may need to have the different applications deployed using different versions of it (which I find unlikely) then you should deploy your Data project as a Nuget package. That way, each application can specify which version it knows about, and can make sure it's always compatible with the version that it specifies.

    I agree with the other commenters/answerers, that you should not create a dependency on the DLL directly. That's a really old-school way of managing things that doesn't scale well with newer version control technologies.

  3. 2017-11-29 20:11

    Ideally you'd want to reference a library project, not a DLL. You may keep all the projects in the same solution or use a private nuget repo like the others have mentioned.

    However sharing a DbContext is not a good idea, because once you have a new migration all the projects using the shared DbContext will have to be redeployed. It's also not a good idea because you don't want multiple projects to be responsible for the data in your datastore.

    Though this might require some restructuring, you might want to look into microservice architecture. Each microservice would be responsible for its datastore alone.

Leave a reply to - Adding dependency as DLL or adding as a project

◀ Go back