There are a lot of small issues. Some of them should be listed here:

• You are using a method Open() in any of your VO windows classes? This will not compile anymore because the Window class has a variable oPen that conflicts with this method name
• you are using '-' in resource paths? For example something like this:

icoFett Icon c:\cavowork\brandnamic\ba-erp\icons\Fett.ico

You need to surround the filename with double apostrophes like this:

icoFett Icon "c:\cavowork\brandnamic\ba-erp\icons\Fett.ico"

• _CodeBlock class: if you are using subclasses of the _CodeBlock class: the Eval method in VO is using the Clipper calling convention, the one in the Vulcan runtime the Strict calling convention
• Functions or methods that pass an object by reference, and you pass a inherited object. This code

function CleanUpServer( oServer ref DataServer ) as void
oServer:Close()
oServer := null_object
return

compiles in VO without any issue when you call it with any subclass of DataServer or DBServer. This is very dangerous and therefore it will not work anymore in X#.

• Local static in VO is currently (X# 1.1.2) not recognized by the X# compiler, but is valid in VO. Change it to static alone in your VO code.
• Access/Assign Font cannot work anymore because there is also a method. Change to :ControlFont, that should also work on the VO side. For bBrowser use :DataFont
• never versions of the VO GUI classes contain an access IsDisabled in the class Control. This is missing in the .NET classes. The same is true for the methods IsStyle() and GetStyle(). Add these methods to you X# version of the GUI classes, or write your own methods.
• DynToOldSpace() is not supported anymore. Replace in your code by MemAlloc()/MemFree()
• if you use CreateInstance() on classes that have no constructor, you will receive a runtime error. Add Init() methods to all of your classes on the VO side.
• the function B64EncString() is missing from the Vulcan runtime library
• dword and int are two different parameter types. If you have a dword parameter in one class and a int parameter in a subclass (or the way around), the .NET runtime will treat them as different methods and call the one or the other based on the parameter type. This is true only for strong typed methods (for the others, the parameters are alway typed as usual).