headers
Avery Pennarun | 15 Oct 22:48

Using Mono.Options in MS.NET

Hi,

I just read Miguel's posting about Mono.Options being included in Mono
2.2.  I agree that Mono.Options is great; in fact, I include a copy of
it in several of the problems we've built at work.  It doesn't
particularly require mono, so it works fine under MS.NET.

There are a few other libraries in a similar vein, such as Miguel's
Mono.Terminal.

Now that Mono.Options is included in Mono 2.2, will it still be
available separately?  If not, it will be hard to build
Windows-compatible programs that use it, unless people go digging
throug the mono sources and extracting the libraries they like.  I
think it might be helpful to separate "mono libraries that add
functionality to any .Net application" and "mono libraries that
implement the MS class library" into two different projects.

Am I missing something?

Thanks,

Avery
Permalink | Reply |
headers
Paul | 16 Oct 08:30

Re: Using Mono.Options in MS.NET

Hi,

> Now that Mono.Options is included in Mono 2.2

2.2? We've only just had the official release of 2.0! I've not seen
anything on this list over a 2.2 release with tarballs or are you
talking about svn?

TTFN

Paul
--

-- 
Sie können mich aufreizen und wirklich heiß machen!

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Permalink | Reply |
headers
pablosantosluac@terra.es | 16 Oct 14:25
Favicon

Re: Using Mono.Options in MS.NET

Yes, SVN

Paul escribió:
> Hi,
>
>   
>> Now that Mono.Options is included in Mono 2.2
>>     
>
> 2.2? We've only just had the official release of 2.0! I've not seen
> anything on this list over a 2.2 release with tarballs or are you
> talking about svn?
>
> TTFN
>
> Paul
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
Permalink | Reply |
headers
Avery Pennarun | 16 Oct 19:16

Re: Using Mono.Options in MS.NET

2008/10/16 Paul <paul <at> all-the-johnsons.co.uk>:
>> Now that Mono.Options is included in Mono 2.2
>
> 2.2? We've only just had the official release of 2.0! I've not seen
> anything on this list over a 2.2 release with tarballs or are you
> talking about svn?

Sorry, I was referring to this:
http://tirania.org/blog/archive/2008/Oct-14.html

Obviously there is no Mono 2.2 yet, but I was assuming from Miguel's
post that it's "as good as included" in 2.2.

Thanks,

Avery
Permalink | Reply |
headers
Miguel de Icaza | 17 Oct 02:33
Favicon

Re: Using Mono.Options in MS.NET


> Now that Mono.Options is included in Mono 2.2, will it still be
> available separately?  If not, it will be hard to build
> Windows-compatible programs that use it, unless people go digging
> throug the mono sources and extracting the libraries they like.  I
> think it might be helpful to separate "mono libraries that add
> functionality to any .Net application" and "mono libraries that
> implement the MS class library" into two different projects.
> 
> Am I missing something?

You can always pull the code using the AnonSVN user interface from the
web, it can produce tarballs of just the things that you need.

Our todo list includes "Make it easier to release components
independently", would love to do it, we just need the spare cycles to
make it happen in a general way for everything that we need.

I think the tarball solution is pretty good, and we could just bundle
solutions or files for the more complicated modules (Mono.Options is
really easy to use).
Permalink | Reply |
headers
Avery Pennarun | 17 Oct 03:17

Re: Using Mono.Options in MS.NET

On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza <miguel <at> novell.com> wrote:
>> Now that Mono.Options is included in Mono 2.2, will it still be
>> available separately?  If not, it will be hard to build
>> Windows-compatible programs that use it, unless people go digging
>> throug the mono sources and extracting the libraries they like.  I
>> think it might be helpful to separate "mono libraries that add
>> functionality to any .Net application" and "mono libraries that
>> implement the MS class library" into two different projects.
>>
>> Am I missing something?
>
> You can always pull the code using the AnonSVN user interface from the
> web, it can produce tarballs of just the things that you need.
>
> Our todo list includes "Make it easier to release components
> independently", would love to do it, we just need the spare cycles to
> make it happen in a general way for everything that we need.
>
> I think the tarball solution is pretty good, and we could just bundle
> solutions or files for the more complicated modules (Mono.Options is
> really easy to use).

Thanks, that answers my question.

Avery
Permalink | Reply |
headers
Petit Eric | 17 Oct 09:03

Re: Using Mono.Options in MS.NET

2008/10/17 Avery Pennarun <apenwarr <at> gmail.com>:
> On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza <miguel <at> novell.com> wrote:
>>> Now that Mono.Options is included in Mono 2.2, will it still be
>>> available separately?  If not, it will be hard to build
>>> Windows-compatible programs that use it, unless people go digging
>>> throug the mono sources and extracting the libraries they like.  I
>>> think it might be helpful to separate "mono libraries that add
>>> functionality to any .Net application" and "mono libraries that
>>> implement the MS class library" into two different projects.
>>>
>>> Am I missing something?
>>
>> You can always pull the code using the AnonSVN user interface from the
>> web, it can produce tarballs of just the things that you need.
>>
>> Our todo list includes "Make it easier to release components
>> independently", would love to do it, we just need the spare cycles to
>> make it happen in a general way for everything that we need.
>>
>> I think the tarball solution is pretty good, and we could just bundle
>> solutions or files for the more complicated modules (Mono.Options is
>> really easy to use).
I don't know if Mono.Option made P/Invoke, but if not you can simply
set , assembly property to "Locale copy" as it, the dll will folow the
.exe and so ...
>
> Thanks, that answers my question.
>
> Avery
> _______________________________________________
(Continue reading)

