Correct (Best) DLL construction method RRS feed

  • Question

  • Hi

    I have made a few DLL's in the past but I'm not entirely sure they are made correctly. I don't have much experience at making DLL projects but what I did worked for its purpose. My question is, What is the best method for constructing a DLL?

    I need some particular variables to be public which I do like this:

    Public Shared sVar01 As String = String.Empty
    Public Shared bBol01 As Boolean = True
    Public Shared sVar02 As String = String.Empty
    Public Shared iInt01 As Integer = 0

    Am doing this correctly for a DLL or should I use property instead? I have seen some other examples where Public Shared Properties have been used.

    The purpose is to capture some values from my application and use them in some Private Functions.

    Is there a standard class template that I can refer to to fully understand the correct construction procedure?

    Appreciate any help :)


    Nacho is the derivative of Nigel "True fact!"

    Wednesday, January 18, 2017 10:18 AM

All replies

  • To create a DLL you simply add a new project to your Visual Studio solution of type "Class library" (or "Portable Class Library" if you intend your code to be used in a Windows phone or Xbox 360 app).

    Then you just add classes to your DLL project like you would any other .net application.

    In another application, you can then use the classes you defined in your DLL (the public ones anyway) simply by adding a reference (Right-click on References in the Solution Explorer and click Add reference; then you can pick out your DLL project). Once you've done that you can just use the classes you created in your DLL like any other .Net class.

    Wednesday, January 18, 2017 10:26 AM
  • Hi

    Thanks for the reply. I already reference my DLL like how you have described. My question was really about whether I am constructing it correctly. Should I be using Properties instead of / as well as Public variables. Do I need to dispose the object once I have used it or do I keep the object until my application closes? Do I need to use NameSpaces in my DLL?



    Nacho is the derivative of Nigel "True fact!"

    Wednesday, January 18, 2017 10:31 AM
  • There really isn't any difference to how you use a class from a DLL than you do from any other kind of project or application.

    So, if you want shared/static variables then it's generally considered better to use properties rather than directly access fields.

    You only need to dispose of an object if it implements IDisposable (as per normal). Otherwise just leave it up to the .Net garbage collector to do its job.

    And you should organise your classes into suitable namespaces as per usual.

    Wednesday, January 18, 2017 10:49 AM
  • Hi

    Ok, appreciate your advice :)

    I will look up the correct info for Namespacing. Ive only ever done it once for a DAL & BLL class project I was working on. I wasn't entirely sure the reasons for the Namespacing if I'm honest.



    Nacho is the derivative of Nigel "True fact!"

    Wednesday, January 18, 2017 10:58 AM
  • The word "namespace" is actually used in slightly different ways in different environments, so I'm hoping we're talking about the same thing!

    This is what I'm thinking of.

    As the page link says, a namespace is a way of organising and grouping your classes. It also helps to avoid naming conflicts. For example, you may want to create an Email class but an Email class may already exist somewhere - as long as these classes are defined within different namespaces then there'll be no problem.

    Just consider the .Net framework. It has a System namespace containing all the really essential things such as the base types (int, String etc). Then you have the System.Net namespace containing a bunch of network related classes; a System.IO namespace containing IO related classes such as File and Path etc. And so on.

    How you organisation your own namespaces and classes is up to you, but typically you will create a top-level namespace just using your company name, then use sub-namespaces to group your classes according to logical use.

    For example, put all your data-access related classes into a <Your company>.DataAccess namespace, put all your business logic-related classes into a <Your company>.Business namespace, and so on.

    Wednesday, January 18, 2017 11:06 AM
  • Hi

    Yes we are talking about the same thing. In the case of my DAL, BLL, I understand now. For example:

    Both BLL & DAL have the same function name inside called EcoMaterialByCategory. The Namespace helps define this by



    Thus allowing my to understand that both functions are related. See my example below:


    Namespace EcoDev.BLL
        Public Class EcoMaterialByCategory
    #Region "Globals"
            Dim ED_DAL As EcoDev.DAL.EcoMaterialByCategory = New EcoDev.DAL.EcoMaterialByCategory
    #End Region
    #Region "Methods"
            Public Function selectMaterialByCategory(ByVal eco_material_id As Integer) As List(Of EcoDev.BLL.EcoMaterialByCategory_details)
                selectMaterialByCategory = ED_DAL.selectMaterialByCategory(eco_material_id)
            End Function
    #End Region
        End Class
        Public Class EcoMaterialByCategory_details
    #Region "Properties"
            Public Property eco_material As String = String.Empty
            Public Property related_material_finish As Integer = 0
            Public Property mat_density As Integer = 0
    #End Region
    #Region "Constructors"
            Public Sub New()
            End Sub
            Public Sub New(ByVal Eco_Material As String, ByVal Related_Material_Finish As Integer, ByVal mat_Density As Integer)
                Me.eco_material = Eco_Material
                Me.related_material_finish = Related_Material_Finish
                Me.mat_density = Mat_Density
            End Sub
    #End Region
        End Class
    End Namespace


    Namespace EcoDev.DAL
        Public Class EcoMaterialByCategory
    #Region "Globals"
            Dim ED_Conn As ClassConn = New ClassConn
            Dim conn As SqlConnection = ED_Conn.GetConnection()
    #End Region
    #Region "Methods"
            Public Function selectMaterialByCategory(ByVal material_category_id As Integer) As List(Of EcoDev.BLL.EcoMaterialByCategory_details)
                selectMaterialByCategory = New List(Of EcoDev.BLL.EcoMaterialByCategory_details)
                Dim cmd As New SqlCommand("dbo.usp_tbl_MaterialSelectByCategoryID", conn)
                cmd.CommandType = CommandType.StoredProcedure
                cmd.Parameters.Add(New SqlParameter("@MaterialCategoryID", material_category_id))
                    Dim reader As SqlDataReader = cmd.ExecuteReader()
                    selectMaterialByCategory = convertMaterialByCategory(reader)
                Catch ex As Exception
                    'Do Some Error Handling Here...
                    If (conn.State = ConnectionState.Open) Then
                    End If
                End Try
            End Function
    #End Region
    #Region "Helpers"
            Protected Function convertMaterialByCategory(ByVal reader As SqlDataReader) As List(Of EcoDev.BLL.EcoMaterialByCategory_details)
                convertMaterialByCategory = New List(Of EcoDev.BLL.EcoMaterialByCategory_details)
                If reader.HasRows Then
                    While reader.Read
                        convertMaterialByCategory.Add(New EcoDev.BLL.EcoMaterialByCategory_details(reader("EcoMaterial").ToString(), _
                                                                                              CInt(reader("RelatedMaterialFinish")), _
                    End While
                End If
            End Function
    #End Region
        End Class
    End Namespace

    Both classes are named the same and have the same function names but are organised by namespace.

    Although I did these classes, I started off with a bit of code examples and built from there. I understand Namespaces now that you have made it clearer.

    Thanks :)


    Nacho is the derivative of Nigel &amp;amp;amp;quot;True fact!&amp;amp;amp;quot;

    Wednesday, January 18, 2017 11:18 AM
  • Hi Nacho,

    Sorry for my late reply.

    >>Both classes are named the same and have the same function names but are organized by namespace.

    No, there are not same. Because they are in different library project respectively.

    Here is what I created A three-tier architecture. BAL referenced DAL's library.

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Monday, January 23, 2017 8:33 AM