Home/ Questions/Q 8543327
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T12:16:31+00:00

I have quite a bit of code that I find myself using over and

  • 0

I have quite a bit of code that I find myself using over and over again in various applications. I recently decided to take the time to get them all organized in one location so I can reference them from any of my solutions. I started with a Class Library project and added a bunch of different functions and some derived controls that I use. Some of the functions are used by the derived controls as well as being called directly from applications. I built the project and started using the DLL in my projects.

I have a few questions regarding this custom DLL (I am using Visual C# 2010 Express):

  1. The first thing I noticed is that it doesn’t seem to work quite like the stock Microsoft libraries. For instance, I can have “using System.Windows.Controls;” in a program, but I can only reference the namespace of my custom library with the using directive. It would be nice to organize my classes in a similar fashion if it makes sense to do so. Is it possible to have the classes nested like the Microsoft ones?

edit: For example… If I type at the top of my application code “using System.”, I get a bunch of sub-namespaces to choose from. I continue typing “Windows.”, and I get more sub-categories. If I add a reference to MyCustom.dll and start typing “using MyCustom.”, I don’t see any of my classes or subclasses. I’m just asking how to organize things within my class library so they behave like the stock libraries.

  1. Is it a good idea to make one big DLL file with all of my reusable code? I don’t have a ton of code at the moment, but I want to leave room for expansion. What is the best practice for this?

  2. How do I deal with my DLL when I make an installer for my applications? I normally use InnoSetup to make my installers.

  3. Here is my main concern… Say I use a function from my custom DLL in Application1 and someone installs it. I later add some features or make a change to that function for Application2 that I am building. If the new features break Application1 or change something in an undesirable way, what happens when a user installs Application2? Is my custom DLL shared between the applications or does each application have its own version of my DLL? Obviously, I would build a new version of Application1 to make it work with the new DLL, but there is no guarantee that the user would update it.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1) You can have your code nested in its own sub-namespaces so-to-speak, by changing the namespace in the class file from: SomeNamespace, to: SomeNamespace.SubNamespace. Incidentally, if you do “Add -> New -> Folder” to your project in the solution explorer of Visual Studio, VS will automatically use your “nested” namespace when you do “Add -> New -> Class”, which will be the name of the folder you added. So if your original namespace is: MyDLLProject, and you add a folder to the project named: HelpfulStuff, then when you add a new class file to that folder, you will see the namespace is now “MyDLLProject.HelpfulStuff”, and consequently, you will need to reference it in your code that way, either by fully specifying it, or by including a “using MyDLLProject.HelpfulStuff” at the top of any class file that needs to use the code contained therein.

    2) Wrapping any and all RE-USEABLE code into a DLL is certainly a good practice, as it is then easily used in other projects, and will only ever have to be changed once, if a change is required, no matter how many projects use it. If however, you can be fairly certain you will never use the code anywhere else, it may not be worth the time and effort.

    3) InnoSetup should automatically include any assemblies (.NET DLL’s) that are referenced by your project. you can see what DLL’s are referenced, and add references from the “References” node in the project tree, in the solution explorer of VS. This is where you will need to add a reference to your own DLL, should you choose to make one.

    4) Unless you actually go through the trouble of making your DLL a shared component by having it registered in the GAC (Global Assembly Cache), you will not need to worry about this. Your application will always have its own copy of the DLL’s it uses, and will not step on each others toes in the way you are imagining.

    • 0