Use C# ref struct in VB.NET Today. And vote against preventing this in Roslyn

[M.Hamdy]

This trick will allow you to use Span(Of T), and System.Text.Json library and more!
Please fight with me to keep this working, as I feel that there is a war against VB .Net, and unfortunately, VB developers are to lazy to defend their beloved language!
The workaround I am using here seems upsetting one of Roslyn team, so, he filed this issue: https://github.com/dotnet/roslyn/issues/50118
to ask to prevent this worarount and deny VB any access to ref structs, which makes VB unable to use important classes and libraries in .NET Core such as System.Text.Json. So, I think it's time for VB community to make the team hear their voice. Please, fight against killing your favorite language.

What is a ref struct?
C# introduced 'ref structs' to represent a `stack-only Structures`, which can perform better (faster) than normal structures and classes, because they are allocated in a part of the memory called `the stack` and are never allowed to be moved to another part called `the heap`, which has less performance (slower). To ensure that, there are many limitation in using ref structs, to prevent them from being boxed directly or indirectly, so:

• you can't assign/convert them to `Object`.
• you can't create an array of a ref struct.
• you can't have a ref strict field in a class or a normal structure. ref strict fields are only allowed insdied another ref struct.
  and other rules alike.

For such many restrictions that need a lot of work to modify the compiler, MS decided to not support them in VB.NET.

The problem
The problem is that ref structs found their way to .NET Core to benefit from their performance, so, they are used to create many types (like `Span(Of T)`) that are used with many important classes like string and file classes, and more recently, the `System.Text.Json library`. But VB.NET can't use any of that, which mean that VB will be out of the game over time as it can't use more and more APIs of .NET Core!
But, I found a workaround, and it works just fine!
Let's try a simple code:

Sub main()
   Dim s As New Span(Of Integer)({1, 2, 3})
   Console.WriteLine(s(1))
End Sub

if you tried this, the code editor will show an error line under 'Span(Of Integer)`, with the message:

Span(Of Integer)' is obsolete. Types with embedded references are not supported in this version of your compiler.

The solution
I tried to workaround this until I found a very simple solution: Just mark the method (or the whole module/calss) with the Obsolete attribute, and pass false to its second parameter:

<Obsolete("Allow ref structs", False)>
Sub main()
   Dim s As New Span(Of Integer)({1, 2, 3})
   Console.WriteLine(s(1))
End Sub

Now this code will compile and run successfully.


But be aware
VB knows nothing about ref structs, and think they are just normal structs, so, it will not prevent you from boding them. Try this:

Dim s As New Span(Of Integer)({1, 2, 3})
Dim o As Object = s

VB will not object boxing the span into an object, and the code will compile, but the .NET RunTime will not allow this, and will give you a runtime error:

System.InvalidProgramException: 'Cannot create boxed ByRef-like values.'

Also, you must know that this error is external to VB.NET, and will crash your app. Ypu can't even handle this error probably by a Try Catch block as it will not prevent the crash. If you used this code:

Dim s As New Span(Of Integer)({1, 2, 3})
Try
    Dim o As Object = s
Catch ex As Exception
    Console.WriteLine(ex.Message)
End Try

The `Catch` statement will catch the error and the error message will be printed to the consol, but the app will still crash and shut down.
So, you must use ref structs with cautious, and don't try to violate their rules.

[Shaggy Hiker]

There have always been a few things in C# that weren't in VB. The oldest example that I'm aware of is unsafe pointers. In places where those were needed, the simplest solution was always to write the code that used them in C# and put it in a dll. The dll can be referenced from VB just fine. Why can't you do the same with any particular use of ref structures? Build your own wrapper around the functionality you need in a dll, then you can reference that from VB.

[M.Hamdy]

Why can't you do the same with any particular use of ref structures? Build your own wrapper around the functionality you need in a dll, then you can reference that from VB.

The same answer as why can't we write the whole app in C# or Rust or Python.

And by the way, VB always has a way to deal with unsafe code thought API, COM, and Marshal. This is an odd situation, where ref structs are managed code not unsafe, and VB can really use them.

