Click here to Skip to main content
15,867,594 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
I have a 3rd party client library which encompasses 2 DLL's.
I have two applications that I am creating , with a business object library.

One application is a service which communicates with a specific industrial device requiring the 3rd party libraries. My service and my application will both require these libraries - which in themselves need some finessing to make them easier to work with (instead of writing 20 or 30 lines of code I would like to be able to write one or 2) - so this means I have implemented a library [kind of like a wrapper but not really] to enable me to do this - so it references the 3rd party dlls - I am trying to not have to reference these dlls in my other two applications - and simply have those two reference the BizObjects and the "wrapper" - I am thinking this will make my code easier to follow and also easier to maintain. I would like to know if this is a sound pattern to follow , something normal or wrong, what is the best practice here since both applications will require the same kinds of access with these 3rd party libraries?
Any helpful insights and especially real world experiential knowledge will be greatly appreciated .. I am not a C# expert and it is not what I do full time , I would say I am somewhere around a rusty intermediate level programmer.
Posted

1 solution

First of all, you don't reference DLL's, you only reference assemblies. Do you think there is no difference? There is… An assembly usually has one module, which can be .DLL, .EXE (you can freely reference an assembly by an .EXE module — did you know that? in some cases, rather exotic ones, it even makes big practical sense; and this is not a trick) or anything else. But this is not necessarily so. .NET allows multiple modules per assembly, and, physically, only one of those modules has an assembly manifest. At the same time, the same module can be reused in more than one assembly. This is supported by compiler's command line, but not directly by Visual Studio. Let's set it aside. Here, it's only important that you reference assemblies, not modules. And the use of the module by an assembly is similar to referencing, but is something different.

Now, you should understand that the boundaries between assemblies are not very strong. Your types and dependencies between them are more important. So, start with the design of your code with main classes, and, when you come to something, you can change distribution of types between assemblies. If you make some mistake, you can relatively easily move one class from one assembly to another. In worst case, you will have to change some internal access specifiers to public, and visa versa. All other access specifiers remains the same. When you look at my past answer referenced below, pay special attention for my words in bold.

Now, I recommend to divide your code primarily not by "topics" (networking, UI, and so on), but first, by layers. These principles are explained here: How Do I Divide My Code Appropriately?.

See also my notes on more advanced kinds of architectures, with plug-ins: Projects and DLL's: How to keep them managable?.

Finally, one practical advice: merge your output directories to one, separately per configuration. It can be done automatically:
Manage output Files and Folders (Debug/release) in VS C#.,
VB.net. Bring all files over with referenced .NET dlls files when compiling..

—SA
 
Share this answer
 
v3
Comments
Sascha Lefèvre 7-Apr-15 20:56pm    
My 5!
Sergey Alexandrovich Kryukov 7-Apr-15 21:09pm    
Thank you, Sascha.
—SA
stixoffire 8-Apr-15 10:00am    
Reference an exe (just found that out) because I could get toolbox items from an executable. Since I had only one assembly file in the solution I thought that was it, assembly just said something about the dll [guess my understanding was short]. Wouldn't have a clue as to how to build a library with multiple assemblies- will research that one just to learn. Some things are not clear to me, perhaps what I wrote is not entirely accurate, so when I add to studio a reference I look for the dll to add - I am referencing an assembly with in it (this is where my question was in regards - but you bring up a lot of topics which I thank you for. Now I do understand in the using statements (imports in VB) I am referencing those namespaces.
As for moving classes around - I am not sure I understand - I do not want to have the same class in every project as I would need to make changes in each project that used that class in order to maintain it - so I wanted to place it in a library where I would have one place to maintain. I wish in my programming classes they taught these concepts but they did not (they taught methods, classes and a bit of how to and that was it), my law classes taught 4 basic questions regarding legal cases and did that repetitively until your thought process was in those terms.. I think I will need to put what you wrote in some kind of format that I can ask myself until my thought process for code writing lines up with that format.
Sergey Alexandrovich Kryukov 8-Apr-15 10:30am    
Your considerations about referencing assemblies or DLLs are not clear. If I explained something unclear, you can ask me some follow-up questions. You are right, you "look for DLL to add", but this is due to different ways of naming the assembly. In the command-line syntax, the referenced either by strong name or by DLL which is the DLL (more exactly, module), which carries assembly manifest. If you reference it by strong name, it should be in GAC. Otherwise assembly is allowed no even to have such name, and — understand it — if you only have set of DLLs, before you reference is and start compiling, the name is unknown, even if it exist.

But picture this: compare "referencing assembly" and "referencing assembly by the name of the module which has assembly manifest". "By". In all cases, you are referencing assembly, not referencing a module. And please read about strong names and GAC.

Now, you certainly did not get a point about moving classes around. What "same class". You never use same class, you can reuse everything. I am simply talking in different phases in your development: you put some classes in some assemblies. Later on, you decided that is was not the best solution and want to change the division of classes between assemblies. Is it hard to do or not? No, it is so easy that you don't have to think too much when you make a decision: it is not the most critical. Is it clear now?

Note that all my discussions were mainly about one single software product. If you produce several assemblies, they inevitably reuse some assemblies, first of all, common definitions such as interfaces, but in practice a lot more. I did not discuss much the re-use of assemblies in different products. This is the place where you might think about placing commonly used code in GAC. But there are other approaches. Main thing is: how to uninstall this stuff cleanly? If you have concerns with that, it could be a matter of a separate question, perhaps...

—SA
stixoffire 8-Apr-15 11:23am    
I must do more reading on strong names and GAC - now the GAC and strong names finally makes some sense! Reading your other post on separating classes by topics and by layers, I somewhat understand what you are saying and that helps ALOT! (thanks); the Layers well some things are obvious, others are not so obvious (I will make mistakes for sure). Since the 3rd party dlls are used by several vendors it is possible the wrong dlls could be in GAC, so if I create my own SN assembly with the 3rd party dlls [https://msdn.microsoft.com/en-us/library/s1sx4kfb%28v=vs.110%29.aspx] this should work work and keep me from having an issue with another 3rd party product being installed and changing dll's - I was thinking simply to place them in a single folder called lib in my installation and trying to force the reference locally to lib.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month


CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900