fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Vulcan Projects: Trying to compile with X#

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #1

Hi,

today, I downloaded the X# beta 0.9 and tried to compile several Vulcan projects without success.
Of-course I will send you more detailed information asap.

The XPorter succesfully imported all the Vulcan Solutions/Projects I tried, but it wasn't possible to build noone :)except a small DLL project having just 2 .prgs.
This small project named 'RemoteObjectLibrary' (it contains a single Class 'RemoteObjectLibrary'), hadn't NAMESPACE definition inside the .prgs, but the Default Namespace in Properties (the assembly's name).

Compiling with X#, the Compiler complained:
C:\Users\George\Documents\Visual Studio 2015\Projects\XSharp\RemoteObjectLibrary\dotNetReactor.prg(7,1): error XS0101: The namespace '<global namespace>' already contains a definition for 'RemoteObjectLibrary'

and:
C:\Users\George\Documents\Visual Studio 2015\Projects\XSharp\RemoteObjectLibrary\RemoteObjectLibrary.prg(82,54): error XS0246: The type or namespace name 'RemoteObjectLibrary' could not be found (are you missing a using directive or an assembly reference?)

The errors disapeared when I put BEGIN/END NAMESPACE to 2 prgs.

This is a simple project but some of my projects have several .prgs without the BEGIN/END NAMESPACE.
Is-there a workaround to bypass the errors and compile these projects ?

regards
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #2

Hi George!

>>>
This small project named 'RemoteObjectLibrary' (it contains a single Class 'RemoteObjectLibrary'), hadn't NAMESPACE definition inside the .prgs, but the Default Namespace in Properties (the assembly's name).
>>>

It's no problem at all not having BEGIN NAMESPACE statements, the issue here is that it is not allowed to declare a class name with the same name as the assembly name, this is enforced by the c# compiler backend (roslyn). This is a known difference to vulcan that we will probably remove in a future build, but for now if you change the assembly name to something slightly different, it should be OK.

Btw, normally roslyn does not allow many more things like that, for example it is by default not allowed to define a field with the same name as the containing class, a local with the same name with a method or the class etc. But we have modified the roslyn code so most of those are now supported in x#, you just stumbled upon one of the very few related cases still not allowed.

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #3

Hi Chris,

Yes. By renaming the Asembly name, it worked.
Now I am trying the most important Common DLL (base of my dozens projects).

I see 154 errors, but mainly they are:
- Use of unassigned local variable '...'
things that I can easily fix.

I also realized I have to remove prgs like:
ChangeLogonPasswordDialog.Designer.prg
from the Project.
Some of my projects are dated back to 2007-2008 (VS 2005).

Question about error XS1690:
C:\Users\George\Documents\Visual Studio 2015\Projects\XSharp\Softway.Common\RemoteObjectClient\RemoteObjectClient.prg(254,56): error XS1690: Accessing a member on 'RemoteObjectLibrary.Users' may cause a runtime exception because it is a field of a marshal-by-reference class

this code line (254,56) access the 'oRemoteObject:Users', an Exported member of the CLASS:
[assembly: SecurityRules(SecurityRuleSet.Level2)]
[Serializable()];
[SecurityCritical];
PARTIAL CLASS RemoteObjectLibrary INHERIT System.MarshalByRefObject
EXPORT Users AS INT

what may-I do in this situation ?
Is-there a compiler switch for that ?

Thank you
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #4

George,
Since we are building on top of the Roslyn (= C# & VB) compiler we share a lot of the error messages with C#. Expect that our error messages start with XS where the error messages of C# start with CS.
If you google for CS1690 you will find the following page:

https://msdn.microsoft.com/en-us/library/x524dkh4.aspx

This page also explains the problem and how you can solve it.
Now the big question of course is why you are inheriting from MarshalByRefObject and then exposing the instance variable (field) publicly ?

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Last edit: by robert.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #5

Robert,

thank you for your answer.
I resolved my problem just puting the accessed oRemoteObject:Users to a LOCAL variable.

>Now the big question of course is why you are inheriting from MarshalByRefObject and then exposing the instance variable (field) publicly

I use this Object inherited from MarshalByRefObject for remoting purposes.
It runs on the Server and all my client Apps are attaching to it from client PCs using: Port (and/or via Ftp), UserName, Password to read necessary information.

thanks a lot
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #6

Hi George,

>>>
I see 154 errors, but mainly they are:
- Use of unassigned local variable '...'
things that I can easily fix.
>>>

Those are not really errors, they are only compiler warnings that you can chose to ignore if you want. It's just because Warnings As Errors in the project properties is set to True by default that they appear as errors. Setting the to False will allow your project to compile and you can also disable those specific warnings by entering their warning number (165) in the Suppress Specific Warnings option. You can specify multiple warnings that you want to disable by separating them with a semicolon as in 165;9001;9002

hth!

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #7

Chris,

>Those are not really errors, they are only compiler warnings that you can chose to ignore if you want.

I know but I'd prefere to work 'by the book', so I will eliminate all the warnings because this way I can found eventually bugs and produce a more stable Assembly.

regards
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #8

Hi,

my 'Common' Vulcan DLL Assembly compiled fine with X#.
To avoid some warnings about pointers' unsafety, I specified:
Allow unsafe code: TRUE.
At the end, no errors, no warnings.

The Vulcan DLL's size was: 662 KB
The X# DLLs' size using Optimize: TRUE in Build Properties is: 486 KB
The X# DLLs' size using the Optimize: FALSE (default) in Build Properties is: 520 KB

Question: Must-I compile also the App with X# in order to run-it ?
I tried to run the Vulcan produced EXE with the X# produced DLL and the program didn't start.
I used of-course the Optimize: FALSE (default) switch.

Initially, I confused because the Vulcan's DLL name ends with '.Common.DLL' and the X# DLL name ends with '_Common.DLL', and I renamed the DLL on the second run.
The Namespace is the same in both languages.

In other words, I expected the App to run in the .NET environment. What am-I missing ?

regards
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #9

The answer to my previous question, I thing it's rather a question of the ban to have the same Namespace as AssemblyName.

I compiled one of my Apps with X#, referencing the X# compiled Assemblies and this way, it works.

regards
George

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #10

Hi George,

Thanks for your feedback, very glad to hear about another application working now in x#!

About compiling the exe, probably some things in the public interface of your libraries have changed when you recompiled in x#, so it is a little different to what the already compiled exe expected. Recompiling the exe with _either_ x# or vulcan should work now.

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #11

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)\MSBuild\14.0\bin\Microsoft.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:\Users\George\Documents\Visual Studio 2015\Projects\XSharp\WindowsFormsApplication2\Program.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

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #12

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
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #13

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

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #14

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
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #15

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)\MSBuild\14.0\bin\Microsoft.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

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #16

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)\MSBuild\14.0\bin\Microsoft.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
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #17

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

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #18

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
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Vulcan Projects: Trying to compile with X# 2 years 1 month ago #19

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

Please Log in or Create an account to join the conversation.

  • Page:
  • 1