I am converting a lot of VB.NET code over to C# and there are a lot of VB functions that C# doesn't have such as DateAdd and DateDiff. Can someone tell me the libraries I would have to reference in order to have access to these functions in my C# code if it is even possible. I already tried adding a reference to Microsoft.VisualBasic and it doesn't work.
Time is a factor here which is the only reason I am looking into doing things this way. I want to leave the code in place as much as possible.
Opps it actually is in Microsoft.VisualBasic.
You have to access it like this:
Microsoft.VisualBasic.DateAndTime.DateAdd()
I'm working on a VB.NET codebase that uses legacy naming conventions vaguely similar to Hungarian Notiation, for instance:
A member string Test would be mstrTest
A function-scope int Test would be lintTest
A parameter Object Test would be pobjTest
In order to verify that variables are being named correctly, and to work out a solution to each non-conforming variable name, I need to find any instance of variables in the codebase, along with their scope and type.
I've done some tests using regexes to look for Functions and Subs, but instances of class member variables (for instance) would be difficult to do in this way, not to mention that parsing code with Regexes feels incorrect.
Is there a way (in C#) that I could create some kind of structured hierarchy from the codebase without having to start from scratch, or a better way to achieve this tack in general?
Apologies if my explanation is wrong/vague, I've not attempted to parse a language before.
Hungarian notation was considered very bad practice even in the days of VB6. What you are asking require code analysis.
Regex expressions aren't enough. You can use tools like Resharper to find and even rename the variables using its SDK although there may be plugins that already do what you want. In .NET vNext the Roslyn compiler will allow you to do this out-of-the-box. Perhaps you can try VS2015 CTP 6 to create a quick-and-dirty utility if you don't want to use Resharper.
You can start from Roslyn's GitHub repository, it contains several samples that show how to write analyzers, refactorings etc, as well as documentation on syntax and semantic analysis. Also check Kathleen Dollard's RoslynDOM library which simplifies coding significantly
I have developed a dll in C#.net. Can we decompile the same in VB.net. If yes, how to do that?
Use a tool like Reflector to convert a compiled C# assembly (IL) into decompiled VB.NET source code (might lose some meaning with certain variable names). Another post mentions some free alternatives to Reflector.
Or convert the C# code using an online resource such as this one (1 code file at a time though).
I agree with Mitch, but as a free alternative to Reflector:
ILSpy
dotPeek
Assuming you have the source, you can use sharpdevelop to convert whole solutions back and forth between c#.net and vb.net
The same group also developed a plugin for visual studio: Code Converter C# to/from VB.NET
Sometimes C# cannot be converted (or decompiled) into VB.Net because there are some elements of C# that have no equivalent in VB. E.g. iterators (yield) and unsafe code. Furthermore some of the free converters fail badly even when there are direct equivalents.
Why do you want to do this anyway? It's probably easy to just use the C# DLL from VB.Net code: you can call it, you can inherit from it. "CLS compliance" will help with this.
For what it's worth, it's also true that there are some elements of VB that have no equivalent in C#, e.g. exception filters.
If you've developed it your self I assume you have access to the source? If so you can just convert it all though here:
http://www.developerfusion.com/tools/convert/csharp-to-vb/
I've been hearing/reading a lot about the new language enhancements for C# 4. I'm a little curious if these same enhancements are also going to be applied to VB as well, or what. Does anyone know where I can get some insight here? With all the new changes happening to C#, it seems like there will very little reason left to be using VB unless you happen to like the syntax. Are there enhancements that MS isn't making to VB this time that are getting included in C#, or visa versa?
I'd actually overlook the dismissal of VB.Net by Lou Franco. Checkout Panopticon Central:
http://www.panopticoncentral.net/archive/2008/10/31/24803.aspx
http://www.panopticoncentral.net/archive/2008/10/29/24764.aspx
For example:
Then Lucian did a really wonderful
demo of VB 10.0, which is shipping in
Visual Studio 2010. He showed (IIRC)
the following features that should be
familiar to the readers of this blog:
array literals, collection
initializers, automatic properties,
implicit line continuations, statement
lambdas, generic variance, and a
feature that embeds primary interop
assembly types in your assembly so you
don’t have to deploy the PIA. I may
have missed some, so check out the
video when it’s posted!
Some of the changes to C# (e.g Named Optional Parameters) were already in VB. The main strength of VB.NET over C# was Office/COM integration, and the new C# is addressing that.
If you need to target an older .NET version, VB.NET will still be the one to use if you need these features.
Something still missing from C# that vb.net has had a little while: xml literals. But this isn't exactly new.
Certainly there's the difference in general syntax, but what other critical distinctions exist? There are some differences, right?
The linked comparisons are very thorough, but as far as the main differences I would note the following:
C# has anonymous methodsVB has these now, too
C# has the yield keyword (iterator blocks)VB11 added this
VB supports implicit late binding (C# has explicit late binding now via the dynamic keyword)
VB supports XML literals
VB is case insensitive
More out-of-the-box code snippets for VB
More out-of-the-box refactoring tools for C#Visual Studio 2015 now provides the same refactoring tools for both VB and C#.
In general the things MS focuses on for each vary, because the two languages are targeted at very different audiences. This blog post has a good summary of the target audiences. It is probably a good idea to determine which audience you are in, because it will determine what kind of tools you'll get from Microsoft.
This topic has had a lot of face time since .Net 2.0 was released. See this Wikipedia article for a readable summary.
This may be considered syntax, but VB.NET is case insensitive while C# is case sensitive.
This is a very comprehensive reference.
Since I assume you can google, I don't think a link to more sites is what you are looking for.
My answer: Choose base on the history of your developers. C# is more JAVA like, and probably C++ like.
VB.NET was easier for VB programmers, but I guess that is no really an issue anymore sine there are no new .NET programmers coming from old VB.
My opinion is that VB is more productive then C#, it seems it is always ahead in terms of productivity tools (such as intelisense), and I would recommend vb over c# to someone that asks. Of course, someone that knows he prefers c# won't ask, and c# is probably the right choice for him.
Although the syntax sugar on C#3 has really pushed the bar forward, I must say some of the Linq to XML stuff in VB.Net seems quite nice and makes handling complex, deeply nested XML a little bit more tolerable. Just a little bit.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Apart from syntax not that much any more. They both compile to exactly the same IL, so you can compile something as VB and reflect it into C#.
Most of the apparent differences are syntactic sugar. For instance VB appears to support dynamic types, but really they're just as static as C#'s - the VB compiler figures them out.
Visual Studio behaves differently with VB than with C# - it hides lots of functionality but adds background compiling (great for small projects, resource hogging for large ones) and better snippet support.
With more and more compiler 'magic' in C#3 VB.Net has really fallen behind. The only thing VB now has that C# doesn't is the handles keyword - and that's of debatable benefit.
#Tom - that really useful, but a little out of date - VB.Net now supports XML docs too with '''
#Luke - VB.Net still doesn't have anon-methods, but does now support lambdas.
The biggest difference in my opinion is the ability to write unsafe code in C#.
Although VB.NET supports try...catch type exception handling, it still has something similar to VB6's ON ERROR. ON ERROR can be seriously abused, and in the vast majority of cases, try...catch is far better; but ON ERROR can be useful when handling COM time-out operations where the error can be trapped, decoded, and the final "try again" is a simple one line.
You can do the same with try...catch but the code is a lot messier.
This topic is briefly described at wikipedia and harding.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
Just go through and make your notes on that.
When it gets to IL its all just bits. That case insensitivity is just a precompiler pass.
But the general consensus is, vb is more verbose.
If you can write c# why not save your eyes and hands and write the smaller amount of code to do the same thing.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Yes VB.NET fixed most of the VB6 problems and made it a proper OOP language - ie. Similar in abilities to C#. AlthougnI tend to prefer C#, I do find the old VB ON ERROR construct useful for handling COM interop timeouts. Something to use wisely though - ON ERROR is easily abused!!