eiffel-org/documentation/23.09/solutions/dotnet/eiffel-net-language/eiffel-net-integration.wiki

[[Property:modification_date|Fri, 29 Sep 2023 08:01:26 GMT]]
[[Property:publication_date|Wed, 27 Sep 2023 19:33:07 GMT]]
[[Property:title|Eiffel for .NET Integration]]
[[Property:weight|3]]
[[Property:uuid|fe8a6a7d-4590-0db2-d59a-307082b18ecc]]
==Differences between Eiffel and Eiffel for .NET==

===Limitation of Eiffel for .NET in version 23.09===

Most of the Eiffel mechanisms are supported in 23.09. 

Eiffel for .NET supports:
* Multiple Inheritance
* Design By Contract
* Exception handling
* Genericity
* Covariance
* Compilation of any existing Eiffel libraries as long as it does not include C externals that call into the Eiffel Software C runtime

However, there are a few limitations that are described later in this documentation.

===Added to Eiffel and Eiffel for .NET===

The following syntax can be used to declare .NET custom attributes on Eiffel entities (features and classes):
<code>
    empty: BOOLEAN
        note
            description: "Is Current empty?"
            metadata: create {OBSOLETE_ATTRIBUTE}.make ("Use `is_empty' instead") end
        obsolete
            "Use is_empty instead"
        do
            Result := is_empty
        end
</code>

The previous example shows the declaration of the obsolete feature <code> empty </code> . The custom attribute defined by <code>OBSOLETE_ATTRIBUTE</code> is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the <code>note</code> clause <code>metadata</code>. The definition consists of a creation expression that creates the custom attribute with the right parameters. 

Using the <code>metadata</code> tag is the most general way of applying a custom attribute. There are however some variations that are explained below:
*<code>metadata</code>: most general way, it applies a custom attribute to both the class and interface generated by the Eiffel compiler.
*<code>class_metadata</code>: applies only to the class generated by the Eiffel compiler (mostly for advanced users).
*<code>interface_metadata</code>: applies only to the interface generated by the Eiffel compiler (mostly for advanced users).
*<code>property_metadata</code>: applies a custom attribute to the associated property generated by the Eiffel compiler for a query.
*<code>assembly_metadata</code>: applies a custom attribute for the current assembly. It only works when present in the Eiffel system root class <code>note</code> clause.

==Differences between Eiffel for .NET and .NET==

===Covariance===

The CLR (Common Language Runtime) does not support [[ET: Inheritance#Covariance and anchored declarations|covariance]] due to a type safety issue that full covariance implies (known as a polymorphic [[ET: Inheritance#Catcalls|catcall]] in Eiffel). Although very rare, catcalls are not suitable to .NET where safety is one of the primary goals. 

Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a catcall. So when a catcall is going to be performed a `Invalid Cast Exception` will be raised by the CLR instead of an unexpected behavior as is the default behavior in classic Eiffel (i.e., the behavior without catcall detection explicitly enabled). 

Another advantage of Eiffel for .NET's implementation of covariance is that it can be easily understood by CLS compliant consumer tools. These tools will actually benefit from the Eiffel for .NET covariance. 

===Genericity===

The .NET Framework does not support generics at all, so that the following Eiffel for .NET classes:
*  <code>LIST [ANY]</code> 
*  <code>LIST [INTEGER]</code> 

will actually be generated as:
*  <code>LIST_ANY</code> 
*  <code>LIST_Int32</code> 

Meaning that if one wants to reuse an Eiffel generic class from another language than Eiffel for .NET, one has to use either <code>LIST_ANY</code> or <code>LIST_Int32</code>. 

WARNING: The .NET Core has support for generics, however this is not yet integrated by Eiffel .NET (it will be part of future releases).

===Enum types===

Eiffel for .NET supports .NET enum types implicitly. From the point of view of Eiffel, they are just considered as expanded classes. The only difference is in the code generation. Eiffel for .NET cannot declare new enum types yet. 

===ByRef===

Eiffel does not have the notion of `byref` argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument. 

==Eiffel Compatibility with .NETCore 6.0 and Above ==

===Limitations with Generics Classes and Features===

Currently, Eiffel does not support the use of `Generics` Classes and `Features` when consuming .NET assemblies.
And the compiler does not yet use .NET generic for code generation

==== Workaround====

In some cases, it's possible to create a C# library to access these features using a `Facade` pattern. However, there are instances where creating a Facade is not feasible, such as with `Avalonia UI` or `EntityFramework` where it is required to use generic to instantiate main components.

===Limitations with "init" Only Setters===

Eiffel currently does not support the special `init` property that is only initialized in a block of code as part of the object initialization. More details can be found in the [https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/init C# 9.0 proposal]

====Workaround====

A potential workaround is to create a C# library that uses a Factory pattern to build the required instance.

===Executing .NET Applications from EiffelStudio: Limitations===

Currently, some types of applications cannot be executed directly from the EiffelStudio IDE. For example Web APIs.

====Workaround====

As a workaround, you can execute the application from the command line. Use the `dotnet` tool with the following syntax: `dotnet <app_name>`.


===Debugging .NET Applications from EiffelStudio: Limitations===

At the moment, EiffelStudio does not provide any support for debugging Eiffel .NETCore directly from the IDE.

====Workaround====

A potential solution is to use the C# wrapper project generated by the Eiffel compiler (in W_code or F_code directory). VisualStudio can open this C# wrapper (via the associated `.csproj` file), and thus the associated Eiffel output (dll or exe), and after configuring Debugging profile within VisualStudio  , it is possible to debug the code.


===Eiffel .NETCore Types of SDKs: Limitations===

In the current version, Eiffel .NETCore does not support directly different types of SDKs such as `Microsoft.NET.Sdk.Web`. The generated C# wrapper only target `Microsoft.NET.Sdk`.

====Workaround====

For other types of applications like Web APIs, you need to manually provide a `.csproj` file with the required SDKs and package dependencies. This allows the application to run and, if necessary, use VisualStudio to debug.


==Publishing the Eiffel Solution: Using the Generated C# Wrapper==

To publish the Eiffel solution on current platform or targeting other platform, use the `dotnet` tool on the generated C# wrapper project.