Stop my "Utility" from submitting bugs between different architectures
I primarily program in WinForms and, among other things, use the control very often TreeView
.
In this case, I have a Utility class that I have developed that has many of my most common functions. Things like converting the DataTable to a delimited string that can be output to a text file by pushing the "Save-As" dialog and returning the filename the user selects or returns a list of checked treenodes from the specified tree, etc.
Considering that I have this utility class, I am now trying to add it to my ASP.Net application and it gives me many obvious errors, for example with TreeNode
having different properties between WinForms and ASP.
Now I know that the first and most intelligent answer to me would be to split all these different functions into separate utility files and libraries and add them as needed / applicable to each application - I understand the benefits and logic from this, but mine the question has more to do with 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 the ASP application without error? In other words, I will not use these functions as they obviously will not work for this architecture, but is there a way to stop errors from occurring just because the objects turned out to be wrong for this architecture and just made the compiler accept this file - Then I just using the functions I know. Is it suitable for this architecture?
As a silly example of a function in my Utility class, working 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 bad programming practice in this particular situation. My question is more about trying to find out if there is a way to "hide" functions that are not in the library from the compiler, so that the class can be used in multiple architectures without having to add functions to the libraries that you will not use / need.
Hope this question makes sense and thanks for your experience.
source to share
The problem with your utility class, based on the example you gave, is that you do not explicitly specify the application you are accessing, so it can only make the assumption that this is the first thing it finds. In other words, use full paths when declaring types so that your utility functions can be more specific, eg.
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 highlights another problem: since your utility class uses types from a specific library, it becomes dependent on it, just like any lib / application that references your lib utility. The question you need to ask is, is it really worth it for the sake of a few useful methods?
Now I know that the first and most intelligent answer to me would be to split all these different functions into separate utility files and libraries and add them as needed / applicable to each application - I understand the benefits and logic from this
Then why go against it? As you can see, there is no clean way to do what you want, anyway, you are going to add dependencies to libraries that are not required.
I see your code breaks down well into 3 separate ie utility libraries
-
Utilities
- For basic link types only -
Utilities.Web
- Links to web controls -
Utilities.WinForms
- Links to form-specific controls
If you are adamant you want to do it this way, then there is always the option to use compiler directives for example.
#if TARGET_WINFORMS
... // win form specific methods
#endif
#if TARGET_WEB
... // web specific methods
#endif
... // core methods
This will allow you to compile your utility to target a specific architecture, essentially eliminating unnecessary code. It comes with a little extra home maintenance, but it would do the trick.
source to share
Copying the class file directly and using it will not work because the code in the class will not compile without references to dependent assemblies (WinForms).
Which should work, but this is the following:
- Create a separate project to hold the class. This project should have a link to webforms assemblies as well as winforms assemblies.
- Create a class for the main stuff.
- Create a class for the WinForms stuff.
- Create a class for web content.
This way you can add all your code in one assembly.
This works because if you don't use the WinForms class from your site, the dependent winform assemblies will not be loaded (which is what we need as they either cannot be loaded or are not needed in the running website).
source to share