Subversion and .NET

[Arild Fines <ar...@broadpark.no>]

We are a group of 3 students who are working on integrating Subversion into
Visual Studio. NET for our final year project at Oslo University College.
Some of you may remember the initial posts made to the list about this a
couple of months ago. Since then, CollabNet has agreed to fill the role of
employer for our project.

After a period of exams and of doing administrative stuff related to the
project(academia...:-|) we are now at the stage where we can actually begin
to write some code(woohoo!). Since the addin itself is going to be written
in C#, we need to make the Subversion client API available to .NET
languages. We believe there are three alternatives for doing this:

o SWIG - From several discussions on this list, we have received the
impression that SWIG is the preferred way to wrap the Subversion client API.
However, for us this approach has several disadvantages:
	- .NET/C# is not (yet?) a supported target for SWIG. This means we might
have to implement this support ourselves, and this is probably not
achievable within our timeframe.
	- None of us are familiar with SWIG(Ok, this is not a major problem, but
still...)
	- The existing SWIG bindings for SVN doesnt appear to be working too well
on Windows yet. Is this related to the fact that SVN on Windows still is
just a set of static libraries?

o P/Invoke - P/Invoke is the standard .NET mechanism for accessing unmanaged
APIs. However, it requires us to mirror every type and every function from
the Subversion API that we need to access in C#. Given the size of the API,
this is: a) A PITA to implement and maintain. b) A pretty fragile solution.
P/Invoke also requires dynamic libraries, which SVN doesn't yet have on
Windows(any timeframe on this?)

o Managed C++ - MC++ allows us to write mixed assemblies - eg, assemblies
containing both managed and unmanaged code. This means we can write a single
DLL which links to the SVN .libs, and that exposes a managed interface for
consumption by managed languages. This approach works equally well with both
dynamic and static libraries.

Currently, we are leaning towards the last solution, but we would be very
interested in hearing input from other people on this.

--
Arild Fines, Kristin Borud and Per Krämer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion and .NET

[Marcus Hettlage <he...@tigris.org>]

I've already done something like that.
I've used a high-level C++ class, that I converted into a classical
Win32-DLL that exports C-style functions.
This DLL is then accessed via P/Invoke from .NET.
If I find the time to do the finishing touches I'll be releasing it at
the end this month.

I'd agree, that using P/Invoke is probably not the best idea.
But it worked for me. I'd like to do a mixed (managed/unmanaged)
C++ DLL, but I've had not yet the time to explore it.


----- Original Message -----
From: "Arild Fines" <ar...@broadpark.no>
To: "Subversion Developers Mailing List" <de...@subversion.tigris.org>
Cc: "Kristin Borud" <ab...@frisurf.no>; "Per August Krämer"
<pe...@perkramer.com>
Sent: Monday, February 03, 2003 7:04 PM
Subject: Subversion and .NET


> We are a group of 3 students who are working on integrating Subversion
into
> Visual Studio. NET for our final year project at Oslo University College.
> Some of you may remember the initial posts made to the list about this a
> couple of months ago. Since then, CollabNet has agreed to fill the role of
> employer for our project.
>
> After a period of exams and of doing administrative stuff related to the
> project(academia...:-|) we are now at the stage where we can actually
begin
> to write some code(woohoo!). Since the addin itself is going to be written
> in C#, we need to make the Subversion client API available to .NET
> languages. We believe there are three alternatives for doing this:
>
> o SWIG - From several discussions on this list, we have received the
> impression that SWIG is the preferred way to wrap the Subversion client
API.
> However, for us this approach has several disadvantages:
> - .NET/C# is not (yet?) a supported target for SWIG. This means we might
> have to implement this support ourselves, and this is probably not
> achievable within our timeframe.
> - None of us are familiar with SWIG(Ok, this is not a major problem, but
> still...)
> - The existing SWIG bindings for SVN doesnt appear to be working too well
> on Windows yet. Is this related to the fact that SVN on Windows still is
> just a set of static libraries?
>
> o P/Invoke - P/Invoke is the standard .NET mechanism for accessing
unmanaged
> APIs. However, it requires us to mirror every type and every function from
> the Subversion API that we need to access in C#. Given the size of the
API,
> this is: a) A PITA to implement and maintain. b) A pretty fragile
solution.
> P/Invoke also requires dynamic libraries, which SVN doesn't yet have on
> Windows(any timeframe on this?)
>
> o Managed C++ - MC++ allows us to write mixed assemblies - eg, assemblies
> containing both managed and unmanaged code. This means we can write a
single
> DLL which links to the SVN .libs, and that exposes a managed interface for
> consumption by managed languages. This approach works equally well with
both
> dynamic and static libraries.
>
> Currently, we are leaning towards the last solution, but we would be very
> interested in hearing input from other people on this.
>
> --
> Arild Fines, Kristin Borud and Per Krämer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion and .NET

