Question

I primarily program in the WinForms environment and, among other things, very often use the TreeView control.

That being the case, I have a Utility class I developed which has a lot of my most common functions – Things such as converting a DataTable to a delimitted string that can be outputted to a text file, popping up a “Save-As” dialog and returning the filename the user chooses or returning a list of checked treenodes from a specified treeview, etc.

Given that I have this utility class, I am now trying to add it to an ASP.Net application and it is giving me a lot of obvious errors with, for example, TreeNode having different properties between WinForms and ASP.

Now, I know the first and most intelligent response to me would be to separate out all these different functions into separate utility files and libraries and add them as-is-needed / applicable to each application – I understand the benefits and logic of that, but my question is more about the theory of creating the class itself.

Is there a way to create a class that will include, for exmaple, WinForms objects and I could still add it to an ASP application without it erroring?
In other words, I won’t use those functions since they obviously won’t work for this architecture, but is there a way to stop the errors from appearing just because the objects appear wrong to this architecture and just have the compiler accept that file – Then I’ll just use the functions I know ARE appropriate for this architecture?

As a stupid example of a function in my Utility class that’s fine in winForms, but Errors in ASP:

Public Shared Function CreateTemporaryNode(ByVal NodeName As String) As TreeNode
    Dim TempNode As New TreeNode

    TempNode.Name = NodeName
    TempNode.Text = NodeName

    Return TempNode
End Function

In this case 'Name' is not a member of 'System.Web.UI.WebControls.TreeNode'

EDIT:
Just to clarify – I understand the bad programming practice on this specific situation. My question is more-so about trying to learn if there was a way to “hide” functions missing libraries from the compiler so a class could be used within multiple architectures without the need for adding in libraries for functions you won’t be using / needing.

I hope this question makes sense and thanks for your expertise.

Answer 1

The problem is in your utility class, based on the example you have shown, is that you aren’t explicitly telling the application which type you are referring to therefore it can only make the assumption that it’s the first one it finds. In other words, use fully qualified paths when declaring types so your utility functions can be more specific e.g.

Public Shared Function CreateTemporaryNode(ByVal NodeName As String) As System.Windows.Forms.TreeNode
    Dim TempNode as New System.Windows.Forms.TreeNode
    TempNode.Name = NodeName
    TempNode.Text = NodeName
    Return TempNode
End Function

However, this then highlights the other issue – as your utility class uses types from particular library it becomes dependant on it, as does any lib/application referencing your utility lib. The question you need to ask is, is it really worth it for the sake of a couple of utility methods?

Now, I know the first and most intelligent response to me would be to separate out all these different functions into separate utility files and libraries and add them as-is-needed / applicable to each application – I understand the benefits and logic of that

Then why go against it? As you can see there is no clean way of doing what you want, either way, you are going to be adding dependencies to libraries that are not required.

I see your code splitting up nicely into 3 separate utility libraries i.e.

• Utilities – References core types only
• Utilities.Web – References web-specific controls
• Utilities.WinForms – References forms-specific controls

If you are adamant you want to do it this way then there is always the possibility of using compiler directives e.g.

#if TARGET_WINFORMS

... // win form specific methods

#endif

#if TARGET_WEB

... // web specific methods

#endif

... // core methods

This would allow you to compile your utility to target a specific architecture, essentially stripping out any unnecessary code. It involves a little extra house-keeping but it would do the trick.