我正在用XNA和VB.NET编写一款策略游戏。这种技术组合看起来是一个不错的选择，直到我决定切换到MonoGame（但要保持VB.NET中的游戏逻辑不变）。
问题是MonoGame目前不支持VB.Net。我做了一些研究，似乎我基本上有两个选择：
- 将我的代码重写为C#
- 围绕MonoGame编写一个小的C#包装，并将我的Game Logic代码转化为库
不用说，这两种选择都很糟糕。我是不是错过了另一个选择？我不介意在MonoGame中付出相当大的努力，但重写并不是一种选择。
到目前为止我的发现：
在浏览网页时，我偶然发现了一个VB.Net的MonoGame模板。虽然它看起来正是我所需要的，但即使在运行了一个简单的新项目后，它在加载时也会崩溃。然后，我开始在谷歌上查找错误，但根本无法运行该程序。
解释我的技术选择（因为有人会问）：
为什么选择XNA我以前用过，我很熟悉，尽管它已经过时了，但它非常适合我的需求，应该还能用几年。
为什么选择VB.Net我对它有丰富的经验，比起C#，我更喜欢它的语法。这对我来说很重要，因为我正在编写一个相当大规模的策略游戏，保持代码的干净和可理解是至关重要的。
为什么不是C#经验。我在C#上工作了一年多，但这还不是很自然。VB是.
我找到了一个解决方案。我前面提到的MonoGame模板是一种让这项工作顺利进行的方法。这种方法有几个小问题，但没有太大的问题。
问题1：启动MonoGame项目时出错
在运行一个新的VB MonoGame模板项目后，在启动时会抛出一个严重的错误（mscorlib.dll中的System.TypeLoadException）。这是因为模板引用了一个不正确版本的Mono Game库（我使用的是windows，有一个android库链接到该项目）。解决方案：从你的新项目中删除MonoGame引用，并使用浏览添加回正确的版本。
第2期：MonoGame中缺少内容项目
MonoGame没有内容项目，而是一个名为"内容"的文件夹，老实说，它的行为就像项目一样。只需将XNA内容项目中的所有内容添加到此文件夹中，即可正常工作。太神了
然而，它未能做到的是从未编译的内容文件（例如myFont.spriteFont）加载声音和字体。对于MonoGame内容，声音和字体文件必须替换为XNA项目的编译版本。
此外，还有一个小麻烦——每个内容文件都必须标记为"始终复制"或"更新时复制"（默认为"从不复制"）。我真的没有找到一种方法来同时改变他们所有人，但这并不需要那么多时间。
问题#3：XNA项目正在自动解决导入问题
XNA项目有一个"语法糖"的优势。直到我切换到单声道，我才意识到这一点，但我从未在我的XNA项目中看到过一条名为"imports"的线路。我大量使用了这一点，拥有许多只有几行的小类，并使用了"Vector2"的"列表"等。在移植到MonoGame后，由于缺少导入，我不得不经历数百个编译错误。
我仍然想知道这是由XNA项目还是Visual Studio中的其他配置引起的，但我必须说我喜欢它。如果你对此有所了解，请分享。
结论：
回想起来，移植到MonoGame的过程花了我大约一个月的时间来弄清楚——但当我最终拥有所有的部分时，整个过程花了大约4个小时来完成100+源文件+100+内容文件项目。我想说MonoGame的人做得很好，修改模板以使用VB.Net.