Permalink | Reply |
headers
Alan McGovern | 17 Oct 10:54

Re: Using Mono.Options in MS.NET

It's 100% pure managed code, and also a single .cs file. That makes it trivial to just include as part of your build. You can reference it using an svn:external (or equivalent) so you always have the latest from svn aswell, which minimises the need to keep in sync with the working copy.

There's no need to lug around an extra assembly when it's so easy to compile it right in :)

Alan.

On Fri, Oct 17, 2008 at 8:03 AM, Petit Eric <surfzoid <at> gmail.com> wrote:
2008/10/17 Avery Pennarun <apenwarr <at> gmail.com>:
> On Thu, Oct 16, 2008 at 8:33 PM, Miguel de Icaza <miguel <at> novell.com> wrote:
>>> Now that Mono.Options is included in Mono 2.2, will it still be
>>> available separately?  If not, it will be hard to build
>>> Windows-compatible programs that use it, unless people go digging
>>> throug the mono sources and extracting the libraries they like.  I
>>> think it might be helpful to separate "mono libraries that add
>>> functionality to any .Net application" and "mono libraries that
>>> implement the MS class library" into two different projects.
>>>
>>> Am I missing something?
>>
>> You can always pull the code using the AnonSVN user interface from the
>> web, it can produce tarballs of just the things that you need.
>>
>> Our todo list includes "Make it easier to release components
>> independently", would love to do it, we just need the spare cycles to
>> make it happen in a general way for everything that we need.
>>
>> I think the tarball solution is pretty good, and we could just bundle
>> solutions or files for the more complicated modules (Mono.Options is
>> really easy to use).
I don't know if Mono.Option made P/Invoke, but if not you can simply
set , assembly property to "Locale copy" as it, the dll will folow the
.exe and so ...
>
> Thanks, that answers my question.
>
> Avery
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



--

Cordially.

Small Eric Quotations of the days:
---------------------------------------------------------------------------
If one day one reproaches you that your work is not a work of
professional, say you that:
Amateurs built the arch of Noah, and professionals the Titanic.
---------------------------------------------------------------------------

Few people are done for independence, it is the privilege of the powerful ones.
---------------------------------------------------------------------------

No key was wounded during the drafting of this message.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Permalink | Reply |
headers
Jonathan Pryor | 20 Oct 16:53
Favicon

Re: Using Mono.Options in MS.NET

On Wed, 2008-10-15 at 16:48 -0400, Avery Pennarun wrote:
> Now that Mono.Options is included in Mono 2.2, will it still be
> available separately?

Good question.  The answer is that the Mono.Options currently in svn is
~identical to NDesk.Options 0.2.1 (which I'll be announcing soon, it's
only been sitting around for the last few months with ~no changes...).
The only major difference is the namespace.

Which of course means they're not source compatible -- you'll need to
change a `using` declaration...

That said, for the time being I plan on keeping NDesk.Options &
Mono.Options in sync with each other (and will likely use a #if block in
the future to control the namespace so that they'll be identical files),
but I don't know for how long I'd want to do this...

 - Jon
Permalink | Reply |
headers
Avery Pennarun | 20 Oct 19:32

Re: Using Mono.Options in MS.NET

On Mon, Oct 20, 2008 at 10:53 AM, Jonathan Pryor <jonpryor <at> vt.edu> wrote:
> On Wed, 2008-10-15 at 16:48 -0400, Avery Pennarun wrote:
>> Now that Mono.Options is included in Mono 2.2, will it still be
>> available separately?
>
> Good question.  The answer is that the Mono.Options currently in svn is
> ~identical to NDesk.Options 0.2.1 (which I'll be announcing soon, it's
> only been sitting around for the last few months with ~no changes...).
> The only major difference is the namespace.
>
> Which of course means they're not source compatible -- you'll need to
> change a `using` declaration...
>
> That said, for the time being I plan on keeping NDesk.Options &
> Mono.Options in sync with each other (and will likely use a #if block in
> the future to control the namespace so that they'll be identical files),
> but I don't know for how long I'd want to do this...

In the end, as others have pointed out, it's pretty easy to extract
the file from the mono svn repository, and it's not something that has
to happen often.  It just seems like an odd thing to ask
non-mono-using C# programmers to do :)  Harmless, though, particularly
if you provide a direct hyperlink to the SVN tarball-making URL.

Thanks again for your work on this library.  It's awesome.

Have fun,

Avery
Permalink | Reply |

Gmane