❔ Proper way to do something in C# (migrating an old Visual Basic library)
So I'm rewriting an ancient library and used an automatic transpiler to convert it all from VB.NET to C#. Still plenty of clean-up I've needed to do after, and there was one line in particular that I can't figure out how to properly convert (and remove all dependencies on the Microsoft.VisualBasic namespace):
Looks pretty straightfoward at first glance, with the big gotcha being that tt isn't a string, it's a struct. The analyzers in Rider say that Strings.Len will automatically box tt to an object to get the length, but I'm not clear on exactly how to do that the same way as the VB Strings.Len() method
20 Replies
Then what exactly is tt?
Can you run and debug it? Maybe step into the method?
Maybe it does tt.ToStrint().Length
Just a guess
Or ask ChatGPT, it's the best modern transpiler you can get
Sadly I can't just run it because I'm still working on even being able to get it to compile (and even if I did it's dependent on a bunch of databases and other things that I don't currently have access to so I'd have to mock those). Looking at the struct that tt is, it's just a bunch of properties with getters and setters, no methods at all
I guess I could just create a program that does Strings.Len on a struct and see what it returns
From the documentation it seems that Len returns the number of bytes necessary to store the struct
It is like sizeof in C
Well this is fascinating.
When IO run Strings.Len on an instance of the struct, I get 12 (which is the number of properties in the struct). However, thr struct has several [VBFixedString] attributes on several of the properties which I had temporarily commented out. Removing the comments changes the length
But only when I remove the comments on the VBFixedString(2) attributes, removing the comments on the VBFixedString(4) attribute doesn't change anything
I assume the pointer for a string reference is 4 bytes so it doesn't change anything?
The C# alternative to Len should also be sizeof, from what I've been able to find
String is a reference type
And the pointer size depends on whether you are building for 32 or 64 bit
Afaik
Well, looks likle I'm going to have to do some more untangling then since the line of code in question is used to change the value of an iterator for a loop
and sizeof only works in unsafe contexts unless you give it a predefined size, and I don't know what that predefiend size is "supposed" to be in the first place
This is some insane black magic
Vb programmers be crazy
I wish it was black magic, it's definitely more spaghetti code here lol. A good chunk of what this library is doing is reading binary data from some files and databases, converting it to strings to use/manipulate/whatever (and ASCII only, I might need to add proper support for unicode) and then converting it back to byte arrays and saving it. They chose some of the most convoluted ways imaginable to do this though lol
And all them left the company years ago
Pretty much yeah, most of this appears to have been originally in VB6, I've found a bunch of comments left behind by an automatic VB6 to VB.NET conversion tool they used on it probably 20 years ago
Guess I'd better find out if the stuff that depends on this is 32-bit or 64-bit, and if we can even change that without breaking all of the data that has already been stored
Jesus why are you tasked with reviving this dinosaur... Haven't they seen what happened in Jurassic park??
They want to move some service to Azure Functions, but it turns out this library is one of said service's dependencies
Here's a last little tidbit to blow your mind before I dive into this trash fire:
Huh
Wha
Why
That's right, they took a string, converted it to an integer (it was the old Conversions.ToInteger, I already changed that), then convert it to a char, then back to a string
I think they wanted to convert it to a hex value but wanted to make sure it actually has both digits if the leading digit is a 0
I think
I hope you get a bonus pay for this
I wish, at least they pay me well here haha
Well.... Enjoy 😂
Well I might be able to avoid using sizeof() entirely here. Turns out they were using that to calculate the byte number in the file to start the write at (using the old VB FileSystem.FilePut() method). Should be easy to do it cleaner and better with a Stream.
Thanks for the help in figuring out what the hell they were doing in the first place haha
Unknown User•16mo ago
Message Not Public
Sign In & Join Server To View
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.