[Mono-dev] Fwd: webservice under mono/xsp
Hello Community, I have still the same problem. I can't use a dll-file under xsp. I checked my source for case-sensitive and all words are correct. I copied the dll-library into a bin-directory but without an effect. my xsp-version: 2.4.3.0 my mono-version: Mono JIT compiler version 2.4.4 mono-vbnc-version: Visual Basic.Net Compiler version 0.0.0.5914 I really have to solve this problem. If there is no solution for my problem I can't use mono for my webservice. Does anybody have an idea? thanks -- Forwarded message -- From: Chakotey STME chakoteys...@gmail.com Date: 2010/9/13 Subject: webservice under mono/xsp To: mono-devel-list@lists.ximian.com Hello Community, I have a webservice-project with nearly no functions and I want to publish it in my local network. Under Windows with IIS I have no problem to publish my webservice. I have a precompiled library (my VB-Code) and a asmx-file. Here is the content of my asmx-file: %@ WebService Language=VB CodeBehind=~/App_Code/MYVBCLASS.vb Class=PROJECTNAME.CLASSNAME % It works good under the IIS. If I try it under mono and XSP I get this error: Error 500 - Typ PROJECTNAME.CLASSNAME not found I put the library of my code into a bin-directory or in the same directory the asmx-file exists. It doesn't work. It works under XSP if I take my Code directly into my asmx-file like this: %@ WebService Language=VB Class=MyClass % Imports ... WebService(Namespace:=http://tempuri.org/;) _ WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1) _ Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated() _ Public Class MyClass Inherits System.Web.Services.WebService WebMethod() _ Public Function MyFunction() As Blabla() End Function End Class --- So, is there a way to use a library in the asmx-file under mono and xsp? What have I to do for it? thanks, chakoteystme ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Thank you for the clarification. All that said, it still seems like
ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller.
ManagedInstallerClass is COM visible, which may imply some things.
AssemblyInstaller appears to be a plain old .NET class. I don't have any
objection to ManagedInstallerClass, I'm just trying to understand where
implementations should fall into place.
Nicholas
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Saturday, September 18, 2010 5:04 AM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
static void Main(string[] args)
{
try
{
ManagedInstallerClass.InstallHelper(args);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
Arguments accepted are documented here:
http://msdn.microsoft.com/en-us/library/50614e95.aspx
So all the functionality of installutil.exe should be moved to
ManagedInstallerClass. Even the help screen comes as an exception.
Note that no version headers are not printed by ManagedInstallerClass
that should remain in installutil.exe and some appropriate status code
should be set on return as well.
Based on the following example I belive that
IManagedInstaller.ManagedInstall does exactly the same except that
exceptions are not returned:
class Program
{
static void Main(string[] args)
{
try
{
IManagedInstaller installer = new
ManagedInstallerClass();
StringBuilder sb = new StringBuilder();
foreach (string arg in args)
{
sb.Append('');
sb.Append(arg.Replace(\\,
).Replace(\, \\\));
sb.Append(\ );
}
if (sb.Length 0)
sb.Remove(sb.Length - 1, 1);
installer.ManagedInstall(sb.ToString(), 0);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
A search for hInstall in Platform SDK headers resulted in matches only
from MsiQuery.h. So that method is most likely used by Windows Installer
and I would guess that at least errors are reported using hInstall
rather than exceptions.
Kornél
Nicholas Salerno write:
Vincent Povirk wrote:
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
The ManagedInstallerClass is scarcely documented in MSDN (unlike the other
classes in the System.Configuration.Install namespace). Also, the
description states that the class is not meant to be directly used by one's
code. I don't know much about this ManagedInstallerClass other than it
doesn't seem to fit with the model established by the Installer class. It
doesn't derive from Installer. It implements IManagedInstaller, an interface
I don't know much about.
I am familiar with the Installer class that derives from Component and is
meant to be subclassed. The AssemblyInstaller class seems to be the class to
use if one wants to programmatically install and uninstall .NET components
(without having to execute shell commands to instalutil). I do this in
Windows.
If nobody has any objections I would like to submit a patch that implements
the AssemblyInstaller class.
Nicholas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fwd: webservice under mono/xsp
I have a little different scenario, but My webservice is setup like this: %@ WebService Language=C# Class=Company.WebServices.Stuff.StuffService % My bin folder contains the dlls for the StuffService and other associated libraries. Hopefully this helps... thanks, Kris From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] On Behalf Of Chakotey STME [chakoteys...@gmail.com] Sent: Monday, September 20, 2010 3:10 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Fwd: webservice under mono/xsp Hello Community, I have still the same problem. I can't use a dll-file under xsp. I checked my source for case-sensitive and all words are correct. I copied the dll-library into a bin-directory but without an effect. my xsp-version: 2.4.3.0 my mono-version: Mono JIT compiler version 2.4.4 mono-vbnc-version: Visual Basic.Net Compiler version 0.0.0.5914 I really have to solve this problem. If there is no solution for my problem I can't use mono for my webservice. Does anybody have an idea? thanks -- Forwarded message -- From: Chakotey STME chakoteys...@gmail.com Date: 2010/9/13 Subject: webservice under mono/xsp To: mono-devel-list@lists.ximian.com Hello Community, I have a webservice-project with nearly no functions and I want to publish it in my local network. Under Windows with IIS I have no problem to publish my webservice. I have a precompiled library (my VB-Code) and a asmx-file. Here is the content of my asmx-file: %@ WebService Language=VB CodeBehind=~/App_Code/MYVBCLASS.vb Class=PROJECTNAME.CLASSNAME % It works good under the IIS. If I try it under mono and XSP I get this error: Error 500 - Typ PROJECTNAME.CLASSNAME not found I put the library of my code into a bin-directory or in the same directory the asmx-file exists. It doesn't work. It works under XSP if I take my Code directly into my asmx-file like this: %@ WebService Language=VB Class=MyClass % Imports ... WebService(Namespace:=http://tempuri.org/;) _ WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1) _ Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated() _ Public Class MyClass Inherits System.Web.Services.WebService WebMethod() _ Public Function MyFunction() As Blabla() End Function End Class --- So, is there a way to use a library in the asmx-file under mono and xsp? What have I to do for it? thanks, chakoteystme ___ 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] AssemblyInstaller
Hi,
A COM visible .NET class is a .NET class. If you use it from .NET you
don't see a difference, and there is no difference in the internals
eiher. The only difference is that you can access COM visible classes
using COM interfaces in unmanaged code. This is very much the same as
P/Invoke DLLs/delegates with the additional support for reference
counting and this argument. (HRESULT to exception translation is also
supported for pure non-OOP functions.)
So you don't really have to care about the COM visible attribute just
take advantage of it if you want to.
Mono already has an installutil.exe (I don't know how mutch compatible
it is with that of MS.NET) so the easiest implementation of
ManagedInstallerClass.InstallHelper is to move logic except
version/copyright header from installutil.exe to
ManagedInstallerClass.InstallHelper.
installutil.exe should not be just a couple of lines longer than my
reference implementation in this thread.
If you mean something else on where implementations should fall into
place please be more specific.
Kornél
Nicholas Salerno:
Thank you for the clarification. All that said, it still seems like
ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller.
ManagedInstallerClass is COM visible, which may imply some things.
AssemblyInstaller appears to be a plain old .NET class. I don't have any
objection to ManagedInstallerClass, I'm just trying to understand where
implementations should fall into place.
Nicholas
-Original Message-
From: Kornél Pál [mailto:kornel...@gmail.com]
Sent: Saturday, September 18, 2010 5:04 AM
To: Nicholas Salerno
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
Hi,
See
http://msdn.microsoft.com/en-us/library/system.configuration.install.managedinstallerclass.installhelper.aspx
That page documents exactly what it does.
installutil.exe should be implemented as sometihng like the following
(I've tried it and it works on MS.NET):
class Program
{
static void Main(string[] args)
{
try
{
ManagedInstallerClass.InstallHelper(args);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
Arguments accepted are documented here:
http://msdn.microsoft.com/en-us/library/50614e95.aspx
So all the functionality of installutil.exe should be moved to
ManagedInstallerClass. Even the help screen comes as an exception.
Note that no version headers are not printed by ManagedInstallerClass
that should remain in installutil.exe and some appropriate status code
should be set on return as well.
Based on the following example I belive that
IManagedInstaller.ManagedInstall does exactly the same except that
exceptions are not returned:
class Program
{
static void Main(string[] args)
{
try
{
IManagedInstaller installer = new
ManagedInstallerClass();
StringBuilder sb = new StringBuilder();
foreach (string arg in args)
{
sb.Append('');
sb.Append(arg.Replace(\\,
).Replace(\, \\\));
sb.Append(\ );
}
if (sb.Length 0)
sb.Remove(sb.Length - 1, 1);
installer.ManagedInstall(sb.ToString(), 0);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
A search for hInstall in Platform SDK headers resulted in matches only
from MsiQuery.h. So that method is most likely used by Windows Installer
and I would guess that at least errors are reported using hInstall
rather than exceptions.
Kornél
Nicholas Salerno write:
Vincent Povirk wrote:
I don't know much about these classes, but my impression was that
ManagedInstallerClass corresponds most directly to installutil.exe,
but that that class must use AssemblyInstaller. It seems installutil
duplicates some functionality of both of those, and it should probably
call on them instead.
The ManagedInstallerClass is scarcely documented in MSDN (unlike the other
classes in the System.Configuration.Install namespace). Also, the
description states that the class is not meant to be directly used by one's
code. I don't know much about this ManagedInstallerClass other than it
doesn't seem to fit with the model established by the Installer class. It
doesn't derive from Installer. It implements IManagedInstaller, an
interface I don't know much about.
I am familiar with the Installer class that derives from Component and is
meant to be subclassed. The AssemblyInstaller class seems to be the class
to use if one wants to
Re: [Mono-dev] AssemblyInstaller
So you don't really have to care about the COM visible attribute just take advantage of it if you want to. OK. Understood. Mono already has an installutil.exe (I don't know how mutch compatible it is with that of MS.NET) so the easiest implementation of... Yes, I agree about Mono's installutil.exe, and the first thing I thought to myself was that the implementation should be moved into the System.Configuration.Install namespace. With respect to compatibility with Microsoft's behavior, I have found two bugs in Mono's implementation of installutil: 1) It does not invoke the Installer instances that are contained in the main Installer (the one with the RunInstaller(true) attribute). One can work around this bug by manually invoking the child installers in their respective overridden Installer methods. 2) When you execute installutil /u MyAssembly.exe it calls the Install() method. The Uninstall() method is not invoked. However, the OnBeforeUninstall() method is called properly so one can work around this bug by setting a value in the IDictionary parameter. In the Install() method, the first thing you do is check for that value. If it exists then dispatch to the Uninstall() method and return. Else, proceed with your implementation of Install(). Both of these bugs I would like to fix because they really break the write once, run everwhere model and I (and company) do not want to maintain two code bases for dealing with Microsoft's way and Mono's way of installers. If you mean something else on where implementations should fall into place please be more specific. You convinced me that installutil.exe is implemented by using ManagedInstallerClass. We agree on that. What I am still undecided about is if ManagedInstallerClass uses AssemblyInstaller to get some of the work done. Right now both of these classes are not implemented in Mono and I am wondering if the code in installutil.exe is split amongst the two classes. You can have ManagedInstallerClass do all the work, but what if somebody was interested in AssemblyInstaller only to find it is not implemented? According to MSDN AssemblyInstaller Loads an assembly, and runs all the installers in it. In using it with Microsoft's implementation, AssemblyInstaller handles the child installers contained in the parent installer (bug #1 that wrote about above). Bug #2 that I wrote about above would be a problem in ManagedInstallerClass. To summarize: installutil.exe --uses-- ManagedInstallerClass --uses-- AssemblyInstaller installutil.exe Provides command line user interface for ManagedInstallerClass. ManagedInstallerClass Responsible for instantiating and managing IDictionary parameter for Installer methods. Also responsible for managing the sequence of calls to Installer methods. AssemblyInstaller Responsible for invoking override methods of Installers found in the assembly (based on RunInstaller attribute). In addition, for each installer found in assembly, invoke methods on the instances that exist in the Installers property of each installer instance. Yes, no? Nicholas -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Monday, September 20, 2010 3:44 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] AssemblyInstaller Hi, A COM visible .NET class is a .NET class. If you use it from .NET you don't see a difference, and there is no difference in the internals eiher. The only difference is that you can access COM visible classes using COM interfaces in unmanaged code. This is very much the same as P/Invoke DLLs/delegates with the additional support for reference counting and this argument. (HRESULT to exception translation is also supported for pure non-OOP functions.) So you don't really have to care about the COM visible attribute just take advantage of it if you want to. Mono already has an installutil.exe (I don't know how mutch compatible it is with that of MS.NET) so the easiest implementation of ManagedInstallerClass.InstallHelper is to move logic except version/copyright header from installutil.exe to ManagedInstallerClass.InstallHelper. installutil.exe should not be just a couple of lines longer than my reference implementation in this thread. If you mean something else on where implementations should fall into place please be more specific. Kornél Nicholas Salerno: Thank you for the clarification. All that said, it still seems like ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller. ManagedInstallerClass is COM visible, which may imply some things. AssemblyInstaller appears to be a plain old .NET class. I don't have any objection to ManagedInstallerClass, I'm just trying to understand where implementations should fall into place. Nicholas -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Saturday, September 18, 2010 5:04 AM To: Nicholas Salerno
Re: [Mono-dev] AssemblyInstaller
I suspect that the Installer class is responsible for chaining the Install, Uninstall, and Commit calls to children. If so, AssemblyInstaller just needs to add all the runnable installers to itself and let Installer do the work of making sure they're invoked. This needs a test case. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Hmm. That is an interesting point. Nicholas -Original Message- From: Vincent Povirk [mailto:madewokh...@gmail.com] Sent: Monday, September 20, 2010 5:40 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] AssemblyInstaller I suspect that the Installer class is responsible for chaining the Install, Uninstall, and Commit calls to children. If so, AssemblyInstaller just needs to add all the runnable installers to itself and let Installer do the work of making sure they're invoked. This needs a test case. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.8 Second Public Preview
Tonight we publish the second (or third if you were watching closely) public preview of Mono 2.8[0]. To see what's been fixed since the first preview head over to github[6] and read the commits on mono-2-8 from d88e223dd4bd0469594e to 58f029f2d1a2ed2c3f16 (older to newer). We are still fixing a problem hitting breakpoints when remotely debugging using Mono Tools for Visual Studio but as far as we know that's the only bug holding back the final release of 2.8. If you find a bug please report it: http://www.mono-project.com/Bugs Also, the QA team asks that we put the string mono-2.8 (without quotes) in the whiteboard field on the bug report. Internally this is Preview 6, so mention that in your bugs. If you use mono on windows we strongly encourage you to do some testing now as we have not done a lot of testing on windows ourselves. Community power activate! There have been some further changes to the RPM spec file so packagers are again encouraged to peruse the spec on github[4]. [6] http://github.com/mono/mono/commits/mono-2-8 On Sat, 2010-09-11 at 16:30 +, Andrew Jorgensen wrote: Yesterday we published the first public preview[0] of Mono 2.8. This release contains many improvements and new features. Please refer to the draft release notes[1] for details. Linux builds include SGen[2] and LLVM[3] either or both of which can be enabled at runtime. [0] http://mono.ximian.com/monobuild/preview/download-preview/ [1] http://www.mono-project.com/Release_Notes_Mono_2.8 [2] http://www.mono-project.com/Compacting_GC [3] http://www.mono-project.com/Mono_LLVM If you find a bug please report it: http://www.mono-project.com/Bugs Packagers for distributions like Fedora are strongly encouraged to have a look at the mono-core.spec file[4] as there are a large number of new assemblies and we have rearranged a few packages to break cyclical dependencies etc.. [4] http://github.com/mono/mono/blob/mono-2-8/mono-core.spec.in The Mono Project is very much alive and a lot of work has gone into this release. We are positioning 2.8 as a sort of early version of what will eventually become Mono 3.0. The next release after 2.8 will be 2.8.2 which will be branched from Git master. This means that we will not be maintaining the mono-2-8 branch (except possibly for security fixes). We will continue in this fashion until 3.0 to allow developers to stay focused on their work and not maintain multiple branches. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Mono 2.8 Second Public Preview
Hi and congratulations, Will this version include x86-64 support on Mac OS X or that will stay in the unstable git? Regards, Natalia Portillo Claunia.com El 21/09/2010, a las 01:06, Andrew Jorgensen escribió: Tonight we publish the second (or third if you were watching closely) public preview of Mono 2.8[0]. To see what's been fixed since the first preview head over to github[6] and read the commits on mono-2-8 from d88e223dd4bd0469594e to 58f029f2d1a2ed2c3f16 (older to newer). We are still fixing a problem hitting breakpoints when remotely debugging using Mono Tools for Visual Studio but as far as we know that's the only bug holding back the final release of 2.8. If you find a bug please report it: http://www.mono-project.com/Bugs Also, the QA team asks that we put the string mono-2.8 (without quotes) in the whiteboard field on the bug report. Internally this is Preview 6, so mention that in your bugs. If you use mono on windows we strongly encourage you to do some testing now as we have not done a lot of testing on windows ourselves. Community power activate! There have been some further changes to the RPM spec file so packagers are again encouraged to peruse the spec on github[4]. [6] http://github.com/mono/mono/commits/mono-2-8 On Sat, 2010-09-11 at 16:30 +, Andrew Jorgensen wrote: Yesterday we published the first public preview[0] of Mono 2.8. This release contains many improvements and new features. Please refer to the draft release notes[1] for details. Linux builds include SGen[2] and LLVM[3] either or both of which can be enabled at runtime. [0] http://mono.ximian.com/monobuild/preview/download-preview/ [1] http://www.mono-project.com/Release_Notes_Mono_2.8 [2] http://www.mono-project.com/Compacting_GC [3] http://www.mono-project.com/Mono_LLVM If you find a bug please report it: http://www.mono-project.com/Bugs Packagers for distributions like Fedora are strongly encouraged to have a look at the mono-core.spec file[4] as there are a large number of new assemblies and we have rearranged a few packages to break cyclical dependencies etc.. [4] http://github.com/mono/mono/blob/mono-2-8/mono-core.spec.in The Mono Project is very much alive and a lot of work has gone into this release. We are positioning 2.8 as a sort of early version of what will eventually become Mono 3.0. The next release after 2.8 will be 2.8.2 which will be branched from Git master. This means that we will not be maintaining the mono-2-8 branch (except possibly for security fixes). We will continue in this fashion until 3.0 to allow developers to stay focused on their work and not maintain multiple branches. ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.PlatformID
On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote: When I query System.Environment.OSVersion.Platform on Linux I get a value that will equate to 128. Yet, this is not in the source code definition for the PlatformID enum. It means you're running in the 1.0 profile. If you were running under the 2.0 profile, you'd get 4 (PlatformID.Unix). See: http://www.mono-project.com/FAQ:_Technical Quote: The first versions of the framework (1.0 and 1.1) didn't include any PlatformID value for Unix, so Mono used the value 128. The newer framework 2.0 added Unix to the PlatformID enum but, sadly, with a different value: 4 and newer versions of .NET distinguished between Unix and MacOS X, introducing yet another value 6 for MacOS X. Question: is 128 supposed to mean Linux? It means Unix under the 1.x .NET profile; under the .NET 2.0 profile, PlatformID.Unix (4) is returned. I am wondering if there is a better way or if this is all that can be done. Targeting .NET 2.0+ will help (no 128 value), but only so much (there's still distinct PlatformID.Unix and PlatformID.MacOSX values), so preferable (normally) are feature checks, not platform checks. Feature checks are also more useful anyway, as a feature may be added in some version of a platform, and (based on reading years of Dr. GUI articles in MSDN) platform version detection and handling is HARD. You would not believe the number of errors applications make doing that... Also, what if Microsoft suddenly came out of nowhere and said that 128 will map to AIX? I would laugh. A lot. (AIX?! Seriously?) The matter still has a theoretical nature, which can be answered thus: dontworryaboutit. More specifically, Mono 2.6 is the last release with 1.x profile support, and thus is the last version that will return 128 for PlatformID on Unix platforms. (Plus, most actual apps have been 2.0 apps for quite some time.). Mono 2.8 is 2.0+ only, and thus will never return 128. Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes, so even if Microsoft added a new enum value, only mono master will actually receive the value, not 2.6 (or likely 2.8, at this point). Thus, in practice, it's not really worth worrying about. - 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-osx] [Mono-list] Mono 2.8 Second Public Preview
The x86-64 support for OSX is still unstable at this time, as it does have some transient bugs with it. Are you interested in contributing to stabalizing this port? I'm happy to review patches. -g On 2010-09-20, at 8:37 PM, Natalia Portillo wrote: Hi and congratulations, Will this version include x86-64 support on Mac OS X or that will stay in the unstable git? Regards, Natalia Portillo Claunia.com El 21/09/2010, a las 01:06, Andrew Jorgensen escribió: Tonight we publish the second (or third if you were watching closely) public preview of Mono 2.8[0]. To see what's been fixed since the first preview head over to github[6] and read the commits on mono-2-8 from d88e223dd4bd0469594e to 58f029f2d1a2ed2c3f16 (older to newer). We are still fixing a problem hitting breakpoints when remotely debugging using Mono Tools for Visual Studio but as far as we know that's the only bug holding back the final release of 2.8. If you find a bug please report it: http://www.mono-project.com/Bugs Also, the QA team asks that we put the string mono-2.8 (without quotes) in the whiteboard field on the bug report. Internally this is Preview 6, so mention that in your bugs. If you use mono on windows we strongly encourage you to do some testing now as we have not done a lot of testing on windows ourselves. Community power activate! There have been some further changes to the RPM spec file so packagers are again encouraged to peruse the spec on github[4]. [6] http://github.com/mono/mono/commits/mono-2-8 On Sat, 2010-09-11 at 16:30 +, Andrew Jorgensen wrote: Yesterday we published the first public preview[0] of Mono 2.8. This release contains many improvements and new features. Please refer to the draft release notes[1] for details. Linux builds include SGen[2] and LLVM[3] either or both of which can be enabled at runtime. [0] http://mono.ximian.com/monobuild/preview/download-preview/ [1] http://www.mono-project.com/Release_Notes_Mono_2.8 [2] http://www.mono-project.com/Compacting_GC [3] http://www.mono-project.com/Mono_LLVM If you find a bug please report it: http://www.mono-project.com/Bugs Packagers for distributions like Fedora are strongly encouraged to have a look at the mono-core.spec file[4] as there are a large number of new assemblies and we have rearranged a few packages to break cyclical dependencies etc.. [4] http://github.com/mono/mono/blob/mono-2-8/mono-core.spec.in The Mono Project is very much alive and a lot of work has gone into this release. We are positioning 2.8 as a sort of early version of what will eventually become Mono 3.0. The next release after 2.8 will be 2.8.2 which will be branched from Git master. This means that we will not be maintaining the mono-2-8 branch (except possibly for security fixes). We will continue in this fashion until 3.0 to allow developers to stay focused on their work and not maintain multiple branches. ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-osx mailing list mono-...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-osx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
