Eiffel for .NET - what exactly is the state of play?

[Peter Lubke]

Can someone elucidate the state of Eiffel .NET development?

My understanding from the documentation was that .NET 1.0 and 1.1 were
(somewhat) supported.

But there is anecdotal evidence that at least .NET 2.0 has been tried
to some degree.

This may "just work" for those with just .NET 1.1 installed on a
Windows box. That seems to me how is "should" happen (doesn't work AT
ALL for me). My understanding is that certain assemblies are
automatically "consumed" to provide access from Eiffel - essentially
by linking to them and providing peer Eiffel classes - and that other
assemblies can be added as well.

Is there anyone authoritative for Eiffel .NET development or is it
just left to chance? (not a criticism - it's completely normal for
open source projects to have very uneven coverage)

Does EiffelStudio emit MSIL code directly? or does it rely on the C
compiler to do so?

Has anyone attempted to build a .NET version of EiffelStudio itself?

[Don't get defensive, I understand the difficulties involved.
EiffelStudio is a huge product and very very good, I just want to
evaluate whether it is suitable for what I want to do (leave
wage-slave conditions and contract program with tools and processes of
my own choosing). - but my prospective clients (dictated by my network
of industry contacts) have significant .NET infrastructure and the
ability to create WCF-style services (NOT Web services or ASP) is a must.]

[I have not yet been able to create an Eiffel .NET application on
either my Windows development machine (which has .NET 3.5 installed)
or my Linux x86-64 machine which has Mono installed.]

[Envision does not install on my Windows Box - I think the last time I
had Visual Studio 2003 on that machine was 2004. I have both Visual
Studio 2005 and Visual Studio 2008 installed. Five(5) years is a
complete IT generation - it's not just old, it's obsolete.]

[I have had great difficultly in compiling the EiffelStudio source on
either of these platforms - it takes about 6 hours on the Windows
machine (and often fails only at the end). The resulting executable
throws multiple "catcall detected" warnings and fails to precompile
(throwing an internal exception) a .NET application. I have not
succeeded in building EiffelStudio on Linux at all - compilation
errors and missing header files.]

.NET (and most particularly .NET 3.0) represent a HUGE opportunity for
Eiffel to compete with more mainstream development languages in
corporate software development. The ability to seamlessly integrate
with any library of service written in any other language would mean
that on a .NET platform it would not matter what language was used.

I'd like to recommend and use Eiffel professionally, but without
access to the .NET libraries, applications and services (especially
ones written by third parties) - there's no way in a month of Sundays
that it would happen.

[Hubert Cater]

Recently I began to explore Eiffel for .NET a bit more, due to the
movement from COM to .NET in general,  and I would be interested in its
current status or plans for the future as well.

I think .NET can provide a lot of opportunity to an Eiffel developer
such as myself when it comes to using 3rd party components, i.e. I
already use DirectX 7 in Eiffel via the EiffelCOM wizard and so my next
question is of course what would the difficulty be in having .NET
components wrapped into accessible Eiffel classes as was done with the
EiffelCOM wizard.

Of course I really don't know the technical difficulty of that approach
but at least it would eliminate the need to use Visual Studio and
provide an Eiffel plug-in etc., and it would be great to be able to
access these components natively via EiffelStudio alone.  May go a
longer way in popularizing the use of .NET via Eiffel as it seems that
Envision only supports older versions of Visual Studio and .NET
respectively.

Hubert

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Peter Gummer-2]

Hubert Cater wrote:

> I think .NET can provide a lot of opportunity to an Eiffel developer
> such as myself when it comes to using 3rd party components, i.e. I
> already use DirectX 7 in Eiffel via the EiffelCOM wizard and so my next
> question is of course what would the difficulty be in having .NET
> components wrapped into accessible Eiffel classes as was done with the
> EiffelCOM wizard.
>
> Of course I really don't know the technical difficulty of that approach
> but at least it would eliminate the need to use Visual Studio and
> provide an Eiffel plug-in etc., and it would be great to be able to
> access these components natively via EiffelStudio alone.

Hi Hubert,

EiffelStudio has been doing that for years. It happens invisibly in the
background. Usually, the only observable effect is that there is a delay
the first time you compile with a 3rd-party assembly, as EiffelStudio
"consumes" the assembly's .NET metadata.