[Branko Čibej <br...@xbc.nu>]

Arild Fines wrote:

>I'm starting to think that maybe a 2 layer API would be the way to go: A
>very low level API that merely maps the svn_client_* calls to managed
>methods, and a higher level API on top of that modelling SVN managed
>resources such as files and directories, as well as remote repositories.
>  
>
That sounds like the right approach to me, too. We're doing something
similar in the Python SWIG bindings, too, and it seems to be working out
pretty well.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: Subversion and .NET

[Arild Fines <ar...@broadpark.no>]

news wrote:
> Hi
>
> Arild Fines wrote:
> [...]
>> o Managed C++ - MC++ allows us to write mixed assemblies - eg,
>> assemblies containing both managed and unmanaged code. This means we
>> can write a single DLL which links to the SVN .libs, and that
>> exposes a managed interface for consumption by managed languages.
>> This approach works equally well with both dynamic and static
>> libraries.
>>
>> Currently, we are leaning towards the last solution, but we would be
>> very interested in hearing input from other people on this. [...]
>
> If you like to hear my 2c ...

Wouldn't have asked if we didn't :-)

> I think there are two alternatives: with or without peer classes.
> I would recommend to read the following article about how the Eclipse
> team solved this problem for SWT:
> http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
> Just replace "widget" with SVN/APR resource (pool, token, etc.).

I have read that article before, but hadn't thought of it in this context.
It is an interesting approach.

I'm starting to think that maybe a 2 layer API would be the way to go: A
very low level API that merely maps the svn_client_* calls to managed
methods, and a higher level API on top of that modelling SVN managed
resources such as files and directories, as well as remote repositories.

--
Arild


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion and .NET

[Oliver Geisser <ol...@gmx.de>]

Hi

Arild Fines wrote:
[...]
> o Managed C++ - MC++ allows us to write mixed assemblies - eg, assemblies
> containing both managed and unmanaged code. This means we can write a single
> DLL which links to the SVN .libs, and that exposes a managed interface for
> consumption by managed languages. This approach works equally well with both
> dynamic and static libraries.
> 
> Currently, we are leaning towards the last solution, but we would be very
> interested in hearing input from other people on this.
[...]

If you like to hear my 2c ...

I have thought about this problem, too. I would use managed C++
to wrap the SVN C API as you describe above.

With our team at work we have done something similiar. We wrapped
a unmanaged C++ API with managed classes.

Another interesting problem is related to resource management (for 
example pools) in the unmanaged world.

I think there are two alternatives: with or without peer classes.

I would recommend to read the following article about how the Eclipse
team solved this problem for SWT: 
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Just replace "widget" with SVN/APR resource (pool, token, etc.).

Olli

-og



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Subversion and .NET

[Branko Čibej <br...@xbc.nu>]

Arild Fines wrote:

>	- The existing SWIG bindings for SVN doesnt appear to be working too well
>on Windows yet. Is this related to the fact that SVN on Windows still is
>just a set of static libraries?
>  
>
No, it's because nobody has had the time and/or inclination to automate
the SWIG build on Windows. As far as I know, one or two people have
managed to build the bindings by hand, but that's it.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org