[Shaggy Hiker]

The same answer as why can't we write the whole app in C# or Rust or Python.

OK, what is it? A library is a library, who cares what it is written in?

One of the great advantages of .NET is that you aren't tied to one language when using dlls. .NET is .NET. At one point, MS was even talking about a new version of VS where you'd be able to use different languages possibly in the same code file, or at least in the same project. Neither of those happened, but it shows where they were thinking of going, at one point in time.

The points the guy made in the Git thread were significant. It's not so easy to corrupt memory in .NET, so if this allowed you to do so, some people would. On the other hand, the final reply that I read showed that some people are already making use of the technique you showed, though not necessarily for the purpose that you put it to. Therefore, changing the behavior will break existing code, which makes it hard to do.

[M.Hamdy]

It's not so easy to corrupt memory in .NET, so if this allowed you to do so, some people would.

Can't happen, as I explained: runtime will throw an exception when a VB code violates ref structs rules.

Therefore, changing the behavior will break existing code, which makes it hard to do.

They are insisting to push vb out of the game, so, Syrus suggesting adding a new formula to the Obsolete Attr, which will need some changes in both C# and VB compilers. Do you think this all effort is to protect vb from a runtime error?

[Niya]

VB6 programmers have been crying about VB6 being obsolete for about 20 years now. I'm not gonna waste time doing the same thing for VB.Net. I love VB but Microsoft did give fair warning that they were no longer going to evolve VB as a language going forward. Something like this was inevitable. Microsoft made it clear that the future is C# and I have no problem going there when it's time. This is just how it is. Things change. We can either adapt or we can waste time crying and moaning.

[jmcilhinney]

VB6 programmers have been crying about VB6 being obsolete for about 20 years now. I'm not gonna waste time doing the same thing for VB.Net. I love VB but Microsoft did give fair warning that they were no longer going to evolve VB as a language going forward. Something like this was inevitable. Microsoft made it clear that the future is C# and I have no problem going there when it's time. This is just how it is. Things change. We can either adapt or we can waste time crying and moaning.

Yeah, Microsoft have pretty much always viewed C-based languages as the choice for real heavy-duty work and VB as being the quick-and-easy tool. That you can push VB to do more complex stuff doesn't change the fact that that wasn't the intention for it to begin with. One of Microsoft's arguments was that forcing VB to keep pace with C# was actually stifling the development of C# to provide features in VB that most developers wouldn't use. I've never heard a valid counter-argument. Sure, people who want to use those new features in VB aren't happy with that but they are balanced by C# developers who have to wait for other new stuff that gets delayed because of VB. No developer has the right to be able to use a programming language in a way that its creator didn't intend or even in a way they did intend if they change their mind. If you want the features of C# then use C#. VB is what it is so, if you don't like what it is, don't use it. When I started at my current employer, they had, fairly recently, migrated from VB6 to VB.NET but we work pretty much exclusively in C# now.

[Niya]

Yeah, Microsoft have pretty much always viewed C-based languages as the choice for real heavy-duty work and VB as being the quick-and-easy tool. That you can push VB to do more complex stuff doesn't change the fact that that wasn't the intention for it to begin with. One of Microsoft's arguments was that forcing VB to keep pace with C# was actually stifling the development of C# to provide features in VB that most developers wouldn't use. I've never heard a valid counter-argument. Sure, people who want to use those new features in VB aren't happy with that but they are balanced by C# developers who have to wait for other new stuff that gets delayed because of VB. No developer has the right to be able to use a programming language in a way that its creator didn't intend or even in a way they did intend if they change their mind. If you want the features of C# then use C#. VB is what it is so, if you don't like what it is, don't use it. When I started at my current employer, they had, fairly recently, migrated from VB6 to VB.NET but we work pretty much exclusively in C# now.

I think for a very long time something like this was inevitable. BASIC started as a teaching language. For it to reach as far as it did is almost miraculous. C was meant to be a "real" programming language, not something to be used to teach. This is why everybody takes it more seriously than any BASIC derivative. BASIC's past was bound to catch up with it. I was not the least bit surprised when Microsoft announced that they were done developing VB. I knew that day would come eventually.

[M.Hamdy]

It seems that if I accidentally piplished in a C# forum
You seem that you don't know anything about BASIC, VB, VB.NET nor Roslyn.
These tradistional propaganda about BASIC and VB should be dead since VB.NET and C# became just an IL interpreter running on the CLR and compiled by JIT. They are just dialects, with some different flavors of semantics. After Roslyn, the deference became two thin to notice, but the real issue is that VB devs are not a community players. If you read your words you will hear it load and clear. Instead you say we will take over the source, and continue our VB as we want, you just say: oh no, it is our fate and we have nothing to do, except obey the company!
In fact, VB.NET is always superior that C# (although they are all IL interpreters) , because its team always offered many features that makes live simpler for us. One of the for example, is the genius XML literals, which made me write the first VB ASP.NET core Razor in 5 minuets, which needs a very complex job (and money of course) to be done and maintained in C# Razor!
Look at this:
https://github.com/VBAndCs/eShopOnWeb_VB.NET
Being simple, and "for teaching", is the most productive qualities can any language have ever. This means easy to learn, easy to recruit devs, RAD, and out of the blue you have the DOS famous for BASIC, Windows famous for VB, and a multi hence a multi pillion $ Microsoft. Just because it was a language for teaching (and here you confused the dialect with the compiler! The dialict is the most brilliant ever, but the compiler differs over years, until it is Roslyn now, whic is the C# compiler too).
In short: C# and F# has active communities, that saves time and money to MS. But VB has no such a community, and we just demanding new things to happen, and they not will, since MS fired 30,000 employee since 2008 crisis, and I expect more since COVID19 crisis. The attitude I am seeing here and in every VB small community is the real VB killer.
And by the way, one of VB.NET community decided to give it another life with another company, and now Murcury is in alpha, and comming soon (you can have a free trial now). Murcury is compatable with VB.NET, cross platform, runs on ASP,NET and Mobile, and can have C# files in the same projects. Every. They done a lot of work in just one year, in a small company, but it is not open source, and not free.
I am still doing my best with VB.NET, and think Mercury is a good completion that can whip MS to take more care of its child.
Thanks.

[jmcilhinney]

You seem that you don't know anything about BASIC, VB, VB.NET nor Roslyn.

Cool story bro. It's not an original idea to assume that if people disagree with you then they must not understand. It's just as arrogant here as it is everywhere else.

[M.Hamdy]

Sorry, but it must said that way. And not understanding an importance of thing doesn't imply understanding nothing at all. I am made that VB devs are throwing away its diamond thinking it is just a peace of glass. If facct this implies that C-like nurds propaganda succeeds to make you think less of vb and its developers. Forgive me, this is unforgivable .

I published an issue in developers community, as Cyrus closed the discussion in Roslyn, so, please vote for it:
https://developercommunity.visualstu...here-is-a.html

[Niya]

After Roslyn, the deference became two thin to notice, but the real issue is that VB devs are not a community players. If you read your words you will hear it load and clear. Instead you say we will take over the source, and continue our VB as we want, you just say: oh no, it is our fate and we have nothing to do, except obey the company!

"Obey the company"? Oh I see. You're one of "those" people. I've out-grown childish tantrums like this. If a lack of ref structs becomes a problem to me guess what I'll do....I'll do the adult thing by making the sensible decision to use C# instead. I'm not gonna waste time on childish nonsense like trying to "save" VB. VB is just a tool and if it can't do what I want it to do, I will find a tool that can.

[Shaggy Hiker]

My goal was not going the way of VB6: Fussing and fighting into that good night.

I suppose a part of my indifference is that this is a Core issue, and I'm currently not writing for Core, so it doesn't apply to my expected future. Structures on the stack do seem fairly useful, and I'm in favor of anything that increases efficiency. Still, I would prefer that the feature be added to VB rather than that the solution be the exploitation of a loophole.

However, change happens. This isn't a hill I'm interested in fighting on, let alone dying on.

[Niya]

I think more programmers need to be exposed to the business side of things. They will learn very quickly that clients don't give a rat's ass what language you're using to create their solutions.

[M.Hamdy]

My goal was not going the way of VB6: Fussing and fighting into that good night.

I suppose a part of my indifference is that this is a Core issue, and I'm currently not writing for Core, so it doesn't apply to my expected future. Structures on the stack do seem fairly useful, and I'm in favor of anything that increases efficiency. Still, I would prefer that the feature be added to VB rather than that the solution be the exploitation of a loophole.

However, change happens. This isn't a hill I'm interested in fighting on, let alone dying on.

This is not a performance issue. Because of the stack-only types best performance, they are now breeding like rabbets in .NET core and 3rd party libs, so, we began to find VB unable to use those libs, and even some old libs announces that will try ref structs. This will eventually kick vb out of the game.
So, this is not about writing our code, it is about using other libs and engines.

[sapator]

Unless you are using VB for a big app that is ready and already in use and you constantly need to implement new features then there is no point of not using any other language that can do a specific task you want.
Don't get me wrong, I really dislike C# , it's an wannabe clone of pure C C++ that went bad and made a baby with VB but if they(micro-coronam0rn-soft) decide to deprecate VB then I won't cry about it.
I will be pissed, yes but , if I can't help it then I must go with the flow. An by "can't help it" I mean that the company I work for is using .NET and I'm limited to that, else I would happily have switched to another language years ago.

[Shaggy Hiker]

This is not a performance issue. Because of the stack-only types best performance, they are now breeding like rabbets in .NET core and 3rd party libs, so, we began to find VB unable to use those libs, and even some old libs announces that will try ref structs. This will eventually kick vb out of the game.
So, this is not about writing our code, it is about using other libs and engines.

Well, unless you are willing to write wrappers for the libs.

[M.Hamdy]

Why should I write a 1000 wrapper over years, while I solved the issue, with one line of code?

Besides, wrappers is not always possible. In fact this is was the first approach I tried to allow vb to crate a JsonConverter to be used with System.Text.Json, but this was not possible, since the converter class must override some methods that have params of ref structs, and I can't pass these params to other methods because ref structs can't be saved if local fields except insied a ref strict!
This is a totally insane type, that don't give you any margin to do anything!. I tried many tricks, but the ones I hope they can work, would need too much effort to wrap a chain of ref structs, that it may be easier to rewrite the whole lib from scratch instead.
So, after 3 days of trials, I decided to kill the obsolete error and go on. And it worked.

[Shaggy Hiker]

The point is not necessarily that YOU create all the wrappers. As long as it is possible to create the wrappers, then somebody will, at which point you can use the wrapper library and you're off and running.

[jmcilhinney]

C# , it's an wannabe clone of pure C C++ that went bad

It obviously isn't. If it's a wannabe anything then it's a wannabe Java. The fact that it uses C-based syntax is irrelevant. So does JavaScript.

[dday9]

Heads up, I modified your original post. VBForums uses use BB code tags instead of markdown syntax.

Besides, wrappers is not always possible. In fact this is was the first approach I tried to allow vb to crate a JsonConverter to be used with System.Text.Json, but this was not possible, since the converter class must override some methods that have params of ref structs, and I can't pass these params to other methods because ref structs can't be saved if local fields except insied a ref strict!

Why don't you create your own JSON library, the language definition is simple enough. Heck, I have an example in the codebank that converts JSON to XDocument.

Better yet, why not use a third party library like Newtonsoft?

I don't think you will get the level of support for trying to browbeat Microsoft into including features (or in some cases reviving) for your choice language. You'll wind up like so many of those in the VB6 forum who will drag their feet on moving on because their language was the brought down by the mountain by Abraham on two separate installation discs.

It obviously isn't. If it's a wannabe anything then it's a wannabe Java. The fact that it uses C-based syntax isn't irrelevant. So does JavaScript.

Yeah, we hired a guy with a strict Java background that could look at C# code and know almost immediately what was going on because their syntax is eerily similar. The only real place he struggled to grasp (for a while) was LINQ.

[peterst]

Why don't you create your own JSON library, the language definition is simple enough. Heck, I have an example in the codebank that converts JSON to XDocument.

Because it is not so easy if you want to handle all cases. Imagine JSON coming from (or passed to) Go, Scala and Node.js services or clients and how much they can differ. That's why the advanced JSON serializers are having multiple options where you can configure how the data is handled. Simple example is NetJSON serialized object can't be deserialized by Newtonsoft.Json (Json.NET) when using default options for both libraries (hint: it was the date/time format).

But there is another big problem:

Better yet, why not use a third party library like Newtonsoft?

Performance is the key. Here is old (2014) comparison of JSON libraries performance (and protobuf-net as binary format serializing library).

System.Text.Json was created for performance. When you have many thousands of requests/responses each second in your system, you will need that performance. In distributed environment every byte and every millisecond counts.

It is sad that the new possibilities from .NET 5/Core sometimes are not accessible to VBers. There are wonderful libraries which are extremely optimized with all new features. For me the solution is to go with C# directly instead of creating wrappers as it is much straightforward (even I still don't like C-style syntax).

[M.Hamdy]

Heads up, I modified your original post. VBForums uses use BB code tags instead of markdown syntax.

Thanks

I don't think you will get the level of support for trying to browbeat Microsoft into including features (or in some cases reviving) for your choice language. You'll wind up like so many of those in the VB6 forum who will drag their feet on moving on because their language was the brought down by the mountain by Abraham on two separate installation discs.

Disagree. There is a big difference between VB6 and VB.NET situations, as VB.NET is an open source, and we are in the GitHub era, so, basically, there is nothing we can't do.
And above that, we have a secret weapon in this fight: The most important vb team member, Anthony Green, who left MS a a yaer ago, but is loyal to VB and still working on amazing things, that can take vb where no language has never gone before. Look at his blog posts about Pattern-based XML Literals on his blog, which elevated the XML approach I used in Vazor (https://github.com/VBAndCs/Vazor) to write ASP.NET core apps with pure VB.NET, to much higher grounds. This is the first part from his blog, and you can follow other parts there: https://anthonydgreen.net/2019/06/13...-introduction/
And I hope you catch up with us in VB.NET rooms in Gitter:
https://gitter.im/VB-NET/Language

[dday9]

Disagree. There is a big difference between VB6 and VB.NET situations, as VB.NET is an open source, and we are in the GitHub era, so, basically, there is nothing we can't do.

I don't understand what you want then.

At first it sounded as if you wanted us to complain to Microsoft that ref structs are available in C# but not VB.NET.

Now you're saying that you can implement the feature if you want. If that's the case, then why not fork off the GitHub repo, make the the changes yourself (or have Anthony Green do it), and then submit a pull request.

And I hope you catch up with us in VB.NET rooms in Gitter:

I went to the chat room and it has the feel of an echo chamber. It genuinely looks and feels like y'all are taking the same route that die hard VB6ers took in 2005.

[Shaggy Hiker]

Back when MS had the UserVoice site, people could put up suggestions and vote on them. VB6 folks were proud that their suggestion (make a new VB6) got more comments than any other, and was around third in the total number of votes. Both were problematic. For one thing, the comments made no difference to anybody, but more significantly, the top suggestion based on votes was WAY ahead of VB6....and MS declined to accept it. That suggestion was to keep XNA going, which never happened.

The point I'm trying to make is that voting in this arena hasn't changed anything in the past and doesn't seem likely to change anything in the future. MS adopted suggestions that got only one or two votes, while rejecting the first and third highest vote winners. I'd say they were right to do so, as well. In the case of XNA, there wasn't any very solid reason for them to continue, especially since MonoGame kept it going forwards.

When it comes to .NET, as you already noted, it is open source. I would say our votes matter even less than they used to. If all people do is vote, aren't they saying, "we care enough to check a box, but not to take even the slightest action"?

[M.Hamdy]

MS is taken VBers for granted, as they will eventually move to C#. We are trying to shake this confidence at different levels:
1. VB community is angry of sabotaging his beloved language intentionally.
2. We have Mercury to migrate to, outside .NET and MS echo system (C# is not the only option).
3. We can fork the lang, and go separate ways.

So, there is a predure on MS to recalcualte the risk, and obviously, you are sending the opposite meassage: Go kill VB, MS, and do not care! We are hopeless helpless community, and don't mind us.

Again, VB6 is not valid for comparison. It was too limited, that I threw it away with the first day of .NET. Also, we wre choosing between two VB dialects, so, there was no fear that MS dumping the lang. This is not the case now.

Finally, it is a strange question about forking the lang to support ref structs! It is already supported, and they are figtinhg to unsupported it! They will never accept any proposals against that!
Almost two tears ago, I volunteered to give ASP.NET team 6 months of my life for free to write a VB Razor (.vbhtml) for them, but they instantaneously rejected the offer! I knew for sure that they are killing vb, so, I dig around and discovered that VB already has a built-in razor (called XML literals), and used it to build Vazor! If just C# had XML literals, it would saved them millions of dollars and agony to create that too complected Razor!
VB has many hidden treasures, waiting for the adventurers to seek.
And the irony here: every single obstacle they threw against VB, I bypassed in a few minutes! One more example of that, C# init-only properties, that can't be set in VB if the class didn't provide a constructor for them. I just set them via late-binding, like this:
Dim O as object = new Foo()
O.SomeInitOnlyProp = someValue!

It works just fine, and there is an issue against in Roslyn to prevent VB from doing that!!
I don't need to fork the language. I only wan't them to stop damaging it, and keep it as is today.

[jmcilhinney]

VB community is angry of sabotaging his beloved language intentionally.

What a crock.

[dday9]

...Again, VB6 is not valid for comparison...

...I only wan't them to stop damaging it, and keep it as is today.

Do tell.

Enough of beating a dead horse, I'm unsubscribing.

[Shaggy Hiker]

Again, VB6 is not valid for comparison. It was too limited, that I threw it away with the first day of .NET. Also, we wre choosing between two VB dialects, so, there was no fear that MS dumping the lang. This is not the case now.

It it TOTALLY relevant. You're making the same case that they did, and in the same way. The language worship, the threats to leave for a different language, the speaking for an enraged community, the desperate desire for the language to be both kept as it is and advanced as long as the direction is acceptable. All of these are features of the many threads in Classic VB and General Developer about the demise of VB6. It all comes across as unhinged, to me, and I have no interest in participating.

[Delaney]

MS is taken VBers for granted, as they will eventually move to C#. We are trying to shake this confidence at different levels:
1. VB community is angry of sabotaging his beloved language intentionally.
2. We have Mercury to migrate to, outside .NET and MS echo system (C# is not the only option).
3. We can fork the lang, and go separate ways.

So, there is a predure on MS to recalcualte the risk, and obviously, you are sending the opposite meassage: Go kill VB, MS, and do not care! We are hopeless helpless community, and don't mind us.

Again, VB6 is not valid for comparison. It was too limited, that I threw it away with the first day of .NET. Also, we wre choosing between two VB dialects, so, there was no fear that MS dumping the lang. This is not the case now.

Finally, it is a strange question about forking the lang to support ref structs! It is already supported, and they are figtinhg to unsupported it! They will never accept any proposals against that!
Almost two tears ago, I volunteered to give ASP.NET team 6 months of my life for free to write a VB Razor (.vbhtml) for them, but they instantaneously rejected the offer! I knew for sure that they are killing vb, so, I dig around and discovered that VB already has a built-in razor (called XML literals), and used it to build Vazor! If just C# had XML literals, it would saved them millions of dollars and agony to create that too complected Razor!
VB has many hidden treasures, waiting for the adventurers to seek.
And the irony here: every single obstacle they threw against VB, I bypassed in a few minutes! One more example of that, C# init-only properties, that can't be set in VB if the class didn't provide a constructor for them. I just set them via late-binding, like this:
Dim O as object = new Foo()
O.SomeInitOnlyProp = someValue!

It works just fine, and there is an issue against in Roslyn to prevent VB from doing that!!
I don't need to fork the language. I only wan't them to stop damaging it, and keep it as is today.

Interesting, with you philosophy, we should have stayed on Qbasic or Basica after all....

By the way, I am not angry of the evolution, so either I am not part of you community or it is not the whole community who is angry after all.

I am an amateur, I am happy with VB.net as it fulfill all my present requirements but when I need I adapt: I needed to use an Arduino so I learned the C language (well, I was knowing it already a bit) which I just hate, but well, you have to do what needed.

If I should become an pro tomorrow, I would probably shift to both C# and Python and/or C++ because I think it would be more adequate.

I think you should learn and use the tools the most relevant to achieve you goal. If the tool is not OK, change it or adapt it but don't go to the store to complain, mostly when it is free...

[M.Hamdy]

VB syntax is the highest level that I know, and the nearest thing to a natural language. Defining that is the most logical thing to do. I am not attached to a compiler or a set of tools. The Basic language is both beautiful and smart. It is on top of the evolution of programming, and I love its efficiency (as an engineer), and its eloquence (as a poet). It is too brilliant to let it fad just because some finance calculations (a questionable ones indeed).
That being said, and since we mentioned finance, VB6 defenders had another reason that I didn't at that time (and I think neither of you): A large code base that VB.NET broke, and was not cheap to upgrade. This is business, and you can't beat that. The seem reason you are thinking now to use some C# with your code base just to keep up and running. I have a friend that owns a company that is base entirely on a VB6 code that he evolved over years into into customizing wizards to create DB and business apps. His team in fact use the wizards, but every thing is still based on vb6 until today. You can't expect that he can just change a 25 years work into VB.NET (now should be C#) just because MS says so!
So, the current situation may not that sever because C# and VB can work together, and this is why MS let VB pass to .NET Core, to be wrapped in dlls and referenced in C# apps. It is easy to VB.NET companies to hire new C# team to make this happen, but individual devs (with are millions) will not all be willing nor able to (after some age) to learn C#. This is Where Murcury and other solutions can take place.
By the way, I write C# (and write books about C# in Arabic). But I see it (and all C-Syntax langs) inferior and out of evolution! They put the compiler welfare first, then the programmer comes next! So, the programmer has to act like a robot to use these languages that can't understand his intentions. This may OK in serious performance considerations, but is not for RAD and daily tasks. This is why the same team member that I am complaining about here confesses he uses VB a lot when he wants to try an idea or create RAD apps, although he is heavily invested in Roslyn and C# source code.
So, there are many strong reasons that will make different groups refuse going to C#, and all of them can be compiled to money in some level (for example, slow coding with a cryptic new lang with many errors and bugs because of low experience is a big wast of money).
So, it you have none of these concerns, good for you, so, move on and let us solve our problems to save our money.

[Shaggy Hiker]

Well I agree with those points, certainly. Many current languages are based on the C syntactic family, including C, C++, Java, JS, and C#, and that syntax has some decided issues. The issues are due to the timeframe when the C language was originally created. They baked in some choices that made a whole lot of sense when computers had no reserve processing power to spare. VB is more recent and better built. Not everybody makes use of some of those features, but they are there.

Some of the VB6 people have very large code bases that make conversion very difficult or impossible. However, if you spend any time in the swamp of angst, you also realize that some do not. Everyone must make an economic choice. For my part, everything I have written has been using framework and WinForms, so this discussion of Core is purely hypothetical, for me. Now, one might say that will change, but for my part, retirement is not very far away. I do intend to write some new things using Core, and get into .NET 5.0, but the applications that will carry me on out are not looking likely to move to Core.

That may seem a bit cynical, but it really isn't meant to. I started in DOS with BASIC, C, C++, and even a bit of ASM. I saw Windows come in, and started using VB back around 4, and in earnest with 5 and 6. Now, don't take that as me talking about the old days. That wasn't all that far back. The real point is that fairly radical shifts have tended to happen every five years, or so. I started being paid to program in pre-internet, early LAN days. My first few programs were built for the conditions of the times, and didn't do anything network. I then wrote a program for use on a PDA. That whole platform went the way of the dodo after only a few years of use. In 2005, I wrote a really well received program that launched the most incredible boondoggle I've ever been witness to, but the original program was intended to be used on tablets. Two years later, tablets were invented, but by then, the boondoggle was off to the races, and the people involved no longer had the understanding to recognize that the necessary platform had arrived on the market. And on it has gone since then.

The simple fact is that most software has a lifespan of only a few years, perhaps a decade, or so, if technology doesn't wipe it away completely. I have a couple programs that are old enough to drink, but they've mostly survived because they were so highly specialized that the changes to the technology haven't prevented them from still operating. Even so, most of those are going to be gone within a year or so, and only one will remain. That's life in this industry: We change at a fantastic pace. Even worse, the race goes not always to the best. Inferior technology has often replaced superior technology, or outlasted it.

Planting your feet in the mud and refusing to move simply doesn't work. Life will flow on around you and leave you behind. It's leaving me behind, as well. In my field, somebody told me just yesterday that nobody comes out of school without knowing something about R. A bit of hyperbole perhaps, but I know from experience that it isn't very much hyperbole.

So, move forwards. Don't say that it must not change, that won't work. VB.NET will continue as long as people use it. It will advance so long as people advance it. What I didn't like about the approach you used was that it exploited a loophole. Loopholes have a way of being closed, sometimes by accident. What you need to do is to make the program work with the feature. In this case, I felt there wasn't a clear and obvious way to do that aside from creating a library, probably in C#, that wrapped the library you wanted to use. That still seems like the best option, even if it is something of a half measure.

[M.Hamdy]

This was well said. OK, we have a common background to built on.
I agree that techs change, So, I never said I want to stuck to a particular compiler of framework (though, we invested a long time to learn the framework). So, Mercury is exactly VB.NET and more. It do all what VB.NET does, can work in VB.NET, and targets .Net framework and .NET Core, but also works where VB.NET doesn't, works out VS on other operating systems, Creates ASP.NET Core and Mobile apps, and targets other non-MS cross platform frameworks. So, it can over weight C# when companies get to choose, and it don't require the devs learning C#. But this will be tested when it released and used in practice. So, this is one of the options one ov VB community made possible when he saw VB.NET ship sinking. And in fact, he can force MS to recalculate the risk if Mercury pulled out a significant part of .NET ecosystem.
So, don't worry, I am not sticking in the mud. I and others try to find another safe ways, to continue using our favorite lang in joy and production.
About consuming ref structs in VB: I am using a known feature of Obsolete, that MS can't change without breaking many working apps. This is why syrus is thinking of inventing a new form of the Attr just to block VB! It is a waste of MS money for unuseful goal and I want to deliver this massage to them.
I am willing to fork the lang, but there is not enough resources about Roslyn. I only wrote an auto completion provider to provide HTML auto completion inside xml literals for Vazor or whatever. It is a VS extension (published on Vazor repository), once installed, it provides auto completion inside the block:
<vbxml>

</vbxml>

But I am still away of playing with VB syntax. I decided to use the Small Basic open source compiler as a playground, as it is a very small compiler that demonstrates many compiler features. I hope I can upgrade to Roslyn soon enough.

By the way, trying to widen our options is practical consideration, since we can't trust the fate of C# itself, after such repeated MS racking decisions. I have a friend that was building a programming without code technology using Fox pro, when MS shut it down suddenly. This friend decided to build his own lang to continue his project safely. He now has a wonderful cross-platform dynamic language called Ring and feel totally secure
Ring is now in the 51-100 rank in Tiobe and hope it can find its way up.
https://ring-lang.sourceforge.io/

I have a vision of next Basic generation, with more eloquent compact syntax, and some powerful features, and I hope I can implement it someday.

[Niya]

Sigh.....this is VB6 vs VB.Net all over again.

[Shaggy Hiker]

Sigh.....this is VB6 vs VB.Net all over again.

Same plot, different cast.

[Niya]

Same plot, different cast.

I couldn't have said it better.