Some issues with the /ins compiler option

[cpyrgas]

1. When using the /ins+ compiler option but there's no reference to XSharp.dll (so Core dialect), the compiler silently seems to ignore it. I think there should be a compiler error in this case.

2. The documentation about /ins (https://www.xsharp.eu/help/opt-ins.html) needs to be updated to clarify this, either if the above becomes a compiler error or if it stays as it is

3. There's also a typo in the documentation, mentioning VulcanImplicitNamespaceAttribute instead of ImplicitNamespaceAttribute.

[RobertvanderHulst]

The /ins compiler option tells the compiler to scan the referenced assemblies for attributes of type ImplicitNamespaceAttribute or VulcanImplicitNamespaceAttribute. When such an attribute exists, namespaces announced with this attribute are automatically included.
So the compiler needs to either have a reference to the X# runtime DLL or the Vulcan Runtime DLL, to be able to resolve one of these two types.
However, if you have declared this type in your code, that should work too.

[wriedmann]

I have tried to add the attribute class in my library (in its own namespace).
`begin namespace PostgreSQLHelper
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple := true)];
sealed class ImplicitNamespaceAttribute inherit Attribute
private initonly _namespace as string
property Namespace as string get _namespace

constructor(namespace as string)
_namespace := namespace

end class
end namespace`
But when using this library it does requests the using statement.
It does not helps also to add that class to the XSharp.Internal namespace (that could lead also to conflicts).

[RobertvanderHulst]

The compiler searches for the fully qualified name, so it has to be in the right namespace.
I am not sure that I understand the problem that you're trying to solve.
Do you want to compile in the Core dialect without referencing XSharp.Core?
Then there should be no conflicts.

[wriedmann]

Let me explain: we have several X# COM libraries that we are using in our VO applications. All of them are in Core dialect and are not using the X# runtime.
When migrating these VO applications to X#, the COM libraries are added as normal references, but to use them we need to specify the using statement in every place where classes from these library are used. The migrated VO applications are compiled using the /ins compiler switch, the VO dialect and (of course) the XSharp.Core.dll.
Defining the attribute in the XSharp namespace in the COM library works, but creates (obviously) conflicts when compiling the migrated application.
IMHO the only solution would be if the compiler looked in the assembly if there is such an attribute not only in the XSharp namespace, but also in the global namespace of the library. In this way we could benefit from this mechanism also in our own libraries-

[RobertvanderHulst]

Wolfgang,
I think what you really need is a "global using", which allows you to specify namespaces in one location of your code and which makes the namespace available everywhere in your code. This is one of the new things that we're adding in X# 3.

[wriedmann]

Hi Robert,
yes, this was something Andreas and me also thougt about, but we tried to solve it now because we are working on some migrations (and are really happy with the compatibility of the X# compiler to VO as we are effectively sharing prg files beween VO and X#).

[RobertvanderHulst]

Wolfgang,
In that case you could try this:

• Add a header file to your project folder, and put the USING statements in there
• From this header file you include our standard header file
• Use the compiler option to use your header file instead of our header file