Question:
I want code for: syntax highlighting (of programming languages)
Language: C# or assembly x86 (preferably C#)
Platform: Windows
Qualifications: most efficient implementation possible / most professional / the way that big corporations like Microsoft do it
Rephrased: How do I implement syntax highlighting in C# for Windows in the most efficient way presently known?
Elaboration (feel free to skip - not needed to answer question :)):
I don't want just any way of implementing it - I've already seen several.
What I'd like to know is how Microsoft does it so well on Visual Studio (whichever version).
People keep trying to reinvent the wheel when it comes to syntax highlighting. I don't understand why.
Is this considered a very hard problem? I've seen implementations that only highlight what's currently showing on the screen, I think that's the way to go... (it used some clever API to know which lines of a textbox were actually showing).
I've also seen implementations using RichTextBox and I think that's not the way to go (maybe I'm wrong here) - I think something like subclassing the routine that draws text on the regular textbox and changing its brushes might be better (maybe I've seen that somewhere - I doubt I'd think of that myself)
Also I've heard that some people implement it with AST just like a compiler would be coded (the lexer part, I think?) - I'd hope that that's overkill - I don't see that as being efficient. (uneducated guess)
If it's indeed a hard problem, then how do the big corps always get it right? I've never heard of a way to break the syntax highlighting in Visual Studio, for example.
But any other tool that implements it does so poorly, or worse than the big guys.
What's the official "this is the best way and any other way is less efficient" way of doing it?
I really don't have any evidence that Microsoft's way is better, but seeing that they probably know more about Windows API than anybody else, I'd guess that there way of implementing it is the best (I would love to be wrong - imagine being able to say that my implementation of syntax highlighting is better than MS's!)
Sorry for the disjointed elaboration.
Also I apologize in advance for any faux-pas - this is my first question.
I don't think there is a "this is the best way and any other way is less efficient" way to do it. In reality I don't think that efficiency is the major problem. Rather complexity is.
A good syntax highlighter is based on a good parser. As long as you can parse the code you can highlight every part of it in any way you like. But, what happens then when the code is not well-formed? A lot of syntax highlighter just highlight keywords and a few block structures to overcome this problem. By doing this, they can use simple regular expressions instead of having a full-fledged, syntax-error tolerant parser (which is what Visual Studio has).
The best way is probably to reuse something existing, such as ScintillaNET.
As with anything code.... there rarely is a "best" way. There are multiple ways of doing things and each of them have benefits and drawbacks.
That said, some form of the Interpreter Pattern is probably the most common way. According to the GoF book:
The Interpreter pattern is widely used
in compilers implemented with
object-oriented languages, as the
Smalltalk compilers are. SPECTalk
uses the pattern to interpret
descriptions of input file formats.
The QOCA constraint-solving toolkit
uses it to evaluate constraints.
It also goes on to talk about it's limitations in the applicability section
the grammer is simple. For complex grammars, the class hierarchy for the
grammer becomes large and unmanagable.
Tools such as parser generators are a
better alternative in such cases
effeciency is not a critical concern. The most efficient
interpreters are usually not
implemented by interpreting parse
trees directly but by first
translating them into another form.
For example, regular expressions are
often transformed into state machines.
But even then, the translator can be
implemented by the Interpreter
pattern, so the pattern is still
applicable.
Understanding this, you should now know why it's better to pre-compile your reusable RegEx first before performing many matches with it. If you don't, it will have to do both steps every time (transformation, interpretations) rather than building the state machine once, and applying it efficiently several times over.
Specifically for the type of interpretation you are describing, Microsoft exposes the Microsoft.VisualStudio namespace and all of it's powerful features as part of the Visual Studio SDK. You can also look at System.CodeDOM for dynamic code generation and compilation.
If you are able to embed a web page you could look at Prism.js
Related
I was reading this question when I noticed a curious comment underneath:
not sure what the question is: you can use VB.NET and C# projects in one solution (though I wouldn't recommend doing so).
I do this quite a bit, as we have legacy VB.Net code, and new code is written in C#. Is this really not recommended? Why not?
There is no real reason to avoid this, other than adding complexity from having two languages in one "solution".
Your scenario (working with a legacy product, but adding new features) is a valid reason to have both languages used in a single solution, in my opinion.
The only reason that it wouldn't be recommended is consistency. Most developers prefer to deal with a single language when working on an application. Having a single language also means that your developers only need to know a single language rather than knowing both VB.NET and C# (even though the two are extremely similar).
If you need to mix legacy VB.NET and C#, there's no reason not to.
It's a matter of "use the best tools available to you for what you're building". Mixing C# and VB within a project isn't recommended (for obvious "it won't compile" reasons), but there's no point in continuing to write old code in VB if you feel your development team can operate faster and in a more maintainable fashion using C#.
We've been doing this at my office for the past few months (in a similar legacy code situation) and have yet to run into any major issues (beyond potential lost dev time due to context switching), and we've gained incredibly from working with a language that we all feel more comfortable with.
More information on task switching here. I really do feel like the benefits we see on a daily basis from our level of comfort with C# outweighs the cost of occasionally having to dip back into the legacy pool.
Its just a matter of person choice. if you are comfortable with both the languages, You surely can use them in same solution.
Using a single language in a solution seems easily maintainable. hence it is preferred.
Mixing code in solutions can get real messy real quickly, its never clear what method you are calling from where, to keep it nice. Develop in separate Solutions, it will keep your projects easier to track and make sure you are not confusing languages inside projects
Why would you want to do that? If you have legacy code what you want to use, you keep that code in its own components, you don't mix it with the new code. It is not recommended because it does not promote "Clean Code". It can lead you to have a solution that is difficult to read and maintain.
First, let me ask you to consider this as a real question, and not a subjective one.
That out of the way, here's my situation: We are looking to port our existing classic ASP application to .NET, but we're unsure of what language to use for the new app.
I personally would 'prefer' C#, as I'm more familiar and comfortable with that languages way of doing things, but, the original code is VBScript, so it would possibly be easier to port to VB.NET ... One possible situation I fear would be that, because the code is so similar between the two variants of VB, that we might end up getting stuck on something that is not similar between the two, even though it looks like it would work. A shift to a wholly different language might avoid that kind of situation.
Does anyone have any practical examples of this kind of situation? Insights to illuminate the issue with? Do the potential benefits of a complete paradigm shift outweigh the gains from a high degree of 'copy-and-paste-ability' ?
I have used C#.NET and just recently learned VB.NET and I have to say that once you get around the small syntactical differences, VB is also a very good language. So for you, this is a win win.
That being said, I think a syntax change will help protect the project from any careless copy pastes from the old dirty code base. I believe a fresh start with a fresh language is your best bet for a top notch re-write.
There are 10X as many questions re: C# as there are VB.NET on StackOverflow. That seems to indicate there are more developers using C#, or perhaps a more thriving community (or maybe it just means C# is harder or C# developers don't know as much).
Any gains made due to the similarity of VBScript to VB.NET are far outweighed by the fact that you need to learn the new data types, .NET namespaces, and a new style of web development using webforms or MVC (my preference).
For this reason I think the choice of language should be made independently of what was used before.
3 years ago I had to make this same decision. My preference would have been C# but we ultimately went with VB.Net because that was the closest language available to the developer base we had. All of the developers had experience with VBScript, so learning VB.Net was easier for them. While the framework is the framework and the rest is just syntax and best practices, you'd be surprised the difference in learning curve just by adding a few curly braces for VB developers (the reverse seems to be exactly the same for C# developers going the other way with an itchy semi-colon finger, learning new keywords and relearning event syntax).
You should look at your developer pool and consider what is the easiest for your team to perform development and maintenance. If this is not a serious criteria (because the developers are proficient equally in both), then I would recommend a C# approach. The primary reason is that the VBScript will be relying on outdated methodologies, but converting to VB.Net will not necessarily throw exceptions for these methods whereas C# will. It will also force you to touch every aspect of your application, which (while tedious) will provide your team an opportunity to evaluate how older methods may be refactored into more efficient processes.
Just keep in mind - the "easiest" seeming solution seldom is.
When moving to ASP.NET, I believe that less focus needs to be on the page itself, and more on how you're going to write the business logic. This is a subjective question because different units will have different results.
That said, always play to your strengths. If your team is more familiar with C# than VB.NET, use C#. If they're more familiar with VB.NET, use VB.NET. If they have no real .NET Experience, then you probably want to set up some sample projects with which they can play to see which will be easier to learn. You want the most bang-for-your-buck, and that means making sure the team is as comfortable as possible.
Further, I wouldn't worry too much about copy & paste code, as there are enough differences that any professional developer (as in one who acts professional, not just one who gets paid) will see how much he/she is changing and go back through the rest of the code to ensure it is working properly.
The difference between an ASP.NET and Classic ASP application is already so big, that it will not be an easy copy/paste port anyway.
So I think you should go for the language that you feel most comfortable with (and as another answer suggests, there is a much larger community using C# than VB.Net).
Why are you rewriting the application? What are the short and long term objectives you hope to achieve through this change?
At a high level there is not much to choose between VB and C# - both are extremely functionally rich labguages that compile to teh same IL code.
Personally I moved to C# a few years ago because the vast majority of code examples found on the net are in C#, and the programmer's best friend is the internet where you may just find that nugget of useful information that save you hours of head scratching.
In your situation, by fircing yourself to rewrite the code in a different language will force you to possible rething the implementation and therefore review carefully the code and functionality required - if yuo have the time and budget. If you are up against tight deadlines then VB would be the natural choice, but may negate the benefiots if the rewrite.
I have been in exactly this position, and I urge you not to translate the app in two ways at once--from VB to C# and from classic ASP to ASP.NET.
You have chunks of business logic in your code that will not need to change much, so why change it? You are guaranteed to introduce new bugs in the translation.
I can't count how many times I thought, "this looks exactly the same, why isn't it working?"
Just adapting your code to the new codebehind pattern will be challenging enough. A vast and worthwhile improvement, of course, but not trivial.
VB.NET and C# are so incredibly similar that technically the choice is almost irrelevant. Each language has some minor things they excel in, but overall, the two are practically identical, just with wildly different syntax.
With that said, I highly recommend going with C#, just because it's the language the .NET community really got behind. It will have the most books, websites, blogs, forums, you name it. Not having to translate the oodles of examples out there on the net into VB.NET alone makes C# a better choice. I think in my 10 years of being a .NET developer, I could count the number of people I've ran into that genuinely chose VB.NET on one hand. Most people that are using VB.NET are using it in a "stop gap" fashion, with the intention of ultimately going to C#.
Many people go for C# because they think that VB.Net and C# is only syntactically different which is just not true. VB.Net has better features for handling interactions with COM components for example, like optional parameters (these are now available in C# 4.0). But there are catches too in a line by line conversion of VB to VB.net. A very simple example is the array index. If I'm not mistaken array indexes start from 1 in vb and in vb.net it starts from 0 which causes horrible bugs. Overall, I'd definitely consider going for VB.Net even though I work basically in C#.
I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.
My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.
One of the developers today specifically asked "why should we switch to C#?"
I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.
So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.
Looking forward to your input!
As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!
I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?
Why switch to .NET over VB6:
Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.
I do not believe you can create a 64-bit native application in VB6. That rules out a lot.
No new enhancements are being made to VB6.
OK, there are so many reasons I can think of, I'll probably just stop there.
Why switch to C# instead of VB.NET
Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.
It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.
In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.
Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).
VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.
I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...
As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...
I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.
This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:
C# / VB.NET comparison
As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:
Wikipedia article listing advantages of C# over VB and vice versa
The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.
Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.
"Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts." (#Markle)
I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)
I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."
I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.
A quick search on SO careers:
92 job postings for c#
11 job postings for vb.net
1 job posting for vb6
reasons why VB6 developers should switch to C#
Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:
C# developers get paid more than VB.NET developers, for doing exactly the same thinking, just typing different source code after doing that thinking
Also
ReSharper for C# is better than ReSharper for VB.NET
Other than technical / social advantage is more business oriented,
Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon.
Moving to a new platform in this case make more business sense.
Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.
Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.
On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.
The biggest advantage C# has over VB6 proper has got to be inheritance.
(OK, to be fair it's my personal favourite, so I am totally biased.)
Other advantages:
Formal accessors
Exception types (I don't think VB6 has exception types, but please correct me if I'm wrong)
Generics
Lambda expressions
And the following are more related to the .NET platform than languages themselves:
Very rich library
Visual Studio refactoring and other goodies
Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.
I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
That proves nothing.
VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing.
But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone).
The market pretty much demands C# over VB.net.
I'm not considering this - I'm comfortable with C# and VB, but an expert in neither. But, some on my team have expressed an intention to do this since we're moving toward C# as a standard.
Hell's no. Just an absolute waste of time.
I would use VB over C# (or C# over VB) only if the language enabled functionality that was not available in the other.
For example, making late bound calls to COM interop objects is much easier in VB than it is in C# (although that is going to change in C# 4.0).
That being said, I'd stick with the language that your team is using, or what you prefer (if that is an option).
Sounds like a recipe for disaster or at least countless WTF-moments with no actual gains.
.net Assemblies are compatible regardless of language (it's all IL at the end anyway), so there is no gain from that.
I would get comfortable in C#, which shouldn't take too long. Writing in VB and then converting would just be a waste of time IMO.
Besides, what happens when they need to read some C# code if they're not comfortable in the language?
I would not do this. I would start using C#.
It is easier to go from programmer's intent to source in either language than it is to go from one to the other.
You should use the language you intend to use.
There are other considerations not mentioned. Notably, if you're converting your VB code to C# using automated software, you can count on there being numerous conversion issues. Do not let anyone lure you into a false sense of confidence regarding the amount of work that conversion entails: VB.NET and C# are further apart from each other than you may think. Converting from one language to the other will introduce a large amount of work into your schedule, and will possibly rewrite portions of your code in unexpected ways.
Take it from someone who's done it.
If you don't have a truly compelling reason to port your existing code to C#, it's likely far more cost effective to leave it in that language, and simply write newer code in C#. Also, if your developers aren't entirely comfortable with the change to the new language, you may have to deal with the discomfort that some of them may feel. Whether we agree with it or not, some employees may feel so strongly about it that they will leave, which will incur a signficiant cost when you have to replace them.
Just my two cents.
I would be opposed to that approach.
If the intent is to move to C# as a standard why wait to start using it? I also find it far too easy to imagine the conversion never happening. When it comes to crunch time and the choice is between converting and adding/fixing features then conversion is likely the first to go.
In the vein of it being a people problem. Why the move to C# in the first place? Are you sure everyone is on board with that being the standard?
As a huge fan of VB I would say that this is essentially a very bad idea. If C# is being used, write in C#.
Actually, .NET makes it quite easy to mix multiple languages in one project as long as it is divided into multiple assemblies. A priori nothing speaks against this practice. However, as soon as one language is established as a standard in the project, all developers should stick to it.
Converting is a waste of time and money since there exist no automatic, error-free conversion tools (that I am aware of) so it would always involve some manual post-processing. This shouldn't be acceptable. Additionally, learning C# when you know VB is pretty straightforward and shouldn't create a barrier that offsets the cost of converting code.
I wouldn't recommend it. It just doubles the work imho.
If you need two different applications to talk to each other, I suggest using web-services or some open format (XML) for transporting data. That way you can keep both VB and C# apps.
I prefer C# but if the majority of developers are VB.NET guys, why are you moving to C#? That will be a learning curve with no gain in productivity. Also I am assuming the majority are VB.NET people, if not well then you have a huge PR nightmare on your hands.
The approach we have is the VB.NET guys develop in VB.NET and the C# guys in C#, we are lucky enough to have well defined modules which can interact on the IL level without any issues.
No. NO! Just... say... no.
My boss suggested that at one point because many of the engineers (note.. structural engineers, NOT programmers) knew VB6 and were comfortable with VB, but he wanted to use C# as a standard.
I immediately wanted to deck him to knock some sense into him, however I restrained myself and calmly discussed the options with him. I was finally able to convince him that -- while .NET is .NET -- VB.NET with slices of VB6 that the users are sure to squeeze in for "ease of coding" is NOT the same as C#.NET.
There are enough differences that -- at least for us -- the learning curve of C# was worth the time instead of the coding curve of converting from one .NET language to another.
I've been jumping from C# to Java an awful lot and the "differences" between the two are a bit of an annoyance.
Would it be possible to write a set of extentions/plugins that would merge the two languages syntaxes.
I'm talking about adding either IDE support or using language constructs that would for example:
treat these two lines equivalently:
System.out.println("Blah");
Console.out.writeline("Blah");
Automatically notice that when you type in string you mean String
Recognise common API calls and translate them in the background.
The end goal being to be able to write a java/C# program and to pick at compile time which VM/Runtime you are targeting.
If you could do this would it be a good idea?
If not why not?
The two languages are so similar it's painful in some aspects but in other aspects they are really different.
I've seen Code that will translate a C# project into Java and I'm assuming there is probably the reverse, what I am proposing is a middle ground, so we can all just "get along".
No, absolutely not. Certainly not in the languages themselves (as implied by the title) and preferably (IMO) not in the IDEs (as requested in the body).
They are different languages. The idioms and conventions are subtly different. I don't want to be thinking in Java when I'm writing C# or vice versa. I believe developers should be actively encouraged to separate their thinking. It's not too hard to switch between the two, but that switch should be present, IMO.
While I totally agree with Jon Skeet, if you must have this why not create your own library of Java API so you can create System.out namespace which has a method call printLn which calls Console.Writeline()?
That gets you close to what you want.
Just because Java and C# share some similar syntax you need to see past this and think in terms of Java Platform and .NET Platform. The two are distinctly different, so my answer is definitely not.
There actually already is a Java language for the .NET framework, developed by microsoft: J#
This way you get the java-syntax but you are still developing with the .NET framework.
But i am not recommending anyone to use it.
I knew Java before i knew C# so i tried out J# because i thought it would be an easier transition. At first I liked it but after I tried C# I'm never going back. First of all, nobody uses J# so it's kinda hard to find examples and tutorials. Second, C# has (IMO) much more convenient syntax, specially for events, properties, lambda, anonymus methods and alot of other things, it's also being updated every now and then with even more syntax sugar which i don't think J# is.
Maybe if you often write Java and sometimes have to write a .net app it might be a good option.
I think no. I also switch from java to c#. But if the syntax is identical was is to stop someone from trying to compile c# in a Java compiler, or vice-versa.
Visual Studio actually ships with a Java to C# converter, which tries to do some of the things you mention. Unfortunately it fails miserably (1) for anything beyond the simple hello world application.
Despite being very similar on the surface, there are many significant differences between Java and C#, so you would achieve very little by doing what you suggest imo.
(1) To be fair, it actually does a fairly good job if you consider the limitations given for such a task, but in practice the resulting code is of limited use and you have to do a lot of clean up after the conversion.
Firstly what you are describing is not a difference in language syntax but a differences in class libraries. Both languages are relatively simple in terms of keywords and features but understanding or knowing the libraries and how they operate requires considerable learning.
The mistakes you are describing are things that the developer should not be making to begin with - the IDE should not be guessing. There are going to be many cases where you can't easily / trivially translate between java or dotnet. In the end a skilled developer learns and knows when and which class libraries to use.
Actually in the beginning there was no dotnet - microsoft was behind java. They however proceeded to change java in ways not compatible with the java plstform standard. To paraphrase sun sued microsoft and won I'm court. Following that ms proceeded to create dotnet and particularly c# which became microsofts VM platform. Of course along the way a whole stack of things got changed. Microsoft introduced many things which broke Javas run anywhere etc. They have done the same thing with dotnet which have cause problems for the mono team to be able to faithfully reimplemwnt everything for other non windows platforms.
• String vs string.
• lowercase method names (java) v uppercase method names(dotnet).
• Giving java keywords new names - "package".
In the end dotnet was microsoft response so they can control the platform and do their own thing instead of following a standar