It's far easier working with EiffelStudio and .NET than working with
EiffelStudio and COM.

- Peter Gummer

[Hubert Cater]

Hi Peter,

Thanks for the information since as I mentioned I have just now begun
investigating .NET due to my previous workloads.

I'll happily look into this further :)

Hubert


Peter Gummer wrote:

>
>
> Hubert Cater wrote:
>  > I think .NET can provide a lot of opportunity to an Eiffel developer
>  > such as myself when it comes to using 3rd party components, i.e. I
>  > already use DirectX 7 in Eiffel via the EiffelCOM wizard and so my next
>  > question is of course what would the difficulty be in having .NET
>  > components wrapped into accessible Eiffel classes as was done with the
>  > EiffelCOM wizard.
>  >
>  > Of course I really don't know the technical difficulty of that approach
>  > but at least it would eliminate the need to use Visual Studio and
>  > provide an Eiffel plug-in etc., and it would be great to be able to
>  > access these components natively via EiffelStudio alone.
>
> Hi Hubert,
>
> EiffelStudio has been doing that for years. It happens invisibly in the
> background. Usually, the only observable effect is that there is a delay
> the first time you compile with a 3rd-party assembly, as EiffelStudio
> "consumes" the assembly's .NET metadata.
>
> It's far easier working with EiffelStudio and .NET than working with
> EiffelStudio and COM.
>
> - Peter Gummer
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.169 / Virus Database: 270.6.17/1657 - Release Date: 9/6/2008 8:07 PM
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Emmanuel Stapf]

> Can someone elucidate the state of Eiffel .NET development?

Since the release of EiffelStudio 6.2, EiffelStudio will target the .NET runtime
2.0 or greater (I realize that greater doesn't mean anything since v3.0 and v3.5
are actually using version v2.0 of the .NET runtime). The only restrictions are on
the consumption part, that is to say the use of pure .NET components and the only
major restriction is the lack of consuming .NET generic types. If someone has some
time on his hand to allow consumption of .NET generic types, please contact me.
 
> Does EiffelStudio emit MSIL code directly? or does it rely on the C
> compiler to do so?

EiffelStudio directly emits MSIL code.
 
> Has anyone attempted to build a .NET version of EiffelStudio itself?

Nope because EiffelStudio relies on some hidden mechanisms of the Eiffel runtime
which are not present in .NET. However, there are many applications out there that
have been compiled successfully in either .NET mode or classic mode.
 
> [I have not yet been able to create an Eiffel .NET application on
> either my Windows development machine (which has .NET 3.5 installed)
> or my Linux x86-64 machine which has Mono installed.]

Currently the .NET code generation only works on Windows (because we used some
Microsoft API to generate the metadata in order to get debugging and those APIs
are missing in Mono). Binaries generated on Windows for .NET can possibly be
executed on Linux using Mono.

Regarding .NET 3.5 it should work out of the box. I've just installed it to verify
that (strangely 3.5 never showed up as a Microsoft Update).
 
> [Envision does not install on my Windows Box - I think the last time I
> had Visual Studio 2003 on that machine was 2004. I have both Visual
> Studio 2005 and Visual Studio 2008 installed. Five(5) years is a
> complete IT generation - it's not just old, it's obsolete.]

The latest version of Envision only works with Visual Studio 2003 and we did not
pursue further development on it and decided instead on focusing our efforts on
EiffelStudio.

> [I have had great difficultly in compiling the EiffelStudio source on
> either of these platforms - it takes about 6 hours on the Windows
> machine (and often fails only at the end). The resulting executable
> throws multiple "catcall detected" warnings and fails to precompile
> (throwing an internal exception) a .NET application. I have not
> succeeded in building EiffelStudio on Linux at all - compilation
> errors and missing header files.]

Compiling EiffelStudio on a decent machine only takes about 10 minutes at most
(this does not include getting the source code which depends on the speed of your
internet connection). You should use the instructions located at
http://dev.eiffel.com/Compiling_EiffelStudio as instructions. Feel free to post
questions on the development forums of EiffelStudio if you have any issue with it
(http://eiffelstudio.origo.ethz.ch/forum).

Hope this helps,
Manu