问题描述
temp[i]=((Char)Convert.ToInt32(temp[i],16)).ToString();这句代码帮忙转成VB.net
解决方案
解决方案二：
temp(i)=ChrW(Convert.ToInt32(temp(i),16))
解决方案三：
c#编译器对于这个语法单独处理，它不去寻找.netframework支持的方式，而是自己独立处理。这是vb.net不支持的。
解决方案四：
VB下更地道的写法：temp(i)=Asc(Val("&H"&temp(i)))
解决方案五：
在vb.net中，必须调用framework中的函数（例如vb.netframework的函数）。而c#实际上直接产生了更为精简的汇编语句，它直接把integer值的地址指针进行操作。因此c#懂得将(char)integer
进行特殊的编译处理，而不需要调用framework任何函数。
解决方案六：
当你使用某种“反编译”的时候，可能你的工具就“误会”了，会给你翻译为类型转换函数。因为vb.net中根本没有跟c#想匹敌的代码。c#跟vb.net稍微有一点差别，这算是其中一点。
解决方案七：
初一看，是个类型连续转换的问题我都会ctype套用当然效率上，会有点差别不过就我的层次来说，能写出来不行了，管不了那么多
解决方案八：
引用1楼sp1234的回复:
temp(i)=ChrW(Convert.ToInt32(temp(i),16))
就这样
解决方案九：
引用6楼xiaobingking的回复:
初一看，是个类型连续转换的问题我都会ctype套用当然效率上，会有点差别不过就我的层次来说，能写出来不行了，管不了那么多
“反编译工具”可能会产生类似CType之类的代码，然后这种反编译代码在vb.net下编译不通过，反编译工具产生了错误的vb.net代码。正因为此，lz才会提出这样的帖子。
解决方案十：
引用8楼sp1234的回复:
Quote: 引用6楼xiaobingking的回复:
初一看，是个类型连续转换的问题我都会ctype套用当然效率上，会有点差别不过就我的层次来说，能写出来不行了，管不了那么多“反编译工具”可能会产生类似CType之类的代码，然后这种反编译代码在vb.net下编译不通过，反编译工具产生了错误的vb.net代码。正因为此，lz才会提出这样的帖子。
反编译后确实有错误不能直接使用，当然要逐句修正，有些需要联系上下文，整句重写。有反编译给你用就不错了，还妄想没错误，还要我们二等程序原干嘛