Re: [Mono-dev] Fwd: webservice under mono/xsp
Thanks for your answer, but that doesn't really help me. I have have the same syntax but I get the error. I have a workaround: I put a dll-File in my bin-directory. In this dll-file is a class (Testklasse). Then I put this source into my asmx-file: %@ WebService Language=VB Class=Test % Imports System.Web Imports System.Web.Services Imports System.Web.Services.Protocols Imports Testklasse WebService(Namespace:=http://tempuri.de/;) _ WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1) _ Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated() _ Public Class Test Inherits System.Web.Services.WebService WebMethod() _ Public Function GetAllHosts() As String() Dim t as new Testklasse() Dim s1 as String s1=t.DoThomething() Dim myString(2) As String myString(1)=s1 return myString End Function End Class But I don't know why this works and the other way not. Does anybody know the reason? thanks 2010/9/20 Kris Ray k...@landmarkdigital.com: 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] [Mono-osx] [Mono-list] Mono 2.8 Second Public Preview
Hi, If you guide me to the bugs I'll do my best, however I don't know what they are, where they are, or the mono codebase. Regards, Natalia Portillo El 21/09/2010, a las 03:31, Geoff Norton escribió: 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
Re: [Mono-dev] [Mono-osx] [Mono-list] Mono 2.8 Second Public Preview
I would start by building the port and running the test suite, there is at least one transient crash when compiling. Additionally, the mach support for sgen will need to be completed for amd64 Im sure there is more but thats probably going to uncover lots of work, off the top of my head On 2010-09-21, at 10:01 AM, Natalia Portillo wrote: Hi, If you guide me to the bugs I'll do my best, however I don't know what they are, where they are, or the mono codebase. Regards, Natalia Portillo El 21/09/2010, a las 03:31, Geoff Norton escribió: 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
Re: [Mono-dev] System.PlatformID
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). If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it. Thank you for the explanation. Nicholas -Original Message- From: Jonathan Pryor [mailto:jonpr...@vt.edu] Sent: Monday, September 20, 2010 10:24 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: 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] System.PlatformID
Hi, Try looking at Environment.Version in the prod environment. If you get 1.1.x rather than 2.0.x you know what your problem is. Note that only app.config is able to require a specific runtime version, and there is no such thing as a 3.5 runtime (it's 2.0 with extra assemblies versioned to 3.5.x.x). Kornél Nicholas Salerno wrote: 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). If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it. Thank you for the explanation. Nicholas -Original Message- From: Jonathan Pryor [mailto:jonpr...@vt.edu] Sent: Monday, September 20, 2010 10:24 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AssemblyInstaller
Nicholas Salerno wrote: With respect to compatibility with Microsoft's behavior, I have found two bugs in Mono's implementation of installutil: Mono aims to be compatible with MS.NET so you are welcome to fix compatibility issues. Note that if you also provide unit tests that prove that your implementation is corrent and ensure that there will be no regression later, your patches are more likely to be accepted. 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. Mono itself has the same goals. 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. I have never used AssemblyInstaller but based on the documentation I agree that ManagedInstallerClass should be the core of a command line tool around AssemblyInstaller. Note that this is an implementation detail invisible to the outside world so you don't have to guess how MS.NET does it, you can just implement it the way that makes sense. To summarize: installutil.exe --uses-- ManagedInstallerClass --uses-- AssemblyInstaller installutil.exe Provides command line user interface for ManagedInstallerClass. I think that this is a good design. Kornél ___ 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
Ah. It is my unit test. I have a test that launches installutil. The installutil.exe that comes with the 2.6.7 RPM packages is from the /usr/lib/mono/1.0 (there doesn't seem to be one for 2.0). The running of installutil invokes my Installer class and at that point PlatformID is going to be 128. In that particular case my Installer derived class is standard so it should have no problem running in a 1.x runtime (and it appears to be the case). For the other tests in the suite, PlatformID is 4 as the runtime is 2.0. Thank you. Nicholas -Original Message- From: Kornél Pál [mailto:kornel...@gmail.com] Sent: Tuesday, September 21, 2010 2:00 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.PlatformID Hi, Try looking at Environment.Version in the prod environment. If you get 1.1.x rather than 2.0.x you know what your problem is. Note that only app.config is able to require a specific runtime version, and there is no such thing as a 3.5 runtime (it's 2.0 with extra assemblies versioned to 3.5.x.x). Kornél Nicholas Salerno wrote: 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). If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it. Thank you for the explanation. Nicholas -Original Message- From: Jonathan Pryor [mailto:jonpr...@vt.edu] Sent: Monday, September 20, 2010 10:24 PM To: Nicholas Salerno Cc: mono-devel-list@lists.ximian.com Subject: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
