Vulcan Projects: Trying to compile with X#

[George]

Chris,

I also think so.

But unfortunately, I cannot use Vulacn compiled Assemblies for new X# Apps.
The generated error is:

C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Softway.Common, Version=1.5.1.1, Culture=neutral, PublicKeyToken=null", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

and of course in Vulcan, there is no other way to produce assemblies.

Also, if I try to use the Vulcan assembly:
USING Softway.Common, the error is:

C:UsersGeorgeDocumentsVisual Studio 2015ProjectsXSharpWindowsFormsApplication2Program.prg(6,7): error XS0434: The namespace 'Softway' in 'Softway.Common, Version=1.5.1.1, Culture=neutral, PublicKeyToken=null' conflicts with the type 'Softway' in 'Softway.Common, Version=1.5.1.1, Culture=neutral, PublicKeyToken=null'


On the other hand, I built a simple X# DLL and tried to use into a simple Vulcan EXE project.
The error is:
'You must build the target project before it can be referenced'.

Both projects are built. I also tried to compile the X# DLL targeting x86: same error.

regards
George

[Chris]

Hi George,

Just set the Platform Type for the x# app (in project options, General tab) to x86 and it should work. Vulcan produces 32bit only dlls, so in order to use them, the executable must also be 32bit only, otherwise the JIT compiles it in 64bit mode machine code and fails when tries to load the 32bit dll at runtime.

Chris

[George]

Hi Chris,

let's consider the 2 following scenarios:

1. XIDE Projects:
I created an X# library Library1 (Dialect X#):
USING System
USING System.Windows.Forms

PARTIAL CLASS Library1
CONSTRUCTOR()
MessageBox.Show("Hello", "MyApps", MessageBoxButtons.OK, MessageBoxIcon.Warning)
RETURN
END CLASS

it builds and compiles fine.

Then I changed the Dialect to Vulcan.NET and referenced VulcanRT, VulcanRTFuncs:
error XS0101: The namespace '<global namespace>' already contains a definition for 'Library1' 8,2 File1.prg Library1
Compilation failed (1 error)

Then, I changed again the Dialect to X# and I created a Vulcan WinForms Application:

[STAThreadAttribute];
FUNCTION Start( asCmdLine AS STRING[] ) AS INT
LOCAL nExitCode AS INT
LOCAL oForm AS BasicForm
Application.EnableVisualStyles()
Application.DoEvents()
LOCAL oLibrary1 := Library1{} AS Library1
oForm := BasicForm{}
Application.Run(oForm)
RETURN nExitCode

The App compiles and runs fine only this way.
Please note also, in XIDE the App compiles even if I changed the platform to AnyCPU !!!


2. I created the same Projects in VS2015. There, the error generated constantly either I choose Vulcan or X# as Dialect (always x86).
The behaviour is different in XIDE and VS2015.

I am attaching the XIDE and VS2015 Projects.

regards
George

[Chris]

Hi George,

The compiler error you are getting on Library1 when compiling it is because the name of the class is the same as the name of the assembly (both "Library1"), if you change either of them, it will compile fine, it's the issue we discussed in a previous post. I am surprised this is supported already in the core dialect, though! Had not noticed this! So maybe it's not too difficult to allow this for the VO/vulcan dialect as well, will check with Robert and will get back to you about this.

About the vulcan app consuming the x# dll, this works no matter what platform options you have used, because vulcan always produces 32bit assemblies, not 64bit or AnyCPU. This means that when you run the vulcan app, the JIT compiles the code in 32 bit machine code. When it needs to load the library, its only option is to use it in 32 bit mode, too, so it JITs the dll code in 32 bit, too. That is, if the platform selected for the dll is AnyCPU (meaning allow the dll to run in either 32bit or 64bit mode) or x86. You would get a (runtime) error only if you had set the platform target of the library to x64, this way it would not be possible to use it from a 32 bit exe.

Btw, you wrote "The App compiles and runs fine only this way.". Do you mean you could not get it to work in some other way?

About the VS problem when referencing the x# library from a vulcan app, maybe this is a problem with the vulcan VS integration? At least it sounds very familiar.. What happens if you try to add a reference to a c# library in the same way? In any case, it should be possible to workaround this by adding the reference directly to the dll file via browse, instead using it as a project reference.

