Re: [Mono-dev] Mono 1.1.17 has been released.
On 8/29/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one.i would recommend not split GTK# into multiple packages , it not suitable for end user. It is better to split into sub-projects. It become a bit irksome to build every single package manually and there are already so many packages. -- Sharique uddin Ahmed Farooqui(C++/C# Developer. IT Consultant, Open Source Expert)http://www.sharique.managefolio.com/Read my Blogs at http://safknw.blogspot.comA revolution is about to begin.A world is about to change.And you and me are the initiator. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Sharique uddin Ahmed Farooqui escribió: Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. i would recommend not split GTK# into multiple packages , it not suitable for end user. It is better to split into sub-projects. It become a bit irksome to build every single package manually and there are already so many packages. But, if you are talking only about the end-user perspective, I'm sure there won't be any compilation requisite (all would be managed by precompiled packages and dependencies between them). Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Miguel de Icaza wrote: Bugs fixed The following bugs were fixed on this release: 7, 76449, 76453, 76757, 77340, 77551, 77820, 78190, 78220, 78271, 78288, 78291, 78328, 78399, 78483, 78513, 78525, 78592, 78607, 78646, 78661, 78696, 78730, 78731, 78732, 78737, 78746, 78753, 78759, 78761, 78773, 78775, 78800, 78804, 78806, 78810, 78813, 78816, 78821, 78822, 78825, 78826, 78827, 78837, 78854, 78855, 78856, 78859, 78864, 78865, 78866, 78868, 78869, 78871, 78877, 78886, 78889, 78907, 78912, 78914, 78927, 78929, 78931, 78939, 78945, 78949, 78969, 78970, 78971, 78972, 78977, 79000, 79001, 79002, 79007, 79016, 79020, 79023, 79030, 79037, 79052, 79053, 79076, 79080, 79085, 79087, 79091, 79095, 79096, 79150, 30235, 45730, 70506, 77403, 77489, 77539, 78253, 78468, 78703, 78724, 78767, 78770, 78784, 78799, 78842, 78860, 7, 78899, 78901, 78943, 78968, 79010, 79033, 79056, 79067, 79084, 79090, 79112, 79117, 79118, 79125, 77396, 78323, 78384, 78986, 78990, 79012, 79019, 79026, 79064, 77963, 78985, 79027 and 79028. Allow me to say a big thanks to everyone who works so hard to make Mono a better product. I'm looking forward to using Mono more and more in my future projects. You guys do an awesome job. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Miguel de Icaza wrote: Mono 1.1.17 has been released. [...] The following bugs were fixed on this release: I made a list of the bugs fixed that contains a little more info than only the number: http://www.frijters.net/mono-bugs-fixed-1.1.17.html Regards, Jeroen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash.Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming,what would even be better then write once, run anywhere, iswrite for any purpose, write once, run anywhereand unfortunately mono has not provided a means to use it as a browserplugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE.Until this can occur, a programmer still has to Java or (active xplugin), to achieveweb page integration.Unfortunately not having this is a huge barrier to some people adopting mono.Providing this (as even MS .Net doesn't seem to provide web page pluginability of .Net) would put Mono over the top, and likely bring many morecontributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then its easy enough just to make a gui for both web and desktop using asp/gtk whatever. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieveweb page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
You should take note that mono-service based program doesn't work with this version... Le mardi 29 aot 2006 16:43 -0400, Miguel de Icaza a crit : Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code _javascript_ code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, August 30, 2006 09:58, ted leslie wrote: [snip] when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? For example, instead of installing an app, or allowing ActiveX-Mono for want of a better term, you might add a decrypting (public) key to your keyring for the application you wish to run. The 'add key' dialog might resemble the pop-up you will see if you try to access a secure website, whose keys were not created by a central certification authority. This would hopefully allow applications encrypted with the correct private key to run, and only those applications. Any others will be blocked by default. (To be honest, I'd be happy if all browser plugins worked in this way, flash especially. Thank you, FlashBlock.) This could be backed up, by limiting the Mono runtime which runs embedded in the browser, to 'sand-box' the application. However, I can only see this being useful in a corporate setting, with many people hot-desking or working from home, yet needing to access applications in the same environment, wherever they are, and without really installing a number of applications beforehand. Even then, there are probably better methods to achieve the same end result. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then itâs easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http
Re: [Mono-dev] Mono 1.1.17 has been released.
The thread is about a language (platform) allowing one to do most anything, adding Flash to the mix immediately defeats the purpose. I use asp.net, great for many things when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then it’s easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? Yes. It's called ClickOnce deployment, requires Code Access Security, and won't be happening with Mono anytime before 2.0 (iirc). Also, it should be noted that .NET 1.0 allowed you to use SWF components as if they were ActiveX controls. I forget the details, but it only required Internet Explorer and a .NET 1.0+ installation on the client. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: On Wed, August 30, 2006 09:58, ted leslie wrote: [snip] when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? For example, instead of installing an app, or allowing ActiveX-Mono for want of a better term, you might add a decrypting (public) key yikes to your keyring for the application you wish to run. The 'add key' dialog might resemble the pop-up you will see if you try to access a secure website, whose keys were not created by a central certification authority. This would hopefully allow applications encrypted with the correct private key yikes (again) For the record, you encrypt with a public key, not a private key. But you're probably talking about signature, not encryption (which is done with a private key). Couldn't resist ;-) Sebastien to run, and only those applications. Any others will be blocked by default. (To be honest, I'd be happy if all browser plugins worked in this way, flash especially. Thank you, FlashBlock.) This could be backed up, by limiting the Mono runtime which runs embedded in the browser, to 'sand-box' the application. However, I can only see this being useful in a corporate setting, with many people hot-desking or working from home, yet needing to access applications in the same environment, wherever they are, and without really installing a number of applications beforehand. Even then, there are probably better methods to achieve the same end result. I have been involved with many projects, and the clients always have the same needs. The audience goes to a web site, and you want to make your sale QUICK (or viral growth), say its a podcast client, a community collaboration tool, casino games, whatever, and the clients don't want to hear about a install executable, or a pokey asp.net sol'n, they want, when i boils down to it, an active X plugin (vb, c, c++ depending on needs) (or Java), and it just runs right there, no fuss no muss. Programmers don't think twice about installing a gtk app, 99+% of web users will not touch it with a ten foot pole. They will move on to the next casino, or community collaboration tool that just works right there, and yes many times now, you can find it to be flash, but lets not even go there and discuss the use of flash. I am just saying, it would be nice if Mono answered everyones needs (w.r.t the general places that you deploy programs - i.e. stand alone apps, ajax, asp.net, scripts/command line, and lastly browser plugins ), and filled this rather HUGE void (all be it a particularly commercial one). -tl On Wed, 2006-08-30 at 08:11 +0100, damien churchill wrote: __ From: damien churchill Sent: 30 August 2006 08:11 To: 'Justin Dearing' Subject: RE: [Mono-dev] Mono 1.1.17 has been released. Yeah if you write your program in classes then it’s easy enough just to make a gui for both web and desktop using asp/gtk whatever. __ From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Dearing Sent: 30 August 2006 08:00 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 1.1.17 has been released. Don't mean to start a flame war here, but if you want the write once run anywhere in a browser. If you can't do it in AJAX, do it in flash. Secondly, have you heard of ASP.NET, The equivilant of JSP for .NET. Mono's support is pretty good. Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top
Re: [Mono-dev] Mono 1.1.17 has been released.
Jonathan Pryor wrote: On Wed, 2006-08-30 at 10:20 +0100, Ben O'Steen wrote: when i am talking in a browser i am talking about stuff that you can't handle with asp.net, like a full fledged arcade game (to take it to an extreme), a video/audio playing client, the power to properly sync video and audio, integrate with the local file system and other resources. ASP.NET and AJAX don't even get you 1% of the way there, and even flash is incredibly lacking in some of these areas. Whilst I haven't put an awful lot of thought into it, can there be a middle ground between 'ActiveX'-style browser apps and install-only apps? Yes. It's called ClickOnce deployment, requires Code Access Security, and won't be happening with Mono anytime before 2.0 (iirc). Also, it should be noted that .NET 1.0 allowed you to use SWF components as if they were ActiveX controls. I forget the details, but it only required Internet Explorer and a .NET 1.0+ installation on the client. Not only as if they were ActiveX controls. MS.NET's S.W.F.Controls are in fact ActiveX controls. They implement the required COM interfaces and are embeddable by several ActiveX containers (IE, MFC, etc.). The only difference to plain ActiveX controls is the new embedding host of the Internet Explorer. The host knows about MS.NET, its type activation, the CAS, and it is apparently more secure than ActiveX alone (I hope so ;-). About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
On Wed, 2006-08-30 at 14:45 +0200, Robert Jordan wrote: About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. He's dead Jim... huh I meant, it's not dead yet Robert ;-) Seriously there are, at least, three reasons to implement this. First, divide and conquer. It can be done in parallel with the CAS implementation (and related tasks). There seems to be little to gain from having it without CAS, however there's also little gain in completing CAS if there's no applications that can take advantage of it. Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Third, this could be the idea of fun to somebody and I feel obligated to encourage such individuals ;-) -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Sebastien Pouliot wrote: On Wed, 2006-08-30 at 14:45 +0200, Robert Jordan wrote: About Mono's plugin: w/out a working CAS it's grossly negligent to even think about an implementation that allows the execution of assemblies from untrusted sources. Even if they were signed with God's own key, they still were insecure to execute. Let's not beat this dead horse again. He's dead Jim... huh I meant, it's not dead yet Robert ;-) Seriously there are, at least, three reasons to implement this. First, divide and conquer. It can be done in parallel with the CAS implementation (and related tasks). There seems to be little to gain from having it without CAS, however there's also little gain in completing CAS if there's no applications that can take advantage of it. Sorry, I exaggerated a little bit. Of course this could be done in parallel. Second, there are scenarios where FullTrust|Nothing is a valid choice. Indeed, but since we were speaking about a generic browser plugin, low trust is rather the usual trust level. See JavaScript, Java Plugin, Flash. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Ok, that's a subset of the CAS. Third, this could be the idea of fun to somebody and I feel obligated to encourage such individuals ;-) Of course. I didn't intend to yell stop energy :-) Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Le mercredi 30 aot 2006 11:17 -0400, Miguel de Icaza a crit: Hello, You should take note that mono-service based program doesn't work with this version... As I pointed out in the bug you filed, am unable to reproduce the problem; Please update the bug. I've talk with Robert Jordan, and he doesn't understant why you can't reproduce the bug... He can reproduce the bug, and we've find the solution, he's making a patch in order to place mono-service.exe into the GAC (like XSP) ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hubert FONGARNAND wrote: I've talk with Robert Jordan, and he doesn't understant why you can't reproduce the bug... He can reproduce the bug, and we've find the solution, he's making a patch in order to place mono-service.exe into the GAC (like XSP) I've made an addendum to that bug report. I think it should be possible to avoid installing everything to the GAC by making liberal use of codeBase declarations in the machine.config file instead. Of course, I guess it's six one way, half a dozen the other; either way, you still have to sign the assembly. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hi! Interesting discussion; see inline, Sebastien Pouliot wrote: Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Actually, if this example could be achieved, it would very possible that, in my particular case, my company be interested in it for the Linux-side of the ClickOnce technologies we are deploying, so I guess I am not a rare case and many other people would benefit from it too. BTW: I suppose you already know about this extension [1]. Has anyone tried it out? What would prevent it for working with Mono (either in Win32 or Linux)? Regards, Andrés [ knocte ] [1] http://www.softwarepunk.com/ffclickonce/ -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.1.17 has been released.
Hello Andrés, On Wed, 2006-08-30 at 22:46 +0200, Andrés G. Aragoneses [ knocte ] wrote: Hi! Interesting discussion; see inline, Sebastien Pouliot wrote: Second, there are scenarios where FullTrust|Nothing is a valid choice. In fact this is what people do when manually downloading and executing any application (mono or not). So it all comes down to the untrusted source and, like any kind of application, this isn't a problem for everyone. E.g. Company A deploys FireFox (on top of Linux, of course ;-) and a mono-plugin configured to accept signed applications (i.e. assemblies) from Company A only. In this case this is an (non-existing) technological choice to deploy corporate applications yet it totally avoid the untrusted source problem. Actually, if this example could be achieved, it would very possible that, in my particular case, my company be interested in it for the Linux-side of the ClickOnce technologies we are deploying, so I guess I am not a rare case and many other people would benefit from it too. Quite interesting! Can you elaborate more (publicly or privately) on your plans ? BTW: I suppose you already know about this extension [1]. Has anyone tried it out? First time I heard of it, but I'll definitively have a good look at it. What would prevent it for working with Mono (either in Win32 or Linux)? Win32: Mono hosting interfaces are different from MS ones. Linux: Hosting + other win32 calls. Regards, Andrés [ knocte ] [1] http://www.softwarepunk.com/ffclickonce/ -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.1.17 has been released.
Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A number of missing pieces of System.IO.Ports have been implemented (ReadChar, ReadLine, BytesToRead, BytesToWrite, ReadTo, return USB tty
Re: [Mono-dev] Mono 1.1.17 has been released.
I just want to say great job to those making mono a real and competitive alternative to the .NET platform, in addition to its incredible cross-platform enabling; being an engineer with .NET technologies, I can say that mono is truly robust and really (finally) provides the write once, run anywhere capability we all have longed for. I salute you, Mr. Cross-platform Enabler! Original Message Subject: [Mono-dev] Mono 1.1.17 has been released. From: Miguel de Icaza [EMAIL PROTECTED] Date: Tue, August 29, 2006 4:43 pm To: mono-list@lists.ximian.com, Mono Announce mono-announce-list@lists.ximian.com, mono-devel-list@lists.ximian.com Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now
Re: [Mono-dev] Mono 1.1.17 has been released.
On Tue, 2006-08-29 at 19:23 -0700, Carlos J. Muentes wrote: I just want to say great job to those making mono a real and competitive alternative to the .NET platform, in addition to its incredible cross-platform enabling; being an engineer with .NET technologies, I can say that mono is truly robust and really (finally) provides the write once, run anywhere capability we all have longed for. I salute you, Mr. Cross-platform Enabler! Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl Original Message Subject: [Mono-dev] Mono 1.1.17 has been released. From: Miguel de Icaza [EMAIL PROTECTED] Date: Tue, August 29, 2006 4:43 pm To: mono-list@lists.ximian.com, Mono Announce mono-announce-list@lists.ximian.com, mono-devel-list@lists.ximian.com Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM
