[RESOLVED] Mixing VB and C#

I can try this out, but I thought I'd ask here whether anybody has any experience with this.

My actual situation is that I have a program that dynamically loads some .NET dlls. Currently, everything is written in VB. In VS, you can be debugging a project and step right into the dynamically loaded dlls. This is still pretty amazing to me. The dll doesn't have to be anywhere in particular. In my case, the dynamic dlls are in one folder somewhere, while the projects that created the dlls are in the default Projects folder for the VS that was used to create them. The dynamic dlls are the release versions, too, so they don't contain symbol information. Still, VS has no problem finding the source code when I step into code in one of those dynamic dlls, and stepping right into it. Of course, if the dynamically loaded dll is not in sync with the source code, then problems arise, but as long as they are in sync, I don't even have to tell VS where the source is located.

So, there's no reason why a C# dll wouldn't work just as well as a VB dll for dynamic loading. What I'm curious about is what happens when stepping through code. Will it step right into C# from VB? My guess is that it will, and I can test it without great difficulty, but I'm wondering if anybody has any experience with stepping into C# dlls from VB, or vice versa. Are there any issues I'll need to be aware of? Any problems that might come up?

I've had solutions that contained both VB and C# projects before and I can't recall ever having any issues related to that or having to do anything special. It's been a while now so I may have forgotten by now but nothing that I can recall.

Yep we have some solutions that contain both VB & C# projects at my work never had a problem debugging from one to the other, it should work just the same as going from one VB project to another VB project.

I've stepped from my VB code into MS's C# code when looking through what the .NET Libs do.... no issue... didn't require anything special.

-tg

I've stepped from VB and C# into C++ and that works perfectly as well!

That's what I was expecting, and with all those responses, I don't think I'll even bother trying it out just for the sake of trying it out. Once I have something real, that'll be time enough.

PLEASE IGNORE THIS POST... missed the point completely, sorry. :)


All .Net language projects are built according to the Common Language Runtime's standard definitions, no matter what language you wrote the code in. As soon as it's built, all the language-ness is stripped away and you're left with the bare conceptual functionality that can be absorbed immediately by another language. Intelli-sense just knows how to deal with it, it's rather elegant.

In other words in practical terms the only difference is the human readable language the source was written in. I've written many class library DLLs over the years and they have been called by languages such as F# and VB.Net and generally there is no indication of what the original language was to the person calling the library. It simply doesn't get in the way at all (unless you're doing something peculiar like passing around unmanaged ("unsafe") objects).

In theory anything that is possible in C# is possible in VB.Net and vice-versa, although it may be easier in one language than the other.

Back in the day we had to consider "Managed C++" as a project type in .Net. That never ended well. I've not heard of anyone doing Managed C++ for years now though. It's probably not a thing anyone wants now.

You may have missed the part about debugging and stepping into the dll code.
The code you see in the IDE isn't the CLR, but the source of the code the DLL was written in, if you have it.
That was the main point of the question, whether you would be stepping through VB code in the IDE, and then end up stepping through C# code in you stepped into the method from the a dll written using C#.

Yeah, that was the point.

Many years back, MS was making noises about being able to write C# and VB in the same file. That may have been a misinterpretation, even at that time. They might have meant different pages within the same project, which would make more sense. After all, C# and VB both have some form of Imports statement, but they aren't the same, so mixing the languages within a single file would be pretty weird. Mixing pages with the two languages within the same project would not be anywhere near as potentially confusing, and would make for some serious power.

To the best of my knowledge, any thoughts along those lines were dropped around 2012 or 2013. Sure would be kind of nice, though. There are features of C# that would be nice to mix into a project that was otherwise VB. It can be done now by making a C# dll to include those features and referencing it from VB, but building the two into the same project would be nicer.

Thanks for the clarification. Now I see what you're getting at.

Are you confusing "Solutions" with "Projects"? One can easily combine a VB GUI project code and a C# DLL project inside a Solution for instance.

Whether you can step through a .net binary... consider the fact that .net is compiled to IL code instead of machine code. Then consider whether the debugger would rather let you step through "decompiled" IL code (roughly readable in your arbitrarily chosen language) instead of machine code (not remotely readable in any .net language).

Long story short, the runtime debugger only needs the .net assembly (which contains IL code) in order to allow you to step through it at a basic level. If the compiler CAN find the original source (and it will look in some likely places) then it will do it's best to show you it synchronised with the real human-written code. If it cannot, then it'll try to show you the best it can based on the "stripped" IL code. And you'll notice things like variable names getting replaced with generic placeholders (variable1, variable2...).

Now I'm not sure whether you're talking about the original post, or my latest. Post #9 was talking about some discussions that were going on back around 2010. It was certainly different pages within one project, but I thought the discussion was about different methods within the same page, which is even more entwined than having different languages within the same project.

Nothing ever came of it, either way, so it doesn't really matter all that much whether I remembered what amounted to speculation incorrectly, because whether I remembered it right or wrong, it didn't happen either way.