We're trying to trim the number of assemblies we load during startup, and one of the easiest to cut is the Microsoft.VisualBasic assembly. There are alot of things in it that were easy enough to replace, like Left(), but I'm struggling to find a good way to replace vbLf and Chr(). vbCrLf was easy enough to replace with Environment.NewLine, but we have a few spots where we generate content for a Unix-based system that is expecting line feeds only.
+2
A:
Public Const vbLf As String = ChrW(10)
Public Const vbLf As String = Convert.ToChar(10)
bdukes
2009-03-18 19:14:13
He wants to get rid of ChrW() as well.
Joel Coehoorn
2009-03-18 19:15:56
Sorry bdukes, I want to do this without anything in Microsoft.VisualBasic.
Bob King
2009-03-18 19:16:36
A:
Chr is a fairly complicated method (looking at it in Reflector).
At its base, it uses Convert.ToChar(), but it does a lot more with checking and different behavior for different ranges of characters.
bdukes
2009-03-18 19:18:02
+5
A:
I need to first point out that there is likely no good reason for this at all. All built-in .Net Assemblies, including Microsoft.VisualBasic.dll, are always available to all .Net programs and using or not using any of these assemblies in your program has zero impact on your program's memory footprint. You can even use Microsoft.VisualBasic.dll from C# programs with no issues. The only case where you might possibly run into a problem is with the mono implementation of the library. So unless you're thinking about porting to mono at some point you're probably spinning wheels.
That said:
Chr():
Function Chr(Byval CharCode As Integer) as Char
Return Convert.ToChar(CharCode)
End Function
vbLf
Const vbLf As Char = Chr(10) ''// of course calling your own Chr implementation
This assumes ASCII, but if you have code that's expecting single line feeds this is a pretty safe bet.
Joel Coehoorn
2009-03-18 19:25:00
@Joel, thanks, and you're probably right about not reducing the memory footprint. What I'm hoping to accomplish is reducing cold startup time by eliminating any assemblies we don't *really* need at startup. It's a WPF app, and we pay a pretty high price for cold-start on XP.
Bob King
2009-03-18 19:38:13
It won't change it: the core assemblies are all pretty optimized. You're talking a few milliseconds. It's the work the famework has to do on your own code that takes time, so adding user-code to bypass an assembly will be a step backwards.
Joel Coehoorn
2009-03-18 19:40:32
@Joel, you are correct. I finished removing it and found no measurable difference. False optimizations: "The only way to win is to not play".
Bob King
2009-03-18 19:49:28
A:
Assuming you're using VB.NET, removing explicit calls to Microsoft.VisualBasic classes won't remove the reference to the assembly. The VB.NET compiler utilizes some functionslink text in there on your behalf. You can compile with the /vbruntime- switch, but I wouldn't recommend it for any non-trivial app.
Mark Brackett
2009-03-18 19:34:31