I've been converting some of my DNN modules from VB.NET to C#. When I first started coding in DNN, since DNN itself was written in VB.NET, I'd decided to also code the modules in the same language.
Lately, we've decided to also make the modules available in C#, and since some of the older modules did not use our Class Libary wrapped in a Web Service architecture, I decided this was an excuse to move stuff from VB.NET to C#.
There's no point in doing all the work yourself, of course. There are sites you can hit which can convert C# code to VB.NET (the best one is the C# to VB.NET based on #Develop IDE), and also sites which can convert VB.NET to C# (the best one I've found thus far, but still not very great, is the CarlosArg VB.NET to C# Code Convertor). Both these sites are very helpful, but you will still have a number of issues left over, depending on the code.
The Carlos Arg convertor has a number of issues, some understandable and some which could be fixed at some point in the future. Specifically, the convertor has an issue with converting abstract methods from VB.NET to C#. Things like this aren't a big deal of course, if one knows C#. You simply convert the code yourself.
And of course, there are issues of things available in C# which are not in VB.NET. There's a lot of discussion about this on the web...for instance, you can't have volatile variables (which essentially allow one to create a thread-safe class variable that can be called by other threads), and a number of other things, most of which are well explained in this VB.NET/C# Comparison Chart.
However, I was surprised to find out that Optional parameters are not allowed in C#. I had just assumed they were, since it's a useful feature and couldn't have been difficult for the Microsoft team to have included for C#. The fact is, they are not, and you have to come up with a solution yourself.
IMO, there are two choices:
- You can create a parameter class to hold the parameters, and create an array (or ArrayList, or HashTable or some other collection) that is used to pass in. My issue with this is, from a code maintenance standpoint, it's not as clear a solution for the next programmer that comes along to maintain your code.
- Or, you can use the 'params' keyword, and pass in an array of Objects, some of which are empty objects, to directly mimic the VB.NET Optional parameters. This is the solution I prefer.
There is an option I didn't mention, which is to just create n over-ridden methods for n parameters that were declared as optional. You could do this (and I'm pretty sure that this is what the compiler does with the optional params anyway. I would consider that as an option, but since one cannot set a 'default' for a parameter passed in like 'MyFunction (vara, , ,vard)', it means one would have to test each parameter for a null value, in each over-ridden method and I think that gets messy.
So, consider the following function stub in VB.NET:
Public Shared Sub ClearCoreCache(ByVal Type As CoreCacheType, Optional ByVal ID As Integer = -1, Optional ByVal Cascade As Boolean = False)
In C#, you should not have to worry about the calling functions, since all parameters are passed in as objects. You do have to know the order of the parameters, and they Type of each parameter.
The 'ClearCoreCache' function would be defined as follows:
public void ClearCoreCache (CoreCacheType otype, params object[] oparams)
{
int iid = -1;
bool bcascade = false;
int iparam = 0;
while (iparam < oparams.length)
{
if ((iparam == 0) && (oparams[0] != null))
iid = (int)oparam[0];
}
else if ((iparam == 1) && (oparams[1] != null))
{
bcascade = (bool)oparams[1];
}
iparam++;
}
// now use the converted code....
}
I hope this helps anyone who is attempting to convert code from VB.NET to C#, for whatever reasons. One thing I have not tested yet is, if one uses the 'params' keyword, if all parameters need to be included...ie, if the params keyword needs to be typed right after the opening parentheses. I am planning on testing this over the weekend. If so, you would simply include the first param (otype) in the object list and have one more 'if' statement.
One more thing. You might also want to wrap the parameter setting into a try...catch block, but the try...catch is expensive in terms of performance. As long as you have the paremeter variable types correct per each indice in the objects array, there would never be a problem, right? If you do get an error, this is the kind of thing that should be caught in the testing phase, especially if you are using (as you should be!) NUnit to unit test your functions and classes before you start building them.