This question already has answers here:
Which version of C# am I using
(20 answers)
Closed 3 years ago.
I use C# for .NET. I know how to programmatically detect CLR version of a .NET assembly, but can’t find out how to programmatically detect the C# version in my code. Anyone has idea? TIA.
The C# source code has been translated to IL when the assembly is generated. It's no longer relevant what C# version was used to generate the IL (or indeed, if C# was used), nor is that information stored.
There are some IL features that will not be used by older versions of C# (e.g. support for nullable reference types and async streams). If the IL contains such constructs, you can rule out older C# versions. It's highly non-trivial to make that determination.
Here's a breakdown of the assembly format (click through to the second article in the series). You'll see there's no information describing the language or version that generated the assembly.
https://www.red-gate.com/simple-talk/blogs/anatomy-of-a-net-assembly-pe-headers/
This question already has answers here:
CLR and CLI - What is the difference?
(7 answers)
Closed 5 years ago.
What exactly is Common Language Runtime in Dot Net. Is it an exe or dll. Can I see common language runtime in task manager. Where is it located.
You should first look up in google before posting here.. But here it goes:
What is it?
The .NET Framework provides a run-time environment called the common language runtime, which runs the code and provides services that make the development process easier.
Where is it located?.
C:\Windows\Microsoft.NET\Framework\v2.0.50727
Of course the last part depends on your version.
This question already has answers here:
Is there any way to compile Java code into a DLL?
(3 answers)
Closed 9 years ago.
I need to use Java code in .NET (C#) and am looking for a way to convert a Java class to a DLL file (which I can then reference in my .NET app). Is this a valid scenario? If yes, How can I do it?
You can use IKVM.NET to use Java classes and libraries from .NET.
Basically that is not a good idea. Since java emphasizes on platform independence, but dll is platform dependent. So, think about pack into a jar file, execute and consume it somehow
May be this link will be useful for you:
http://www.codeproject.com/Articles/13549/Using-Java-Classes-in-your-NET-Application
For this you can use IKVM.NET.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Tool to convert java to c# code
I have done a project in java and I want to convert it to C#.Net. I'm using Visual Studio 2008. How can I convert the code from Java to C#? Are there any tools available?
There are tools that can help do this. For example this one from the team who created db4o:
Smart java to c# conversion for the masses with sharpen
Note that these are not perfect and some constructs and API's cannot be easily translated.
IKVM.NET Bytecode Compiler
Here is an Msdn Article about converting from Java to Visual C#.
I think your best shot would be, unless you really really need all the code in C#, to use Visual J# and integrate your Java code with C#.
Microsoft used to support their own .net implementation of the Java language, called Java#, but unfortunetelly they discontinued the project.
But at least you could try it to see if it could help you to convert your code to .net
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have just moved job and gone from VB 6 to VB.Net and found the learning jump fairly steep, have more a problem with the object / conceptual side of things .. but getting there now ... but as I was a assembler / C++ 10/15 years ago and was considering learning C++/C# .Net (XNA games library calls my name) but not sure if it would hinder my VB.NET learning .... or should I just get myself certified
I was (back in the day) a VB6 dev, and I would expect it to help. There is a much-commented tendency for VB6 developers to keep writing VB6 in .NET; even just a brief look at C# might help you think about VB.NET as a .NET language, rather than a Visual Studio 6 ancestor.
Of course, you might find (as I did) that you don't want to go back to VB.NET after C# ;-p
But as has already been mentioned - the framework is identical. And with C# 4.0, many of the differences will become even less (with "dynamic" making it easier for C# to talk to late-bound COM, and the named arguments / auto-ref stuff making it easier for typed COM).
There is a lot of drive for converging the feature sets of C# 4.0 and VB.NET in VS2010
To me the biggest obstacle for .NET is learn what is available in the framework. Therefore, if you find it easier to code in C# it will mean you only struggle with one thing instead of two. Once you know the framework it's just syntax really as 95% of the stuff you can do with C# can be done with VB.
Also, C# will force you to write code in a more object orientated manner as you can't fall back to coding in a VB6 style.
'yield return' is an example of something that doesn't have an equivalent in VB9 (there are rumours this is being added for VBX though).
Apart from the fact that a large part of what you need to know is about the Frameworks's libaries learning another syntax that targets the .NET's CLR is useful.
Seeing how another language expresses the same concepts helps you to separate the concepts from the language. This is always useful because the concepts are fairly constant, (for example a shadowed(VB) or hidden(C#) function) whilst different languages use different words to express them.
Understanding the concepts better will help you to utalise them when designing code.
IMX, learning C# helped me with learning VB. It's something about seeing the same concepts expressed in 2 ways rather than just 1.
EDIT: Anthony Jones beat me to it :-)
Well for one thing if your method does not return anything then you have to create a Sub in VB.NET and if it returns anything then call it a Function!
I just switched from C# to VB.NET (client requirement) and am still getting used to its nuisances :(
I would say coding in VB almost takes the OOPS out of .NET
I was also a VB6 developer before switching to .NET. First I tried to use VB.Net but it never felt comfortable so I tried C# and fell in love with it. :-)
There are some differences as noted in the previous replies, there are things you can do in VB.Net that you can't in C# (like indexed properties) and vice versa. But apart from that the differences are purely in the syntax. There are in fact several available translators that will convert C# to VB.Net and back.
So I would recommend you to try out C#. Since you know some C++ it shouldn't be very hard to get the syntax right, and the rest is learning to use the framework.
The only real hindrance learning C# would have to VB is documentation. There seems to be a lot more information out there for C# users and trying to find the VB equivalent syntax of sometimes pretty standard C# can be a pain.
That being said... it never hurts to know alot of different ways to do the same thing.
I agree with Garry, the biggest issue is the API.
The second biggest issue I have personally observed is VB6 developers writing VB6 code in VB.NET. That's a good reason in itself for VB6 developers to learn C# - it forces you to think in .NET style.
As a devoted .Net developer I have worked on big projects in both C# and VB.net. Having seen the strengths and weaknesses of both languages I have found VB to be the most frustrating at times.
The problem is that with VB (depending on your project settings) it will magically perform implicit operations such as casts. This can be helpful sometimes, but in the general case you do not want your code to do something unless you explicitly tell it to (this is how C# behaves, in an explicit manner). I would prefer a compiler time error to tell me I cannot convert from one object type to another rather than a runtime exception in our live deployment.
I have found that this implicit aspect of VB tends to hamper the "VB only" developer's understanding of what is going on behind the scenes. For these people, looking at C# seems to trigger some lightbulbs, where they say "aha!, that must be what VB is actually doing when I perform this operation".
I'd recommend you give C# a try, it'll give you a new perspective and you might find that you really like it.