hope this helps!

Chris

[George]

Chris,

>Btw, you wrote "The App compiles and runs fine only this way.". Do you mean you could not get it to work in some other way?

I meant if you change (in XIDE) the Library1 from Core to Vulcan Dialect, it doesn't compile as you see before (error XS0101).
Also, please note I didn't change Namespace, AssemblyName. Just kept the XIDE generated properties.
The XIDE is smart enough to link the Library1 to Vulcan App in 'AnyCPY' and 'x86' mode.

>About the VS problem when referencing the x# library from a vulcan app, maybe this is a problem with the vulcan VS integration? At least it sounds very familiar.. What happens if you try to add a reference to a c# library in the same way? In any case, it should be possible to workaround this by adding the reference directly to the dll file via browse, instead using it as a project reference.

Yes, it's a problem with the Vulcan VS integration: when I referenced the DLL instead of the Project's Reference, it works just like XIDE in both 'AnyCPY' and 'x86' modes.

Of course, in 'AnyCPU' mode when the VulcanRT and VulcanRTFuncs are referenced, the compiler correctly generates the warning:

C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "VulcanRTFuncs, Version=4.0.401.0, Culture=neutral, PublicKeyToken=0e73a8bf006af00c", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

best regards
George

[Chris]

Hi George,

>>>
I meant if you change (in XIDE) the Library1 from Core to Vulcan Dialect, it doesn't compile as you see before (error XS0101).
>>>

OK, but this error happens only when you have a class name with the same name as the assembly name. Is this something that you really depend on?


>>>
Of course, in 'AnyCPU' mode when the VulcanRT and VulcanRTFuncs are referenced, the compiler correctly generates the warning:
C:Program Files (x86)MSBuild14.0binMicrosoft.Common.CurrentVersion.targets(1820,5): warning MSB3270: There was a mismatch between the processor architecture
>>>


That doesn't come from the compiler actually, it is coming from MSBuild/VS itself. You don't see such a message from XIDE, because XIDE just doesn't make such a mismatch check


regards,
Chris

[George]

Chris,

>>>
I meant if you change (in XIDE) the Library1 from Core to Vulcan Dialect, it doesn't compile as you see before (error XS0101).
>>>

>OK, but this error happens only when you have a class name with the same name as the assembly name. Is this something that you really depend on?

The real answer is Yes. I can change-it of course in my Libraries, but, look at the second issue below.
Is-it denied only for the Vulcan Dialect ?


In XIDE, I created the empty Library Library1. Then a new empty X# code file with the code:

USING System
USING System.Windows.Forms

PARTIAL CLASS Library1
CONSTRUCTOR()
MessageBox.Show("Hello from Library1", "Library1", MessageBoxButtons.OK, MessageBoxIcon.Warning)
RETURN
END CLASS

without changing anything, the Compiler succeeds!

By changing the Dialect from Core to Vulcan (and adding the VulcanRT/VulcanRTFuncs), generates the error:

error XS0101: The namespace '<global namespace>' already contains a definition for 'Library1' 8,2 File1.prg Library1
Compilation failed (1 error)

So, in X# the same Namespace/AssemblyName works fine but not in Vulcan Dialect!

regards
George

[Chris]

Hi George,

Yes, this error occurs only in the Vulcan/VO dialects, it's because of a name conflict with the compiler generated class that holds functions etc. In the vulcan/VO dialects this is generated in a different way (vulcan-compatible) than in Core.

This limitation will most likely be removed in one of the next builds, but for now I'd suggest just slightly changing the name of the assembly or class name. If it is very important for those to have the exact same name, then maybe you can use an extra dll in core that only inherits the real implementation of the class in a helper dll.

Chris

[George]

Chris,

>Yes, this error occurs only in the Vulcan/VO dialects, it's because of a name conflict with the compiler generated class that holds functions etc. In the vulcan/VO dialects this is generated in a different way (vulcan-compatible) than in Core.

Fine.

>This limitation will most likely be removed in one of the next builds, but for now I'd suggest just slightly changing the name of the assembly or class name. If it is very important for those to have the exact same name, then maybe you can use an extra dll in core that only inherits the real implementation of the class in a helper dll.

Tes, I will.

thank you
George