Best practices for common routines
-
What is the best practice for placing general-purpose routines which will be widely used? To date, I've tended to simply have a ModGlue.vb file in each project, where I throw any that I need, but moving classes between projects requires locating and copying in the appropriate stuff from ModGlue, which is somewhat tedious and will become moreso the longer I go without a better strategy. Some of the general-purpose routines are things like:
Function Byt(ByVal v as Integer) As Byte
Return CByte(v and 255)
End FunctionFunction HexArr(ByVal dat() as Byte) As String ' Returns hex representation of array
Function ByteString(ByVal dat() as Byte, ByVal Length As Integer) As String ' Converts bytes to string (by character code)
Sub Zap(ByRef it as iDisposable)
Dim oldIt as iDisposable
oldIt = it
If oldIt IsNot Nothing then
oldIt.Dispose
Threading.Interlocked.CompareExchange(it, Nothing, oldIt)
EndIf
End SubIn many cases, things that sorta should have been part of the .Net framework, but aren't. What's the best way to make sure that the necessary functions get brought in when copying a class from one project to another, without ending up with extraneous or duplicated methods?
-
What is the best practice for placing general-purpose routines which will be widely used? To date, I've tended to simply have a ModGlue.vb file in each project, where I throw any that I need, but moving classes between projects requires locating and copying in the appropriate stuff from ModGlue, which is somewhat tedious and will become moreso the longer I go without a better strategy. Some of the general-purpose routines are things like:
Function Byt(ByVal v as Integer) As Byte
Return CByte(v and 255)
End FunctionFunction HexArr(ByVal dat() as Byte) As String ' Returns hex representation of array
Function ByteString(ByVal dat() as Byte, ByVal Length As Integer) As String ' Converts bytes to string (by character code)
Sub Zap(ByRef it as iDisposable)
Dim oldIt as iDisposable
oldIt = it
If oldIt IsNot Nothing then
oldIt.Dispose
Threading.Interlocked.CompareExchange(it, Nothing, oldIt)
EndIf
End SubIn many cases, things that sorta should have been part of the .Net framework, but aren't. What's the best way to make sure that the necessary functions get brought in when copying a class from one project to another, without ending up with extraneous or duplicated methods?
Build a dll you import into all your projects.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
What is the best practice for placing general-purpose routines which will be widely used? To date, I've tended to simply have a ModGlue.vb file in each project, where I throw any that I need, but moving classes between projects requires locating and copying in the appropriate stuff from ModGlue, which is somewhat tedious and will become moreso the longer I go without a better strategy. Some of the general-purpose routines are things like:
Function Byt(ByVal v as Integer) As Byte
Return CByte(v and 255)
End FunctionFunction HexArr(ByVal dat() as Byte) As String ' Returns hex representation of array
Function ByteString(ByVal dat() as Byte, ByVal Length As Integer) As String ' Converts bytes to string (by character code)
Sub Zap(ByRef it as iDisposable)
Dim oldIt as iDisposable
oldIt = it
If oldIt IsNot Nothing then
oldIt.Dispose
Threading.Interlocked.CompareExchange(it, Nothing, oldIt)
EndIf
End SubIn many cases, things that sorta should have been part of the .Net framework, but aren't. What's the best way to make sure that the necessary functions get brought in when copying a class from one project to another, without ending up with extraneous or duplicated methods?
As CG said, create a class project, put all your utility snippets in there and reference it from every project. The only problem with this is my util never stays the same for long enough to create a DLL. Housekeeping this DLL can be a major job, otherwise it just continues to grow. I moved from VB to C# last year and had to rewrite all my utilities and DAL, one of the best excercises I have ever done, shrank by 40%.
Never underestimate the power of human stupidity RAH
-
As CG said, create a class project, put all your utility snippets in there and reference it from every project. The only problem with this is my util never stays the same for long enough to create a DLL. Housekeeping this DLL can be a major job, otherwise it just continues to grow. I moved from VB to C# last year and had to rewrite all my utilities and DAL, one of the best excercises I have ever done, shrank by 40%.
Never underestimate the power of human stupidity RAH
I've never managed to create a DLL that I could "references". I have managed to create DLL's which I could use by explicitly importing them at run-time (hardcoding the path to the DLL) but that seemed really incredibly icky. I'm using a mix of VS2005 and VBex2005; I'd probably just use VS except that I have VS set to one color scheme and VBex to another; if I could set different projects to different color schemes, I'd probably just standardize on VS, but I've asked repeatedly how to do such a thing and never gotten any response. To be sure, the DLL's I've created have been in straight C rather than C# or VB, but I'm still wondering what step I'm missing. Otherwise, I wonder if there are any good utilities which can take some source files and aggregate all the stuff that matches, flagging anything that doesn't. Merge all identifiers within a module or namespace that have identical definitions; for classes without control definitions, merge everything but fields. For control definitions, prompt the user for what to do about mismatches. Do any such handy tools exist? Also, you say you go in and clean up your multi-purpose project periodically. How do you ensure that nothing breaks when you do that?
-
I've never managed to create a DLL that I could "references". I have managed to create DLL's which I could use by explicitly importing them at run-time (hardcoding the path to the DLL) but that seemed really incredibly icky. I'm using a mix of VS2005 and VBex2005; I'd probably just use VS except that I have VS set to one color scheme and VBex to another; if I could set different projects to different color schemes, I'd probably just standardize on VS, but I've asked repeatedly how to do such a thing and never gotten any response. To be sure, the DLL's I've created have been in straight C rather than C# or VB, but I'm still wondering what step I'm missing. Otherwise, I wonder if there are any good utilities which can take some source files and aggregate all the stuff that matches, flagging anything that doesn't. Merge all identifiers within a module or namespace that have identical definitions; for classes without control definitions, merge everything but fields. For control definitions, prompt the user for what to do about mismatches. Do any such handy tools exist? Also, you say you go in and clean up your multi-purpose project periodically. How do you ensure that nothing breaks when you do that?
i am wondering if you are over thinking it. Grab everything that you think other apps would benefit and just move them into a class-library project (dll). All the name spaces that you have created (if any) still exist. You might need to add references to system libraries that natually come with a windows application (drawing/window.forms/etc). In your windows app, reference the new dll and import the new dll in your form or whereever else you need it. Same code that worked in one project now works spanning another project with the benefits of intellisense, etc(lose that at run-time load assembly). Nothing breaks --> to verify all projects are compatiable with the changes made in your new shared dll, just create a "master" solution and add all projects in there. make your changes and then compile the master solution and if successful...you know at least syntax wise all is compatible...
'Never argue with an idiot; they'll drag you down to their level and beat you with experience.' ~ anonymous 'Life's real failure is when you do not realize how close you were to success when you gave up.' ~ anonymous
-
I've never managed to create a DLL that I could "references". I have managed to create DLL's which I could use by explicitly importing them at run-time (hardcoding the path to the DLL) but that seemed really incredibly icky. I'm using a mix of VS2005 and VBex2005; I'd probably just use VS except that I have VS set to one color scheme and VBex to another; if I could set different projects to different color schemes, I'd probably just standardize on VS, but I've asked repeatedly how to do such a thing and never gotten any response. To be sure, the DLL's I've created have been in straight C rather than C# or VB, but I'm still wondering what step I'm missing. Otherwise, I wonder if there are any good utilities which can take some source files and aggregate all the stuff that matches, flagging anything that doesn't. Merge all identifiers within a module or namespace that have identical definitions; for classes without control definitions, merge everything but fields. For control definitions, prompt the user for what to do about mismatches. Do any such handy tools exist? Also, you say you go in and clean up your multi-purpose project periodically. How do you ensure that nothing breaks when you do that?
Yup - do what Larson said, this really is a simple excercise. I have no idea what VBex is so I can't comment on it but VS C#/VB allows you to simple make a class library project, compile it and reference it in other projects.
Never underestimate the power of human stupidity RAH