.net如何明智地使用.dll？

Question

In my current .net projects I am using various .dlls files, some externaly written and some created by me. Now I am asking myself , what are the best practises to handle different .dll files over different solutions and projects and get them working with SVN so that they are available to use among different developers.

Okay, so I am asking about some general hints for:

• Should I bind the .dll Project into the different Solutions by source, or just directly by its release.dll?

• How can I prevent people getting the files by SVN to rebind the dll source (global assembly issues etc.)

• Is it good to use as much .dlls as possible (divide them by functionality), or using one big .dll, to get an easier overview?

Please don't be too hard, I am a beginner in this business and english is not my native language.

Thank you in advance, Harry.

Answer 1

The thing about DLLs in .NET is that they aren't at all like DLLs in pre .NET windows programming. They are just containers for code.

I read a good article a couple of years ago that explained this too me, as it once confused me too - it was, I believe, written by one of the MS patterns and practices people, talking about the relationships between namespaces, assemblies, projects and solutions (if i find it I'll post the link).

For source control purposes, I think you are better off storing the code, and letting it compile on the machine of the end users. Putting the compiled DLLs into source control is usually something you do for 3rd party dependencies.

This is all just from my experience - some experts may have better advice.

Answer 2

I would suggest setting up own NuGet feeds that contain your external dlls. You can setup NUGet feed just as a shared folder (no installation required). Those feeds will be internal in your organization and you have full control over upgrades.

Multiple projects can share the same dlls by using the same NuGet package.

http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Answer 3

I think using dll's in your application isn't a question that can be answered with yes it is good or no it is not good, since it depends on why are which dll's you are using.

So if you are using 3rd parties dll's in your solution already I think putting your code instead of the dll's you are creating will be the best practice here so that you don't have many dll's and your compiler won't have references for many dll's as well.

Answer 4

I think 3 layers architecture is good practice.

GUI.dll
Business.dll
DataAccess.dll

I prefer project references instead of DLL references, because you reference the Debug dll in debug configuration and the Release dll in Release configuration.

Answer 5

Generally you should divide your code into different assemblies if there are a good reason to do it like....

• You are using the code of the assembly in different projects
• You want to seperate your data from the GUI
• The DLL is updated many times and to keep it simple you want to update just a small part of it

There are many reasons to put code into dll's instead putting it in one big project. But you should not create to many dll's if there are no reason to do it ( I've seen some ppl creating one dll for each namespace and they contained not so many classes and there have been no reason to split them ).

Of course splitting code into dll's can cause some problems like you have a class in dll a and a class in dll b and each of them need a reference to another. This is mostly a design issue of the application.