Vulcan Projects: Trying to compile with X#

[George]

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:UsersGeorgeDocumentsVisual Studio 2015ProjectsXSharpRemoteObjectLibrarydotNetReactor.prg(7,1): error XS0101: The namespace '<global namespace>' already contains a definition for 'RemoteObjectLibrary'

and:
C:UsersGeorgeDocumentsVisual Studio 2015ProjectsXSharpRemoteObjectLibraryRemoteObjectLibrary.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

[Chris]

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

[George]

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:UsersGeorgeDocumentsVisual Studio 2015ProjectsXSharpSoftway.CommonRemoteObjectClientRemoteObjectClient.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

[robert]

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

[George]

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

[Chris]

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

[George]

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

[George]

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

[George]

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

[Chris]

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