Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
On 19/11/14 20:50, Martin Thwaites wrote: Hey Martin, Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Please be especially careful with System.Web - there are plenty of mines buried there. Both in our and in Microsoft code. The latter codebase uses a lot of native Win32 methods which may not have portable (POSIX, preferably) counterparts. Our code, OTOH, has a lot of cruft from the 1.1 days. The biggest problem with our code, however, is its reliance on an early (wrong) assumption that ASP.NET pages are, in fact, valid HTML. The parser is such a convoluted piece of misery that touching it in a wrong way causes System.Web to fall apart. If you want to start contributing I'd start there since there are issues we cannot fix using the current parser (especially the conditional parsing part). I dare say that System.Web will be one of the most challenging parts to port. Good luck and if you need any reviews and/or help don't hesitate to contact me. marek Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: * Make changes to the fork in mono/referencesoure * Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com mailto: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 ___ 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] .NET and Mono integration, the plans
On 19/11/14 21:51, Miguel de Icaza wrote: Hey, Hey, I took a quick look at System.Web over the weekend, and I am not sure that it is that bad. Most of the native stuff has to do with performance counters and some authentication stuff on Windows (which we can skip/ignore). I think also the caching subsystems use kernel APIs. But the core of System.Web should be relatively easy to move. Right, but we need to remember about mod_mono compatibility and the fact that changing the core (the sole System.Web namespace) has cascading effects on all the other System.Web things - it's not an easy task to make it all work fine. It's definitely doable, but may require a lot of work to get right. It would be great if we could replace just the System.Web namespace for starters, but I doubt it's going to be that easy. marek On Wed, Nov 19, 2014 at 3:28 PM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: On 19/11/14 20:50, Martin Thwaites wrote: Hey Martin, Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Please be especially careful with System.Web - there are plenty of mines buried there. Both in our and in Microsoft code. The latter codebase uses a lot of native Win32 methods which may not have portable (POSIX, preferably) counterparts. Our code, OTOH, has a lot of cruft from the 1.1 days. The biggest problem with our code, however, is its reliance on an early (wrong) assumption that ASP.NET http://ASP.NET pages are, in fact, valid HTML. The parser is such a convoluted piece of misery that touching it in a wrong way causes System.Web to fall apart. If you want to start contributing I'd start there since there are issues we cannot fix using the current parser (especially the conditional parsing part). I dare say that System.Web will be one of the most challenging parts to port. Good luck and if you need any reviews and/or help don't hesitate to contact me. marek Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey, I do not think we would be moving the code. We would do two things: * Make changes to the fork in mono/referencesoure * Reference the new files from mono/external/referencesource Miguel On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.__uk mailto:monofo...@my2cents.co.uk wrote: HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com mailto:mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/__docs/about-mono/dotnet-__integration/ http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/__net-framework-integration-__into-mono https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel _ Mono-list maillist - mono-l...@lists.ximian.com mailto:mono-l...@lists.ximian.com mailto:Mono-list@lists.__ximian.com mailto:mono-l...@lists.ximian.com http://lists.ximian.com/__mailman/listinfo/mono-list http://lists.ximian.com/mailman/listinfo/mono-list _ Mono-devel-list mailing list Mono-devel-list@lists.ximian.__com mailto:Mono-devel
Re: [Mono-dev] Crash course on bringing .NET open sourced code to Mono.
On 15/11/14 15:48, Miguel de Icaza wrote: Each one needs to be discussed Some of the Ms behaviors don't work on Unix, so not only we shouldn't bring it, we should work towards a better shared set of new Apis I would be all in favor of this approach. In fact, I'd advocate for having a rule that forbids bringing non-trivial Microsoft sources to Mono as they are. Not because they are bad, but precisely because they have lots of Windows-specific code that will not work on other platforms. The fact is that Mono source code is far more portable in many areas. I think the way to work with it is to review each non-trivial source side-by-side and bring the missing bits to the Mono side (as well as fix the apparent bugs) by modifying the Mono sources using the Microsoft ones as reference. Adding tests in the process will ensure that the behavior is the same for both sets of sources and, in the end, we'll have a solid base for the better API Miguel mentions. Mono sources could serve as the base for this being curated for portability over 14 years of development (first, of course, we'd have to get rid of the #ifdef cruft, clean up the sources, get rid of all the guesswork implementations we had to do over the years). In general, I think we shouldn't rush anything but take our time to produce codebase that merges the best of both worlds. Community help would be greately appreciated here - the more eyes on the sources, the better. We should peruse PRs and put as many eyes on them as possible. marek Not sure what you meant in this specific case. On Saturday, November 15, 2014, Greg Young gregoryyou...@gmail.com mailto:gregoryyou...@gmail.com wrote: What's the plan on where there are differences in behavior? An example of this would be uri matching. I would guess it makes sense to use the ms stuff moving forward, how will changes in current behavior be communicated On Saturday, November 15, 2014, Miguel de Icaza mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@xamarin.com'); wrote: Hey guys, Sami reached out to me, and was wondering how to get started in bringing some code to Mono, in particular WCF to Mono. So I wrote this small guide for newcomers. I would say it takes a couple of steps: * Build your own local version of Mono on Linux. * Make sure it works mcs should be able to run after installing it. * Run a trivial self-hosted WCF server/client * Make a trivial change to the WCF class library, and install this version to test you can make changes locally and have them run: o cd mono/mcs/class/System.ServiceModel o Make changes o make install o Run your test again in another window o Repeat * Make sure you can run the test suite: o cd mono/mcs/class/System.ServiceModel o make run-test-local Once you are ready, you can start importing code. Ideally, you want to go for high-value targets: the most buggy parts of Mono's stack (you can check bugzilla for reports on memory usage, bugs). Or you can pick a missing feature. To import code, modify the relevant .sources file in the System.ServiceModel directory (where you ran the test) and replace a local file, with a reference to the referencesource. Chances are, you will need to make changes to the referencesource code, since a lot of it is Windows specific. Miguel On Fri, Nov 14, 2014 at 5:25 PM, Sami Ben Grine sben-gr...@axarosenberg.com wrote: Sweet – is there anything I can do to make progress? __ __ I am somewhat ignorant about Mono but I am pretty ok with .NET and Linux. __ __ thanks -- Studying for the Turing test ___ 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] Size of thread in Mono (65MB per thread?)
On 12/20/2013 09:10 , Nicolas Antoniazzi wrote: I am not using OpenVZ but a solution that we developed based on Linux kernel calls because we really need to bootstrap a virtual environment in less than 50ms. I tested the same program on a .Net platform and after 1000 threads created, the whole application used 48MB of RAM. It sounds really strange to me that a Thread, that in theory should be a light process, takes 65MB of virtual memory. In the meantime, I am not expert in differences between virtual and physical memory, but, does your answer mean that if mono would detects that my system only has 500MB of physical memory, it would reserve less amount of memory per thread? Unix systems work based on a bit different principle than the Windows ones. Namely, as Nikita mentions in his other mail, the virtual memory is nearly free of any limits - your process reserves the right to use that much memory, but it doesn't actually use (commit) it physically. The virtual memory reservation is merely a hint of what can be consumed by the program, should it need it. You can observe that by running the following command on Linux: ps axu|less now look at the headers at the top of the display: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1203 0.0 0.1 3436 1140 ?SNov30 0:00 upstart-udev-bridge --daemon root 1209 0.0 0.1 9552 1416 ?Ss Nov30 0:00 /lib/systemd/systemd-udevd --daemon The VSZ and RSZ columns represent, respectively, the virtual (reserved) and real (committed) memory - you always want to look at the latter for actual memory usage of a process. Now, in my opinion, any virtualization system that limits the virtual memory is inherently flawed (at least on Linux) and this is because of the RSS vs VSZ difference I explained above but also because of another detail. Namely, each thread, as you know, is not a separate process per se (even though it's got its own PID) but rather a compartment in your parent process which has its own stack, own CPU state etc but it *still* lives in the same memory space and share the memory allocation with the parent. So if you look at the thread's memory usage figures you will get exactly the same numbers as for the main process - but it does not mean the each thread is using that much memory. In fact, memory is not allocated to the thread but to the process only. Therefore, if your virtualization software looks at each PID's virtual memory usage and imposes a limit on that figure, then certainly, you will get an OOM in no time - even though the physical memory usage will be actually much lower. hope that helps a bit, marek Maybe there is a way to send some parameters to mono or to change some content in /proc to simulate a smaller amount of physical memory? Thanks for your answer! 2013/12/20 Nikita Tsukanov kek...@gmail.com mailto:kek...@gmail.com Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization. Regards, Nikita 2013/12/19 Nicolas Antoniazzi nicolas.antonia...@gmail.com mailto:nicolas.antonia...@gmail.com Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already consumed without the use of any thread. Is it a normal behavior? P.S: Sorry I double posted this message on mono-list because I did not understood that third party programmers also had to come on this devel list. Thanks! -- Nicolas Antoniazzi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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 mailto: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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Size of thread in Mono (65MB per thread?)
On 12/20/2013 10:48 , Nicolas Antoniazzi wrote: Ok, I understand better the underline mechanism. I will try change my virtualization system with cgroups to simulate limitation of physical memory. But in the meantime, I am curious to know what is the need for a thread to reserve 64MB of virtual memory. I understand a need of 1 or 2MB for its stack plus few other kilos. But 64MB seems a lot to me :) I don't think it's the thread itself that reserves the memory. Your test program stashed that much of data/code in RAM and the figure is simply reported by each thread/LWP. As for the actual per-thread memory usage, you'd need to defer to somebody who worked on their implementation in the Mono runtime (I didn't), but I would be surprised if it was a large number. marek Thanks a lot for your help! 2013/12/20 Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net On 12/20/2013 09:10 , Nicolas Antoniazzi wrote: I am not using OpenVZ but a solution that we developed based on Linux kernel calls because we really need to bootstrap a virtual environment in less than 50ms. I tested the same program on a .Net platform and after 1000 threads created, the whole application used 48MB of RAM. It sounds really strange to me that a Thread, that in theory should be a light process, takes 65MB of virtual memory. In the meantime, I am not expert in differences between virtual and physical memory, but, does your answer mean that if mono would detects that my system only has 500MB of physical memory, it would reserve less amount of memory per thread? Unix systems work based on a bit different principle than the Windows ones. Namely, as Nikita mentions in his other mail, the virtual memory is nearly free of any limits - your process reserves the right to use that much memory, but it doesn't actually use (commit) it physically. The virtual memory reservation is merely a hint of what can be consumed by the program, should it need it. You can observe that by running the following command on Linux: ps axu|less now look at the headers at the top of the display: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1203 0.0 0.1 3436 1140 ?SNov30 0:00 upstart-udev-bridge --daemon root 1209 0.0 0.1 9552 1416 ?Ss Nov30 0:00 /lib/systemd/systemd-udevd --daemon The VSZ and RSZ columns represent, respectively, the virtual (reserved) and real (committed) memory - you always want to look at the latter for actual memory usage of a process. Now, in my opinion, any virtualization system that limits the virtual memory is inherently flawed (at least on Linux) and this is because of the RSS vs VSZ difference I explained above but also because of another detail. Namely, each thread, as you know, is not a separate process per se (even though it's got its own PID) but rather a compartment in your parent process which has its own stack, own CPU state etc but it *still* lives in the same memory space and share the memory allocation with the parent. So if you look at the thread's memory usage figures you will get exactly the same numbers as for the main process - but it does not mean the each thread is using that much memory. In fact, memory is not allocated to the thread but to the process only. Therefore, if your virtualization software looks at each PID's virtual memory usage and imposes a limit on that figure, then certainly, you will get an OOM in no time - even though the physical memory usage will be actually much lower. hope that helps a bit, marek Maybe there is a way to send some parameters to mono or to change some content in /proc to simulate a smaller amount of physical memory? Thanks for your answer! 2013/12/20 Nikita Tsukanov kek...@gmail.com mailto:kek...@gmail.com mailto:kek...@gmail.com mailto:kek...@gmail.com Don't use OpenVZ, it limits _virtual_ memory, not physical. Mono threads use a small amount of physical memory, but might reserve high of virtual memory space. You'd rather try KVM/Xen virtualization. Regards, Nikita 2013/12/19 Nicolas Antoniazzi nicolas.antonia...@gmail.com mailto:nicolas.antonia...@gmail.com mailto:nicolas.antoniazzi@__gmail.com mailto:nicolas.antonia...@gmail.com Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any
Re: [Mono-dev] Mono Project: Next Steps
On Thu, 7 Jul 2011 10:04:31 +0200 Alex xtzgzo...@gmail.com wrote: Hi, Hey, I would be eternally grateful if someone made that possible; Cygwin is a major pain in the butt to build anything with... Note that you can also cross-compile for Windows from Linux, see the build-mingw32.sh script in the Mono sources. best, marek Regards, Alex On Thu, Jul 7, 2011 at 7:41 AM, Frank Fuchs fk.fu...@googlemail.com wrote: Hello folks, Some of you have been asking about the upcoming release of Mono 2.12. We hit a little bit of a bump in the road with the layoff of the Mono team, but we have now re-constituted the team at Xamarin and we are getting back to speed. Our first priority at Xamarin is to ensure that our amazing team of hackers remains employed, so we are focused on creating amazing products for the mobile space. Of course, our products are entirely based on Mono, and as you can see from the commits to the various Mono modules, a lot of our energy goes into improving Mono. To get the 2.12 release to your hands, here?s what we still need to do: (a) We need to be able to build packages (b) We need to be able to host the software (c) We need to adopt the branching and release procedures. During the transition to Xamarin, we lost our build engineer. But luckily at Xamarin we?ve hired Alex Corrado, a very talented developer who?s created a new build system for Mono. The good news is that we are making progress and we are now able to build Linux and MacOS packages. Next, Alex is working on Windows builds. We are not there yet, but we will be there in the next couple of weeks. Once we have packages, we will setup a new website for the Mono project where we can host the software and the other project resources, like a wiki, forums, etc. So we are working on a separate domain to host both a Mono web site and the software, and that should be up in the next week or two. Once we have something ready, we will share the information with the rest of the world and give access to the new Wiki to the various maintainers to help us keep the content up to date. Thank you for your patience and your love for Mono! Miguel Maybe this is a good chance to dump the cygwin stuff and switch to Mingw-w64 and MSys (as native toolchain for Windows). It is possible to build mono in 32 and 64bit with it - some people lurking around at this list have done it (including me). Best, Frank ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ASP.NET MVC 3 with Razor on Mono 2.10.1 ?
On Sun, 01 May 2011 18:52:21 +0200 Quandary quandar...@hailmail.net wrote: Hey, Thanks Robert, that helped somewhat. Now, the following dll's are in the bin directory: ls *.dll MyProject.dll System.Web.Routing.dll System.Web.Entity.dll System.Web.WebPages.Administration.dll System.Web.Extensions.dll System.Web.WebPages.Deployment.dll System.Web.Helpers.dll System.Web.WebPages.dll System.Web.Mvc.dll System.Web.WebPages.Razor.dll You must remove System.Web.Entity (Mono doesn't have the EntityFramework), System.Web.Extensions (it's probably a .NET assembly, Mono has its own version - the .NET one will not work with Mono), System.Web.Routing (the same - Mono has its own version, also in .NET 4.0 this assembly is practically empty since the routing classes were moved to System.Web proper) and now I get this error on http://localhost:8080 : /Could not load type 'System.Web.WebPages.Razor.RazorBuildProvider' from assembly 'System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'./ This might go away after you remove the assemblies I listed above. And if I switch to http://localhost:8080/Sandbox, I get this: /Invalid IL code in System.Web.Handlers.ScriptModule:.ctor (): method body is empty./ *Description: *HTTP 500. Error processing request. *Stack Trace:* System.InvalidProgramException: Invalid IL code in System.Web.Handlers.ScriptModule:.ctor (): method body is empty. at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] in filename unknown:0 This looks like a genuine bug, although let's see if removing the aforementioned assemblies helps here as well. Also, please consider upgrading your Mono to version 2.10.2 - it includes important fixes which apply to ASP.NET and related technologies. marek On 05/01/2011 01:09 AM, Robert Jordan wrote: On 30.04.2011 23:08, Quandary wrote: Hi, I'm trying to get ASP.NET MVC3 with Razor to run on Linux. I localcopied all necessary dll's ( System.Web.Helpers.dll System.Web.Mvc.dll System.Web.Razor.dll System.Web.WebPages.dll ) You need to copy more MS assemblies into your app's bin directory: System.Web.Mvc.dll System.Web.Razor.dll System.Web.WebPages.dll System.Web.WebPages.Deployment.dll System.Web.WebPages.Razor.dll Robert ___ 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] Patch for StopRoutingHandler - stop handling routes instead of throwing
On Fri, 14 Jan 2011 15:43:08 +0100 Damir Simunic damir.simu...@wa-research.ch wrote: Hi all, Hey, noticed that adding routes using StopRoutingHandler() throws NotSupportedExceptions instead of simply ceasing further processing in the UrlRoutingModule. Attached is the patch I wrote to change that behavior on master branch, accompanied with a unit test. Committed to master, mono-2-10 and mono-2-8 - thanks for the contribution :) marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Windows Integrated Authentication
On Thu, 25 Nov 2010 11:28:39 +0100 Helmut Ziegler helmut_zieg...@gmx.de wrote: Hi Marek, Hi, thanks for the prompt answer! I think forms authentication could be a way to go, but your answer pushed my thoughts in to several direction. And I have to think and test these thought a bit. Nevertheless, Windows Integrated Authentication would be the easiest way to go. Especially in the current project, which focuses on the windows platform only and has a tight schedule. I think I tell something more about our scenario, to make things and possibilities clearer. We want to use the Mono Server only on clients to run the MVC web app locally. In order to limit the usage of the app to a specific domain and specific users using the Integrated Authentication would be the best way. If possible, we don't want users to have extra login via form. So you want the app to run on a local windows machine, using local user credentials or using windows domain credentials? From what you wrote above I have the impression that your users are members of a windows domain, which means their accounts are in ActiveDirectory. If this is the case, you can implement Mono's System.Web.Security.ActiveDirectoryMembershipProvider to the directory server in order to authenticate the users against that service. Of course, it would require completing the implementation of Mono's WindowsIdentity principal (in corlib/System.Security.Principal/WindowsIdentity) and the System.Web.Security.WindowsAuthenticationModule (you could use our FormsAuthenticationModule as the model). Implementing the two latter types would give you access to local Windows user credentials. None of those tasks should be too complicated. As far as I can see, there are two possibilities to make use of the Integrated Authentication: * As we start the Mono Server via console app we could read the WindowsIdentity and hand it over somehow to our web app. If the app is ran by Mono, then this approach won't solve the problem. If it is a native app or it runs with .NET, then you can just make sure that it's the console launcher that authorizes the user and runs the application (perhaps under a secured local user account - using impersonation) only if the authentication/authorization was successful. * We enhance the Mono Server, so it can read the WindowsIdentity. That would be very welcome, especially if you contributed to Mono the patches :) As I haven't put my fingers on programming a server so far, I'm a bit sceptical about the second possibility. Mainly, as I don't know how much effort it would be ... As said above, I don't think it would be a lot of work. WindowsIdentity is already partially implemented and the WindowsAuthenticationModule should be pretty straightforward to code. best, marek Cheers, Helmut Original-Nachricht Datum: Wed, 24 Nov 2010 17:46:46 +0100 Von: Marek Habersack gren...@twistedcode.net An: agez helmut_zieg...@gmx.de CC: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Windows Integrated Authentication On Wed, 24 Nov 2010 07:11:11 -0800 (PST) agez helmut_zieg...@gmx.de wrote: Hi, Hey, we're developing an ASP.Net MVC2 web application for the Intranet and wanted to use Windows Integrated Authentication. Everything works fine with the Visual Studio Development Server or IIS. But we wanted to switch to a Mono Server. And there the user's identity isn't available. So authorization doesn't work. As Mono aims to be platform independent this is understandable, but does anyone know how to get around this? The best option, imho, is to use the forms authentication framework (unless you have a very specific application which absolutely needs to use the Unix/Windows user database). You can take advantage of the Membership and Role providers in your MVC application - implementations of them exist for basically every RDBMS and also for LDAP, plain XML, plain text files (alas, Mono's implementation of the ActiveDirectoryMembershipProvider is just a stub - patches welcome, of course :D). If you can't find a provider that suits your needs, it's easy to create a custom one, tailored to your environment. If this is not desirable, you can easily roll out your own authentication provider using any database (from LDAP/ActiveDirectory to any RDBMS) as the backend and just the forms authentication ticket/cookie services to keep the user logged in. If you wanted to authenticate users on Linux using their physical account credentials then things will get a bit complicated. In order to be absolutely compatible with the multitude of ways to authenticate users on Linux you'd have to use PAM and that would require either to grant your application special rights or use a daemon to which the application would talk in order to authenticate the users. If you want to keep your
Re: [Mono-dev] Windows Integrated Authentication
On Wed, 24 Nov 2010 07:11:11 -0800 (PST) agez helmut_zieg...@gmx.de wrote: Hi, Hey, we're developing an ASP.Net MVC2 web application for the Intranet and wanted to use Windows Integrated Authentication. Everything works fine with the Visual Studio Development Server or IIS. But we wanted to switch to a Mono Server. And there the user's identity isn't available. So authorization doesn't work. As Mono aims to be platform independent this is understandable, but does anyone know how to get around this? The best option, imho, is to use the forms authentication framework (unless you have a very specific application which absolutely needs to use the Unix/Windows user database). You can take advantage of the Membership and Role providers in your MVC application - implementations of them exist for basically every RDBMS and also for LDAP, plain XML, plain text files (alas, Mono's implementation of the ActiveDirectoryMembershipProvider is just a stub - patches welcome, of course :D). If you can't find a provider that suits your needs, it's easy to create a custom one, tailored to your environment. If this is not desirable, you can easily roll out your own authentication provider using any database (from LDAP/ActiveDirectory to any RDBMS) as the backend and just the forms authentication ticket/cookie services to keep the user logged in. If you wanted to authenticate users on Linux using their physical account credentials then things will get a bit complicated. In order to be absolutely compatible with the multitude of ways to authenticate users on Linux you'd have to use PAM and that would require either to grant your application special rights or use a daemon to which the application would talk in order to authenticate the users. If you want to keep your server/application users in one place and use the same credentials on Linux, Windows and your MVC app, then I'd recommend looking at OpenLDAP to implement your own directory server. Hope that helps a bit, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ASP.MVC Accesing HttpContext.Current from AsyncController action..
On Sun, 3 Oct 2010 02:03:32 +0200
Pablo Ruiz pablo.r...@gmail.com wrote:
Hey,
Please file a bug report with an attached self-contained, small and
fully working sample
demonstrating the issue (http://mono-project.com/Bugs, the Sys.Web component),
thanks.
marek
I have an ASP MVC2 application (running under mono 2.8 p1) which has an
async action (ValidateAsync) which handles user verification by consulting
an external subsystem (hence the async nature of the operation), after a
valid response it's received by the async completed method
(ValidateCompleted), the user it's authenticated by using
FormsAuthentication..
The code it's working ok on MS side, however, on mono looks like
HttpContext.Current it's not (re-)set before calling async action response
method..
Has anyone tried MVC2 Async action methods on mono?
Here it's a stacktrace of the failure:
System.Web.HttpException: Context is null!
at System.Web.Security.FormsAuthentication.SetAuthCookie
(string,bool,string) [0x00042] in
/usr/src/redhat/BUILD/mono-2.8/mcs/class/System.Web/System.Web.Security/FormsAuthentication.cs:654
at System.Web.Security.FormsAuthentication.SetAuthCookie (string,bool)
[0x5]
in
/usr/src/redhat/BUILD/mono-2.8/mcs/class/System.Web/System.Web.Security/FormsAuthentication.cs:640
at Herma.WebSite.FormsAuthenticationService.SignIn (string,bool) [0x0001b]
in
/srv/hudson/workspace/Herma-v1.x/BUILD/Herma/WebSite/Services/FormsAuthenticationService.cs:25
at Herma.WebSite.Controllers.AccountController.ValidateCompleted
(Herma.WebSite.Models.AccountValidationModel,Herma.Messaging.AccountValidationRes)
[0x0002d]
in
/srv/hudson/workspace/xxx-v1.x/BUILD/xxx/WebSite/Controllers/AccountController.cs:185
at
(wrapper dynamic-method)
System.Runtime.CompilerServices.ExecutionScope.lambda_method
(System.Runtime.CompilerServices.ExecutionScope,System.Web.Mvc.ControllerBase,object[])
IL 0x00035, 0x00088
at System.Web.Mvc.ActionMethodDispatcher.Execute
(System.Web.Mvc.ControllerBase,object[]) IL 0x8, 0x00018
at
System.Web.Mvc.Async.ReflectedAsyncActionDescriptor/BeginExecutec__AnonStorey2E.m__34
(System.IAsyncResult) IL 0x00047, 0x000bf
at System.Web.Mvc.Async.AsyncResultWrapper/WrappedAsyncResult`1object.End
() 0x0004e
at System.Web.Mvc.Async.AsyncResultWrapper.Endobject
(System.IAsyncResult,object) 0x00035
at System.Web.Mvc.Async.ReflectedAsyncActionDescriptor.EndExecute
(System.IAsyncResult) IL 0x0, 0x0001c
at
System.Web.Mvc.Async.AsyncControllerActionInvoker/BeginInvokeAsynchronousActionMethodc__AnonStorey21.m__1C
(System.IAsyncResult) IL 0x7, 0x00018 at
System.Web.Mvc.Async.AsyncResultWrapper/WrappedAsyncResult`1System.Web.Mvc.ActionResult.End
()
0x0004e at
System.Web.Mvc.Async.AsyncResultWrapper.EndSystem.Web.Mvc.ActionResult
(System.IAsyncResult,object) 0x00035
at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod
(System.IAsyncResult) IL 0x0, 0x0001a
at
System.Web.Mvc.Async.AsyncControllerActionInvoker/BeginInvokeActionMethodWithFiltersc__AnonStorey1E/BeginInvokeActionMethodWithFiltersc__AnonStorey1F.m__27
() IL 0x00030, 0x00062 at
System.Web.Mvc.Async.AsyncControllerActionInvoker/InvokeActionMethodFilterAsynchronouslyc__AnonStorey25.m__20
() IL 0x8, 0x00028
And here it's a sample snippet of the code failing:
[HttpPost]
public void ValidateAsync(AccountValidationModel model)
{
AsyncManager.Parameters[model] = model;
if (!ModelState.IsValid)
{
AsyncManager.Parameters[result] = false;
return;
}
try
{
AsyncManager.OutstandingOperations.Increment();
AsyncManager.Timeout = 15000;
_bus.SendAccountValidationReq(x =
{
x.Email = model.Email;
x.Random = model.Code;
})
.RegisterAccountValidationRes(x =
{
AsyncManager.Parameters[result] = x;
AsyncManager.OutstandingOperations.Decrement();
});
}
catch (TimeoutException ex)
{
AsyncManager.Parameters[result] = AccountValidationRes.Timeout;
AsyncManager.OutstandingOperations.Decrement();
_Log.Error(Account validation request timedout, ex);
}
}
public ActionResult ValidateCompleted(AccountValidationModel model,
AccountValidationRes result)
{
if (result == AccountValidationRes.Success)
{
FormsService.SignIn(model.Email, false /* createPersistentCookie */);
return this.RedirectToActionHomeController(x = x.Index());
}
return View(model);
}
Greets.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] status of asp.net 4.0
On Sun, 22 Aug 2010 07:59:20 + Sharique uddin Ahmed Farooqui saf...@gmail.com wrote: Hey, Hi, I know that there are many features of .net 4 are being implemented. I want to the status of asp.net 4.0, I'm particularly interested in cleaner html and url rewriting. The only major part missing from System.Web (but in the works atm) is the Menu class rendering support for the the List rendering mode. Routing is fully supported. System.Web.Extensions hasn't been touched yet for 4.0. You need to use Mono from master or wait for 2.8 in order to take advantage of the code. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ASP.NET MVC 3 Preview
On Wed, 4 Aug 2010 10:25:21 -0300 Rafael Teixeira mono...@gmail.com wrote: Hey, Can you try to debug it with MonoDevelop? (latest versions enable the soft debugger for ASP.NET (xsp)). It sure seems like some path transformation or file-access mishap, although the responsible to tell the view is available is each view engine and there should be code that is dependent on something else that isn't available. I think it's something more involved. First, System.Web.Mvc references System.Entity.Data which we don't have. Second, mvc3 use a service locator implementation which is used internally to locate view engines and the locator failing might be the reason why it cannot find the views. Removing any [MonoTODO], of course, doesn't matter here. Until MVC3 source is out, I can't help you more, I'm sorry. When it is out we will have to determine whether it can be compiled without System.Data.Entity support and what's going on with the service location. best, marek Ideally you should compile ASP.NET MVC from sources, but they seem not to be available yet, to have debug symbols in Mono's format so you can step in that code and see what is happening. Fun, Rafael Monoman Teixeira --- To be creative means to be in love with life. You can be creative only if you love life enough that you want to enhance its beauty, you want to bring a little more music to it, a little more poetry to it, a little more dance to it. Osho On Tue, Aug 3, 2010 at 2:30 PM, Tomi bosak.to...@gmail.com wrote: I didn't remove that attribute to fix the exception permanently. According to documentation, the assembly should be now loaded with full trust, which probably shouldn't break anything (I may be wrong of course). Broken environment would probably affect also MVC 2 application targeted to run on .net 4.0 which however work as expected. The only difference in deployed web application is System.Web.Mvc.dll in bin folder. On 3 August 2010 19:07, Robert Jordan robe...@gmx.net wrote: On 03.08.2010 18:25, Tomi wrote: Hi folks, I wanted to try out preview version of ASP.NET MVC 3 on trunk version of mono, so I downloaded it from git (mono, xsp, mod_mono). Then I removed [MonoTODO] attribute on line 806 (IsFullyTrusted property) in Assembly.cs (http://github.com/mono/mono/blob/master/mcs/class/corlib/System.Reflection/Assembly.cs) because otherwise I would get Method not found error. After setting up this modified parallel environment and configuring apache/mod_mono to use mod-mono-server4 I get this stuff: This makes absolutely no sense. Removing [MonoTODO] does not fix Method not found exceptions. I believe you've got a broken development/testing environment (mixed 2.0 and 4.0 assemblies). Robert ___ 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 ___ 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] github workflow proposals
On Tue, 27 Jul 2010 18:41:46 -0400 Geoff Norton gnor...@novell.com wrote: On 2010-07-27, at 6:21 PM, Alan wrote: For commit messages, how about gnome style ones? http://live.gnome.org/Git/CommitMessages This is actually very nice. My only concern is maintaining the list of [Tag]'s. My sentiment as well. I think the [Tag] is pretty useless in our case. marek -g We'll end up with messages like this: http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2 :) Alan. On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst mark.pro...@gmail.com wrote: On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera kump...@gmail.com wrote: I have another proposition to make. Can we stop using Changelog files? Those can be generated from the commit logs for tarballs and releases without losing anything at all. Commit messages would still have to be at least as informative as they currently are. Not having Changelog files resolve 90%+ of our sources of conflicts and make the forkqueue much more useful. If we are to move to a DVCS style of development, this will be a big barrier otherwise. I totally agree with this. A few days ago I wanted to merge a simple commit Sanjoy made, and the fork queue would have been perfect for this. Unfortunately it didn't grok the ChangeLog conflict, so I had to pull the change myself, rebase it on master and then push it by hand. I also agree with the one-line summaries and work branches in private repositories. Mark ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with ASP.NET MVC 2: Flawed implementation of HttpServerUtility.Execute()?
On Sun, 9 May 2010 20:24:14 +0200 Oskar Berggren oskar.bergg...@gmail.com wrote: Hi, Hey, [snip] Any suggestions to resolve this? Yep - create a test case (self-contained), file a bug report and attach the test case to it (http://mono-project.com/Bugs, file the bug for the System.Web component) thanks, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] New performance counter in Mono to report physical memory size in the machine
On Sat, 17 Apr 2010 18:14:49 -0800 (PST) jmalcolm malcolm.jus...@gmail.com wrote: Hello, Thanks Marek, Does this live in System.Diagnostics? Yes, Does this mean that the code you posted would fail on Microsoft.NET with an InvalidOperationException? Using this particular category, yes - it is described in the article as Mono-specific and the constructor is supposed to throw the exception (see http://msdn.microsoft.com/en-us/library/z0wssx8x.aspx) System.Diagnostics seems like the place Microsoft should have put it. I am just surprised to see a Mono extension that does not have it's own assembly or namespace. There are probably more that I have managed to miss or simply forgotten about. There's nothing to be put in a separate assembly. The code throws an exception not because we extended something, but because the performance counter _category_ doesn't exist (http://www.mono-project.com/Mono_Performance_Counters#Category:_Mono_Memory) on .NET. Replace Mono Memory with any other non-Mono specific category in the list and it will work. You are always expected to handle the exceptions that are thrown by the class code - the sample is just a simple snippet of code to show a technique. Performance counters are implemented in the Mono runtime, not in managed code, so they don't belong in any assembly. Would something like the following be portable? Both your code and the sample are perfectly portable. [snip] Sorry if this is a basic question but I am currently on a Windows machine. Building Mono from trunk on Windows is not an area of strength for me and I have not really played around with this part of the framework before. I've updated the article with an extended sample and a note about the exception. I've noticed that Mono doesn't throw the InvalidOperationException for missing categories. Will look into that later today. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] New performance counter in Mono to report physical memory size in the machine
On Sun, 18 Apr 2010 08:00:04 -0400
Jay R. Wren jrw...@xmtp.net wrote:
Hello,
Confirmed, the constructor throws InvalidOperationException with a
message of Category does not exist. on .NET 4.
The code you pasted falls through to Cannot detect Physical RAM.
It is not a big deal, but it is something of which people should be aware.
The behavior is exactly as documented in MSDN documentation for the
PerformanceCounter class -
there are no surprises there.
marek
--
Jay
On 4/17/2010 10:14 PM, jmalcolm wrote:
Thanks Marek,
Does this live in System.Diagnostics?
Does this mean that the code you posted would fail on Microsoft.NET with an
InvalidOperationException?
System.Diagnostics seems like the place Microsoft should have put it. I am
just surprised to see a Mono extension that does not have it's own assembly
or namespace. There are probably more that I have managed to miss or simply
forgotten about.
Would something like the following be portable?
--- CUT ---
using System;
using System.Diagnostics;
class app
{
static void Main ()
{
if (PerformanceCounterCategory.Exists(Mono Memory))
{
var pc = new PerformanceCounter (Mono Memory, Total Physical
Memory);
Console.WriteLine (Physical RAM (bytes): {0}, pc.RawValue);
}
else
{
Console.WriteLine(Cannot detect physical RAM);
}
}
}
--- CUT ---
Sorry if this is a basic question but I am currently on a Windows machine.
Building Mono from trunk on Windows is not an area of strength for me and I
have not really played around with this part of the framework before.
___
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
[Mono-dev] New performance counter in Mono to report physical memory size in the machine
Hey everybody,
This is just to let you know that Mono in trunk has a new performance
counter which returns
the amount of physical RAM in the machine. The need to add such a counter arose
from the fact that
there's no means in .NET to get this piece of information. Also, different
operating system have
different ways of obtaining the information. Here's the excerpt of code which
will get you the
information on Mono/trunk (and 2.8+ when it's released):
--- CUT ---
using System;
using System.Diagnostics;
class app
{
static void Main ()
{
var pc = new PerformanceCounter (Mono Memory, Total Physical Memory);
Console.WriteLine (Physical RAM (bytes): {0}, pc.RawValue);
}
}
--- CUT ---
Code, as committed, works on Linux, {Open,Free,Net}BSD, Solaris,
MacOS/X and Windows. If
your operating system reports invalid values (or reports 128MB even though you
have 1TB of RAM)
please either file a bug or, better yet, provide a patch which adds support for
your OS.
Hope somebody finds that useful,
marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono 2.6.3 breaks https connections
On Fri, 19 Mar 2010 11:22:49 +0100 Latif Khalifa lati...@radegastclient.org wrote: Hello, Yes, in order to provide X509 certificate generation capability, that would also work when executing under .NET, we've been including Mono.Security assembly with our binaries. That worked until 2.6.3. I guess we now have to find out a different way to generate self-signed server certs for https connections, that would run from the same set of shipped executables under both runtimes. I'm guessing you need your own copy of Mono.Security only when running on .NET. The solution in such case is easy - use reflection to load the types you need. If you detect you're running on Mono, do this: Assembly asm = Assembly.Load (Mono.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756); or even Assembly asm = Assembly.Load (Mono.Security); if you don't care for the version. On .NET use: Assembly asm = Assembly.LoadFrom (\\path\\to\\local\\copy\\of\\Mono.Security.dll); And reflect on the returned assembly to get any types you want. best, marek On Fri, Mar 19, 2010 at 6:17 AM, Miguel de Icaza mig...@novell.com wrote: Hello, It seems to me that he has a local copy of Mono.Security that he is loading, and not using the system provided Mono.Security. On Fri, Mar 19, 2010 at 12:32 AM, Gonzalo Paniagua Javier gonzalo.m...@gmail.com wrote: On Fri, 2010-03-19 at 00:28 +0100, Latif Khalifa wrote: Just recompiled using mono 2.6.3 tarball and several of my applications stopped working, all displaying this on the console ** (OpenSim.exe:25319): WARNING **: Missing method .ctor in assembly /usr/lib/mono/gac/System/2.0.0.0__b77a5c561934e089/System.dll, type Mono.Security.Protocol.Tls.CertificateValidationCallback2 ** (OpenSim.exe:25319): WARNING **: The class Mono.Security.Protocol.Tls.CertificateValidationCallback2 could not be loaded, used in System ** (OpenSim.exe:25319): WARNING **: Missing method .ctor in assembly /usr/lib/mono/gac/System/2.0.0.0__b77a5c561934e089/System.dll, type Mono.Security.Protocol.Tls.CertificateValidationCallback2 Both OpenSimulator and LibOpenmetaverse worked fine up to mono 2.6.1 What prefix did you use when installing the tarball? That looks like the Mono.Security.dll you are using is the system installed one in /usr while the System.dll in your system has the latest changes from 2.6.3. -Gonzalo ___ 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 ___ 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] Removing Obsolete Code from Mono 2.8
On Mon, 01 Mar 2010 21:36:06 -0500 Miguel de Icaza mig...@novell.com wrote: Hello, [snip] There are many different versions of the SQLite provider. However, Mono has a couple of different versions: Mono.Data.SqliteClient which is 1.1 only. It will not work with NET_2_0 profile unless someone fixes it. Mono.Data.Sqlite - the 2.0 parts - is based on System.Data.Sqlite. Agreed, this is a good time to drop the old provider. Marek, how far did we deviate from the upstream code? And can we do a We renamed the namespace from System.Data.SQLite to Mono.Data.Sqlite, all the classes were renamed by changing the SQLite prefix to Sqlite (for compatibility with older SQLite provider we had), added some connection string compatibility code (some 40 lines of code) and that's basically it. code refresh without breaking the API? Yes. I can drop the old provider if someone tells me which one it is. The old one is Mono.Data.SqliteClient marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest Framework
On Thu, 11 Feb 2010 03:16:33 -0600 Tiaan Geldenhuys tag...@gmail.com wrote: Hello, The attached patch is a fix for System.Web.Security.Roles.IsUserInRole to prevent ASP.NET MVC errors like the one shown at the bottom, which happens when a user hasn't logged on and requests public pages with sections that are dynamically removed using role-based access-restrictions. It now behaves more like .NET that does not throw an exception. Thanks, that part of the patch looks ok. Writing a test for this fix was a bit of a challenge -- it's no wonder there is not any working test for the Roles class yet. :) To address this, the MonoTests.SystemWeb.Framework.WebTest class was updated slightly to make it possible to write self-contained tests for cases where you might want more control over the resources that are copied to your hosted web application, such as when creating Web.config files dynamically. The test for the current fix also serves as an example of how this can be done. If these changes are approved, one can expand on this for all the other Roles methods. Unfortunately, the test can't be implemented this way. I committed your code, but laid out in a slightly different manner. The RoleProvider definition went to Web.config and Web.mono.config resources since overwriting Web.config in the middle of running of the test suite is not acceptable - the configs contain settings other tests rely upon. However, I have decided to commit your changes to WebTest as they may come useful in other scenarios. Please review and commit. Committed in r151519 (trunk), r151520 (2.6 branch) and r151521 (2.4 branch - backported without the WebTest changes) Thank you, Thanks! marek Tiaan. NOTE: The patch files can be used without changes on both trunk and the 2.6 branch. --- [System.Web.HttpUnhandledException]: Exception of type 'System.Web.HttpUnhandledException' was thrown. at System.Web.UI.Page.ProcessException (System.Exception e) [0x0] in filename unknown:0 at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] in filename unknown:0 at System.Web.HttpApplication+Pipelinec__Iterator5.MoveNext () [0x0] in filename unknown:0 at System.Web.HttpApplication.Tick () [0x0] in filename unknown:0 [System.Web.HttpUnhandledException]: Exception of type 'System.Web.HttpUnhandledException' was thrown. at System.Web.UI.Page.ProcessException (System.Exception e) [0x0] in filename unknown:0 at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] in filename unknown:0 at System.Web.Mvc.ViewPage.RenderView (System.Web.Mvc.ViewContext viewContext) [0x0] in filename unknown:0 at System.Web.Mvc.WebFormView.RenderViewPage (System.Web.Mvc.ViewContext context, System.Web.Mvc.ViewPage page) [0x0] in filename unknown:0 at System.Web.Mvc.WebFormView.Render (System.Web.Mvc.ViewContext viewContext, System.IO.TextWriter writer) [0x0] in filename unknown:0 at System.Web.Mvc.ViewResultBase.ExecuteResult (System.Web.Mvc.ControllerContext context) [0x0] in filename unknown:0 at System.Web.Mvc.ControllerActionInvoker.InvokeActionResult (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ActionResult actionResult) [0x0] in filename unknown:0 at System.Web.Mvc.ControllerActionInvoker+InvokeActionResultWithFiltersc__Ano nStoreyE.m__11 () [0x0] in filename unknown:0 at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter (IResultFilter filter, System.Web.Mvc.ResultExecutingContext preContext, System.Func`1 continuation) [0x0] in filename unknown:0 [System.ArgumentException]: Username cannot be empty. at SomeRoleProvider.IsUserInRole (System.String username, System.String roleName) [0x0] in filename unknown:0 at System.Web.Security.Roles.IsUserInRole (System.String rolename) [0x0] in filename unknown:0 at ASP.views_shared_site_master.__RenderTree (System.Web.UI.HtmlTextWriter __output, System.Web.UI.Control parameterContainer) [0x0] in filename unknown:0 at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Control.RenderChildren (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Control.Render (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Page.Render (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.Mvc.ViewPage.Render (System.Web.UI.HtmlTextWriter writer) [0x0] in filename unknown:0 at System.Web.UI.Control.RenderControl (System.Web.UI.HtmlTextWriter writer)
Re: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest Framework
On Thu, 11 Feb 2010 11:58:53 -0600 Tiaan Geldenhuys tag...@gmail.com wrote: Hi Marek: Hey, Thanks for committing almost all the changes, especially the ones to WebTest. However, I would still like to get some ideas about a better way to then isolate the Web.config settings between different Tests and Test That's why I created support for standalone tests - see System.Web/Test/standalone* in trunk Fixtures -- because that seems to be the main issue with the changes that weren't approved, and having one RoleProvider configuration that must be shared between all tests is not really an option. The test suite doesn't like being restarted (which happens if you update Web.config, bin/*, App_* etc) and I have no time to spend fixing it atm. One approach could be to call WebTest.SetupHosting with a delegate that calls CopyResources to start with the default Web.config and then perhaps add the roleManager section programmatically in the setup delegate (instead I really see no reason for this. You can provide an implementation of a meta role provider which will dispatch the calls to the specific role provider you need in a particular test - that way you have only one role provider in the web.config. Or you can access the Roles.Providers collection directly to get any named provider you defined in web.config of overwriting the config file completely, like I did previously; and instead of always having the same RoleManager, like you now did, which could also interfere with other test that assume the default of not having any I know this is not ideal, but with the way the current test suite works this is the best we can get (or we can just create more standalone tests, which for this kind of test is the best option anyway) role manager, or at least with tests I would still like to contribute). If isolation between tests is important, then one could add tear-down logic to the test that could perhaps call WebTest.CleanApp (so that the next call to EnsureHosting would start from fresh). The problem with this approach is Yes, this is a solution but as said above - I don't have time to spend on this right now. Patches are welcome, of course :) that it seems to be very slow, and perhaps that's why the tests currently have to share their config. Speed doesn't matter in this case. Ideally one would want to re-use any existing host and simply add/remove settings to Web.config programmatically in the test's start-up/tear-down logic (after calling WebTest.EnsureHosting). But for this to work, WebTest.Run should only execute the next test after the updated Web.config has been loaded -- I've quickly tried this previously and ran into race conditions. Do you know of a way that this synchronization can be added to WebTest without too much trouble? I haven't spent any time on this, but I imagine it shouldn't be too complicated. best regards, marek Regards, Tiaan. -Original Message- From: Marek Habersack [mailto:gren...@twistedcode.net] Sent: 11 February 2010 8:18 AM To: Tiaan Geldenhuys Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] Fix Roles.IsUserInRole and enhance WebTest Framework On Thu, 11 Feb 2010 03:16:33 -0600 Tiaan Geldenhuys tag...@gmail.com wrote: Hello, The attached patch is a fix for System.Web.Security.Roles.IsUserInRole to prevent ASP.NET MVC errors like the one shown at the bottom, which happens when a user hasn't logged on and requests public pages with sections that are dynamically removed using role-based access-restrictions. It now behaves more like .NET that does not throw an exception. Thanks, that part of the patch looks ok. Writing a test for this fix was a bit of a challenge -- it's no wonder there is not any working test for the Roles class yet. :) To address this, the MonoTests.SystemWeb.Framework.WebTest class was updated slightly to make it possible to write self-contained tests for cases where you might want more control over the resources that are copied to your hosted web application, such as when creating Web.config files dynamically. The test for the current fix also serves as an example of how this can be done. If these changes are approved, one can expand on this for all the other Roles methods. Unfortunately, the test can't be implemented this way. I committed your code, but laid out in a slightly different manner. The RoleProvider definition went to Web.config and Web.mono.config resources since overwriting Web.config in the middle of running of the test suite is not acceptable - the configs contain settings other tests rely upon. However, I have decided to commit your changes to WebTest as they may come useful in other scenarios. Please review and commit. Committed in r151519 (trunk), r151520 (2.6 branch) and r151521 (2.4 branch - backported without the WebTest changes) Thank you, Thanks! marek Tiaan. NOTE
Re: [Mono-dev] ASP.NET website fails after update to 2.4.3
On Thu, 17 Dec 2009 10:06:42 +0100 Marek Habersack gren...@twistedcode.net wrote: Hello On Tue, 15 Dec 2009 17:18:32 -0700 Robert Abram li...@loneprairie.com wrote: Hello, I believe my error after upgrading from 2.4.2.3 to 2.4.3 on a test server is a similar problem. Please see attached test app. Excellent! It does reproduce the issue. I filed a bug report (https://bugzilla.novell.com/show_bug.cgi?id=565547) so that it doesn't skip my mind and will try to work on fixing it later tonight. The bug is fixed now, marek thanks a lot, best marek On the page, I have an ObjectDataSource which read two parameter values from controls on the page. asp:ObjectDataSource runat=server ID=odsECCNSummary TypeName=App.Test.ECCN SelectMethod=GetECCNSummaryWithFilter SelectCountMethod=GetECCNSummaryCountWithFilter EnablePaging=true SelectParameters asp:ControlParameter ControlID=ddlDate Name=year Type=Int32 / asp:ControlParameter ControlID=txtSearchValue Name=eccn Type=String / /SelectParameters /asp:ObjectDataSource Changing the control parameters to simple default parameters makes the page work. asp:Parameter Name=year Type=Int32 DefaultValue=2009/ asp:Parameter Name=eccn Type=String DefaultValue=test / This is code is right out of production that was working fine on 2.4.2.3 Regards, Robert System.NotSupportedException: CollectionConverter cannot convert from System.String. at System.ComponentModel.TypeConverter.GetConvertFromException (System.Object value) [0x0001d] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System/System.ComponentModel/TypeConverter.cs:161 at System.ComponentModel.TypeConverter.ConvertFrom (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value) [0x00017] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System/System.ComponentModel/TypeConverter.cs:79 at System.Web.UI.ObjectStateFormatter+TypeConverterFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x00030] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:1019 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:467 at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x6] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:715 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:467 at System.Web.UI.ObjectStateFormatter+ObjectArrayFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x00016] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:806 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:467 at System.Web.UI.ObjectStateFormatter+PairFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x00013] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:692 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:467 at System.Web.UI.ObjectStateFormatter+ObjectArrayFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x00016] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:806 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:467 at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x6] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:715 at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject
Re: [Mono-dev] [PATCH] XSP: Reliable socket closure on FastCGI Backend
On Wed, 16 Dec 2009 14:57:15 -0600 Tiaan Geldenhuys tag...@gmail.com wrote: Hello, The attached path fixes an issue where XSP's FastCGI Backend would sometimes close sockets before all data has made it to the FastCGI Server (web server), which leaves the FastCGI protocol in a bad state and can even truncate content to the web client prematurely. Committed (with a small cosmetic change - there's no point in catching ObjectDisposedException and ignoring it, as socket.Close () will throw it anyway as it should) in r148675 (trunk), r148676 (2.6 branch) and r148677 (2.4 branch). Thanks! best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ASP.NET website fails after update to 2.4.3
/System.Web.UI/ObjectStateFormatter.cs:222 at System.Web.UI.ObjectStateFormatter.Deserialize (System.IO.Stream inputStream) [0x00011] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:141 at System.Web.UI.ObjectStateFormatter.Deserialize (System.String inputString) [0x000a8] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs:169 at System.Web.UI.HiddenFieldPageStatePersister.Load () [0x7] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/HiddenFieldPageStatePersister.cs:61 at System.Web.UI.Page.LoadPageStateFromPersistenceMedium () [0xf] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/Page.cs:1908 at System.Web.UI.Page.LoadPageViewState () [0x0] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/Page.cs:1914 at System.Web.UI.Page.RestorePageState () [0x00051] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/Page.cs:1558 at System.Web.UI.Page.InternalProcessRequest () [0x001b9] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/Page.cs:1533 at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0005b] in /home/build/mono.2.4.3/mono-2.4.3/mcs/class/System.Web/System.Web.UI/Page.cs:1353 -Original Message- From: k0l0b0k k0l0b0k.v...@gmail.com To: gren...@twistedcode.net Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] ASP.NET website fails after update to 2.4.3 Date: Fri, 11 Dec 2009 00:09:03 +0200 Hello again, thanks for reply. I'm play with ObjectStateFormatter, and found this: if I add this check: !converter.CanConvertFrom (t) on line 441 of trunk's source as it was changed in this patch: http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System.Web/System.Web.UI/ObjectStateFormatter.cs?r1=143587r2=143967 application goes to work well. I did not understand how and why (no time for it), but it works. Thanks, Marek! 2009/12/10 Marek Habersack gren...@twistedcode.net: On Thu, 10 Dec 2009 23:08:55 +0200 k0l0b0k k0l0b0k.v...@gmail.com wrote: Good day! Hello, I have a production website, that runs on mod_mono on Debian Lenny, and after update from 2.4.2.3 to mono-2.4.3 few hours ago, application runs with some stranges (it works at all, but does not show some information). It looks like either a regression in ObjectStateFormatter or an issue with CollectionConverter. 2.4.3 has some changes in the former which introduced proper usage of type converters. It's hard to tell which of the above is true without getting a test case or access to your application so that I can reproduce the bug locally. Please file a bug and include a test case (or provide source for your application if you can). If you can't share your app's code publically and are unable to come up with a test case, please contact me privately at mhabers...@novell.com and we'll work something out. regards, marek In apache's error log I'm found: Runtime error: Exception of type 'System.Web.HttpUnhandledException' was thrown. at System.Web.UI.Page.ProcessException (System.Exception e) [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] Inner exception: CollectionConverter cannot convert from System.String. at System.ComponentModel.TypeConverter.GetConvertFromException (System.Object value) [0x0] at System.ComponentModel.TypeConverter.ConvertFrom (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value) [0x0] at System.Web.UI.ObjectStateFormatter+TypeConverterFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectArrayFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+PairFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r
Re: [Mono-dev] ASP.NET website fails after update to 2.4.3
On Thu, 10 Dec 2009 23:08:55 +0200 k0l0b0k k0l0b0k.v...@gmail.com wrote: Good day! Hello, I have a production website, that runs on mod_mono on Debian Lenny, and after update from 2.4.2.3 to mono-2.4.3 few hours ago, application runs with some stranges (it works at all, but does not show some information). It looks like either a regression in ObjectStateFormatter or an issue with CollectionConverter. 2.4.3 has some changes in the former which introduced proper usage of type converters. It's hard to tell which of the above is true without getting a test case or access to your application so that I can reproduce the bug locally. Please file a bug and include a test case (or provide source for your application if you can). If you can't share your app's code publically and are unable to come up with a test case, please contact me privately at mhabers...@novell.com and we'll work something out. regards, marek In apache's error log I'm found: Runtime error: Exception of type 'System.Web.HttpUnhandledException' was thrown. at System.Web.UI.Page.ProcessException (System.Exception e) [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] Inner exception: CollectionConverter cannot convert from System.String. at System.ComponentModel.TypeConverter.GetConvertFromException (System.Object value) [0x0] at System.ComponentModel.TypeConverter.ConvertFrom (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value) [0x0] at System.Web.UI.ObjectStateFormatter+TypeConverterFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectArrayFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+PairFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectArrayFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ArrayListFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ArrayListFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ArrayListFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+ObjectFormatter.ReadObject (System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at System.Web.UI.ObjectStateFormatter+TripletFormatter.Read (Byte token, System.IO.BinaryReader r, System.Web.UI.ReaderContext ctx) [0x0] at
[Mono-dev] [PATCH] IOMAP reporting - reimplemented as a profiler module
+211,14 @@ ves_icall_System_String_InternalAllocateStr (gint32 length)
{
MONO_ARCH_SAVE_REGS;
- return mono_string_new_size(mono_domain_get (), length);
+ if (mono_profiler_events MONO_PROFILE_STRING_ALLOC) {
+ MonoDomain *domain = mono_domain_get ();
+ MonoString *str = mono_string_new_size (domain, length);
+
+ mono_profiler_string_allocation (domain, str);
+ return str;
+ } else
+ return mono_string_new_size(mono_domain_get (), length);
}
MonoString *
diff --git a/mono/mini/method-to-ir.c b/mono/mini/method-to-ir.c
index 4d6f33d..2517797 100644
--- a/mono/mini/method-to-ir.c
+++ b/mono/mini/method-to-ir.c
@@ -49,6 +49,8 @@
#include mono/metadata/threads-types.h
#include mono/metadata/security-core-clr.h
#include mono/metadata/monitor.h
+#include mono/metadata/profiler-private.h
+#include mono/metadata/profiler.h
#include mono/utils/mono-compiler.h
#include mini.h
@@ -4189,7 +4191,7 @@ mini_redirect_call (MonoCompile *cfg, MonoMethod *method,
{
if (method-klass == mono_defaults.string_class) {
/* managed string allocation support */
- if (strcmp (method-name, InternalAllocateStr) == 0) {
+ if (strcmp (method-name, InternalAllocateStr) == 0 !(mono_profiler_events MONO_PROFILE_STRING_ALLOC)) {
MonoInst *iargs [2];
MonoVTable *vtable = mono_class_vtable (cfg-domain, method-klass);
MonoMethod *managed_alloc = NULL;
diff --git a/mono/profiler/Makefile.am b/mono/profiler/Makefile.am
index 0b0db4f..f9b674f 100644
--- a/mono/profiler/Makefile.am
+++ b/mono/profiler/Makefile.am
@@ -7,9 +7,9 @@ INCLUDES = \
if !DISABLE_PROFILER
if JIT_SUPPORTED
if PLATFORM_LINUX
-lib_LTLIBRARIES = libmono-profiler-cov.la libmono-profiler-aot.la libmono-profiler-logging.la
+lib_LTLIBRARIES = libmono-profiler-cov.la libmono-profiler-aot.la libmono-profiler-logging.la libmono-profiler-iomap.la
else
-lib_LTLIBRARIES = libmono-profiler-cov.la libmono-profiler-aot.la
+lib_LTLIBRARIES = libmono-profiler-cov.la libmono-profiler-aot.la libmono-profiler-iomap.la
endif
endif
endif
@@ -24,4 +24,5 @@ libmono_profiler_aot_la_SOURCES = mono-profiler-aot.c
libmono_profiler_aot_la_LIBADD = $(top_builddir)/mono/mini/libmono.la
libmono_profiler_logging_la_SOURCES = mono-profiler-logging.c
libmono_profiler_logging_la_LIBADD = $(top_builddir)/mono/mini/libmono.la
-
+libmono_profiler_iomap_la_SOURCES = mono-profiler-iomap.c
+libmono_profiler_iomap_la_LIBADD = $(top_builddir)/mono/mini/libmono.la
diff --git a/mono/profiler/mono-profiler-iomap.c b/mono/profiler/mono-profiler-iomap.c
new file mode 100644
index 000..ef129b0
--- /dev/null
+++ b/mono/profiler/mono-profiler-iomap.c
@@ -0,0 +1,532 @@
+/*
+ * mono-profiler-iomap.c: IOMAP string profiler for Mono.
+ *
+ * Authors:
+ * Marek Habersack mhabers...@novell.com
+ *
+ * Copyright (c) 2009 Novell, Inc (http://novell.com)
+ */
+#include config.h
+
+#include string.h
+#include mono/utils/mono-io-portability.h
+#include mono/metadata/metadata.h
+#include mono/metadata/metadata-internals.h
+#include mono/metadata/class.h
+#include mono/metadata/class-internals.h
+#include mono/metadata/image.h
+#include mono/metadata/mono-debug.h
+#include mono/metadata/debug-helpers.h
+#include mono/metadata/threads.h
+#include mono/metadata/profiler.h
+#include mono/metadata/loader.h
+#include mono/io-layer/mono-mutex.h
+
+#define BACKTRACE_SIZE 64
+
+typedef struct _MonoStackBacktraceInfo
+{
+ MonoMethod *method;
+ gint native_offset;
+} MonoStackBacktraceInfo;
+
+typedef struct
+{
+ guint32 count;
+ gchar *requestedName;
+ gchar *actualName;
+} MismatchedFilesStats;
+
+typedef struct _SavedString
+{
+ MonoString *string;
+ MonoDomain *domain;
+ void *stack [BACKTRACE_SIZE];
+ gint stack_entries;
+ struct _SavedString *next;
+} SavedString;
+
+typedef struct _SavedStringFindInfo
+{
+ guint32 hash;
+ size_t len;
+} SavedStringFindInfo;
+
+typedef struct _StringLocation
+{
+ gchar *hint;
+ struct _StringLocation *next;
+} StringLocation;
+
+struct _MonoProfiler
+{
+ GHashTable *mismatched_files_hash;
+ GHashTable *saved_strings_hash;
+ GHashTable *string_locations_hash;
+ gboolean may_have_locations;
+};
+
+typedef struct _StackWalkData
+{
+ MonoProfiler *prof;
+ void **stack;
+ int stack_size;
+ int frame_count;
+} StackWalkData;
+
+static mono_mutex_t mismatched_files_section;
+static gboolean runtime_initialized = FALSE;
+
+static inline void append_report (GString **report, const gchar *format, ...);
+static inline void print_report (const gchar *format, ...);
+static inline guint32 do_calc_string_hash (guint32 hash, const gchar *str);
+static inline guint32 calc_strings_hash (const gchar *str1, const gchar *str2, guint32 *str1hash);
+static void print_mismatched_stats (MonoProfiler *prof);
+static inline gchar *build_hint (SavedString *head);
+static inline gchar *build_hint_from_stack (MonoDomain *domain, void **stack, gint stack_entries);
+static inline void store_string_location (MonoProfiler *prof, const gchar *string, guint32 hash, size_t len);
+static
Re: [Mono-dev] [PATCH] MONO_IOMAP reporting option - string allocation locations
On 11/28/2009 07:12 AM, Miguel de Icaza wrote: Hello Marek, Hey Miguel, I think the idea is very useful, but I would like to see this implemented as a loadable profiler. We discussed that with Rodrigo and Zoltan, and while doing it is easy the conclusion was that at this time it's not practical because we don't support multiple profilers right now and it would conflict with, e.g., the soft debugger (it is possible to use the allocation profiling callback while another profiler is active, but since we support only one callback per category, it may override the original handler). Zoltan suggested that the code is committed as-is right now, and modified to use the profiler interface when we have multiple profiler support ready (the change to do that in my code would be really minimal). We could make an alias to load other modules like --module that would just be an alias to this feature if you think that the profiler association is too negative. I think it doesn't reflect the purpose of the code and, as Zoltan said, it is more a tooling interface than a profiling one. Also, what do you think about implementing the support in the similar fashion as the soft debugger - i.e. it wouldn't be a separate .so, but would live in the runtime, otherwise behaving like a shared module? That would let us keep the code together with the I/O portability layer. marek On Nov 26, 2009, at 7:08 PM, Marek Habersack wrote: Hello everybody, Attached is an update to the original code I posted last week. The update adds support for reporting string allocation locations. It is useful with large code base where strings may be created in one location but used in many others. The code adds a new internal function which does the job of backtrace (3) but supports mono JIT. It's basically a lighter version of mono_jit_walk_stack which was too heavy for this purpose. The code needs to record stack location for each and every string allocated in the application and the runtime only to store it for later use when IOMAP kicks in. Doing that with mono_stack_walk rendered Mono many times slower and made debugging the application virtually impossible. The patch makes execution just slightly slower than usual. The reporting code uses simple heuristics to select the possible string allocation location - it attempts to ignore all methods from assemblies installed in GAC, from corlib and, should the two checks fail, from a list of assemblies and classes to ignore. This is done based on the premise that the Mono runtime and class libraries are case-sensitive and don't have the problem some applications might have (there's actually an instance where that assumption is incorrect - in System.Web we check for existence of web.config, Web.config and Web.Config - but it's intended :)). The results of the selection algorithm might not always be accurate, but they should be close enough to aid the developer to spot the location where string was allocated. Please review and let me know if I can commit. marek iomap-report.diff___ 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] [PATCH] MONO_IOMAP reporting option - string allocation locations
On 11/27/2009 02:29 PM, Rodrigo Kumpera wrote: I agree with Zoltan, we better figure out how to extend the profilling interface to support such tool than it would defy the purpose of the tool, but it seems I can remove the code from mono_string_new_utf16 without harming functionality - would that be ok? marek to increase the complexity of the runtime. On Thu, Nov 26, 2009 at 10:22 PM, Zoltan Varga var...@gmail.com mailto:var...@gmail.com wrote: Hi, This patch adds code to the string allocation functions which need to be as fast as possible. I think it might be better to implement this as a profiler module, a profiler can already receive notifications when an object is allocated. Zoltan On Fri, Nov 27, 2009 at 1:08 AM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: Hello everybody, Attached is an update to the original code I posted last week. The update adds support for reporting string allocation locations. It is useful with large code base where strings may be created in one location but used in many others. The code adds a new internal function which does the job of backtrace (3) but supports mono JIT. It's basically a lighter version of mono_jit_walk_stack which was too heavy for this purpose. The code needs to record stack location for each and every string allocated in the application and the runtime only to store it for later use when IOMAP kicks in. Doing that with mono_stack_walk rendered Mono many times slower and made debugging the application virtually impossible. The patch makes execution just slightly slower than usual. The reporting code uses simple heuristics to select the possible string allocation location - it attempts to ignore all methods from assemblies installed in GAC, from corlib and, should the two checks fail, from a list of assemblies and classes to ignore. This is done based on the premise that the Mono runtime and class libraries are case-sensitive and don't have the problem some applications might have (there's actually an instance where that assumption is incorrect - in System.Web we check for existence of web.config, Web.config and Web.Config - but it's intended :)). The results of the selection algorithm might not always be accurate, but they should be close enough to aid the developer to spot the location where string was allocated. Please review and let me know if I can commit. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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 mailto: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] [PATCH] MONO_IOMAP reporting option - string allocation locations
On 11/27/2009 06:48 PM, Rodrigo Kumpera wrote:
On Fri, Nov 27, 2009 at 1:40 PM, Marek Habersack
gren...@twistedcode.net mailto:gren...@twistedcode.net wrote:
On 11/27/2009 02:29 PM, Rodrigo Kumpera wrote:
I agree with Zoltan, we better figure out how to extend the
profilling
interface to support such tool than
it would defy the purpose of the tool, but it seems I can remove the
code from mono_string_new_utf16 without harming functionality -
would that be ok?
Why using the profilling interface defy the purpose of the tool? I can't
see how passing an extra argument to the mono runtime be a problem.
The utility should be as seamless to use. With it consisting of two
parts - one in IO portability code and another as a profiler module
('profiler' being a misnomer here too, as the tool is by no means a
profiler) it would require setting both MONO_IOMAP and passing
--profile=iomap (or somesuch) to the runtime as they both are required
for the code to be useful. This can be a problem for MonoVS or
MonoDevelop, which would have to call the runtime with --profile for
every app whether or not it is necessary, and also it introduces a
complexity for users not familiar with Mono command line. To get rid of
the disparity, one would have to switch IOMAP on behind the scenes if
--profile=iomap was used and this is not a nice thing to do, imho. From
the other end, the user would have to know that they need to specify
'all:report' and pass --profile=iomap to the runtime - also not a nice
solution.
My main issue is about bloat, if we can make it work as an external tool
There's not much bloat really. The only thing that can be considered as
such is the addition to the mini_redirect_call function which checks if
IOMAP reporting is active. I agree it's not a nice thing to do at this
point, but it's not very costly in terms of execution time and code size
(especially if related to what mini_redirect_call does). I've just
removed the code from mono_string_new_utf16 without any harm to
functionality, so the only part that remains in the string allocation
functions is the one in InternalAllocateStr icall - which is NOT used by
default anyway (mini_redirect_call overrides it with emitted code for
managed string allocator) and so the code won't affect usual
performance. I really think the impact on the runtime is kept to minimum.
just fine, I don't see a reason to add it to the runtime.
As I mentioned, we can extend the profiling API to fit your needs.
The profiling API has all that's needed - but if the code was there, it
would have to hook up to the object allocation function and examine
every single object whether it's a string and then store the string - it
would cost more time it does with the current patch.
Find attached the new version of the patch.
marek
diff --git a/mono/metadata/class-internals.h b/mono/metadata/class-internals.h
index f18b9b1..4531e50 100644
--- a/mono/metadata/class-internals.h
+++ b/mono/metadata/class-internals.h
@@ -19,6 +19,7 @@ extern gboolean mono_print_vtable;
extern gboolean mono_setup_vtable_in_class_init;
typedef void (*MonoStackWalkImpl) (MonoStackWalk func, gboolean do_il_offset, gpointer user_data);
+typedef int (*MonoStackBacktraceImpl) (MonoDomain *domain, void **buffer, int size);
typedef struct _MonoMethodNormal MonoMethodNormal;
typedef struct _MonoMethodWrapper MonoMethodWrapper;
@@ -1085,6 +1086,9 @@ mono_method_get_wrapper_data (MonoMethod *method, guint32 id) MONO_INTERNAL;
void
mono_install_stack_walk (MonoStackWalkImpl func) MONO_INTERNAL;
+void
+mono_install_stack_backtrace (MonoStackBacktraceImpl func) MONO_INTERNAL;
+
gboolean
mono_metadata_has_generic_params (MonoImage *image, guint32 token) MONO_INTERNAL;
diff --git a/mono/metadata/loader.c b/mono/metadata/loader.c
index b599f21..931df55 100644
--- a/mono/metadata/loader.c
+++ b/mono/metadata/loader.c
@@ -1961,6 +1961,28 @@ mono_install_stack_walk (MonoStackWalkImpl func)
stack_walk = func;
}
+static int
+default_mono_stack_backtrace (MonoDomain *domain, void **buffer, int size)
+{
+ g_warning (stack backtrace not installed);
+ return 0;
+}
+
+static MonoStackBacktraceImpl stack_backtrace = default_mono_stack_backtrace;
+
+int
+mono_stack_backtrace (MonoDomain *domain, void **buffer, int size)
+{
+ return stack_backtrace (domain, buffer, size);
+}
+
+void
+mono_install_stack_backtrace (MonoStackBacktraceImpl func)
+{
+ if (func)
+ stack_backtrace = func;
+}
+
static gboolean
last_managed (MonoMethod *m, gint no, gint ilo, gboolean managed, gpointer data)
{
diff --git a/mono/metadata/loader.h b/mono/metadata/loader.h
index 517f8e0..464688b 100644
--- a/mono/metadata/loader.h
+++ b/mono/metadata/loader.h
@@ -3,6 +3,7 @@
#include mono/metadata/metadata.h
#include mono/metadata/image.h
+#include mono/utils/mono-compiler.h
G_BEGIN_DECLS
@@ -87,6 +88,9 @@ mono_stack_walk (MonoStackWalk func
[Mono-dev] [PATCH] MONO_IOMAP reporting option - string allocation locations
Hello everybody,
Attached is an update to the original code I posted last week. The
update adds support for reporting string allocation locations. It is
useful with large code base where strings may be created in one location
but used in many others. The code adds a new internal function which
does the job of backtrace (3) but supports mono JIT. It's basically a
lighter version of mono_jit_walk_stack which was too heavy for this
purpose. The code needs to record stack location for each and every
string allocated in the application and the runtime only to store it for
later use when IOMAP kicks in. Doing that with mono_stack_walk rendered
Mono many times slower and made debugging the application virtually
impossible. The patch makes execution just slightly slower than usual.
The reporting code uses simple heuristics to select the possible string
allocation location - it attempts to ignore all methods from assemblies
installed in GAC, from corlib and, should the two checks fail, from a
list of assemblies and classes to ignore. This is done based on the
premise that the Mono runtime and class libraries are case-sensitive and
don't have the problem some applications might have (there's actually an
instance where that assumption is incorrect - in System.Web we check for
existence of web.config, Web.config and Web.Config - but it's intended
:)). The results of the selection algorithm might not always be
accurate, but they should be close enough to aid the developer to spot
the location where string was allocated.
Please review and let me know if I can commit.
marek
diff --git a/mono/metadata/class-internals.h b/mono/metadata/class-internals.h
index f18b9b1..4531e50 100644
--- a/mono/metadata/class-internals.h
+++ b/mono/metadata/class-internals.h
@@ -19,6 +19,7 @@ extern gboolean mono_print_vtable;
extern gboolean mono_setup_vtable_in_class_init;
typedef void (*MonoStackWalkImpl) (MonoStackWalk func, gboolean do_il_offset, gpointer user_data);
+typedef int (*MonoStackBacktraceImpl) (MonoDomain *domain, void **buffer, int size);
typedef struct _MonoMethodNormal MonoMethodNormal;
typedef struct _MonoMethodWrapper MonoMethodWrapper;
@@ -1085,6 +1086,9 @@ mono_method_get_wrapper_data (MonoMethod *method, guint32 id) MONO_INTERNAL;
void
mono_install_stack_walk (MonoStackWalkImpl func) MONO_INTERNAL;
+void
+mono_install_stack_backtrace (MonoStackBacktraceImpl func) MONO_INTERNAL;
+
gboolean
mono_metadata_has_generic_params (MonoImage *image, guint32 token) MONO_INTERNAL;
diff --git a/mono/metadata/loader.c b/mono/metadata/loader.c
index 6293811..bcf0d1f 100644
--- a/mono/metadata/loader.c
+++ b/mono/metadata/loader.c
@@ -1969,6 +1969,28 @@ mono_install_stack_walk (MonoStackWalkImpl func)
stack_walk = func;
}
+static int
+default_mono_stack_backtrace (MonoDomain *domain, void **buffer, int size)
+{
+ g_warning (stack backtrace not installed);
+ return 0;
+}
+
+static MonoStackBacktraceImpl stack_backtrace = default_mono_stack_backtrace;
+
+int
+mono_stack_backtrace (MonoDomain *domain, void **buffer, int size)
+{
+ return stack_backtrace (domain, buffer, size);
+}
+
+void
+mono_install_stack_backtrace (MonoStackBacktraceImpl func)
+{
+ if (func)
+ stack_backtrace = func;
+}
+
static gboolean
last_managed (MonoMethod *m, gint no, gint ilo, gboolean managed, gpointer data)
{
diff --git a/mono/metadata/loader.h b/mono/metadata/loader.h
index 517f8e0..464688b 100644
--- a/mono/metadata/loader.h
+++ b/mono/metadata/loader.h
@@ -3,6 +3,7 @@
#include mono/metadata/metadata.h
#include mono/metadata/image.h
+#include mono/utils/mono-compiler.h
G_BEGIN_DECLS
@@ -87,6 +88,9 @@ mono_stack_walk (MonoStackWalk func, gpointer user_data);
void
mono_stack_walk_no_il (MonoStackWalk func, gpointer user_data);
+int
+mono_stack_backtrace (MonoDomain *domain, void **buffer, int size) MONO_INTERNAL;
+
G_END_DECLS
#endif
diff --git a/mono/metadata/object.c b/mono/metadata/object.c
index c2ecefa..06e3f0e 100644
--- a/mono/metadata/object.c
+++ b/mono/metadata/object.c
@@ -41,6 +41,7 @@
#include mono/utils/strenc.h
#include mono/utils/mono-counters.h
#include mono/utils/mono-error-internals.h
+#include mono/utils/mono-io-portability.h
#include cominterop.h
#ifdef HAVE_BOEHM_GC
@@ -4555,6 +4556,8 @@ mono_string_new_utf16 (MonoDomain *domain, const guint16 *text, gint32 len)
memcpy (mono_string_chars (s), text, len * 2);
+ if (IS_PORTABILITY_REPORT)
+ mono_portability_remember_string (s, domain);
return s;
}
diff --git a/mono/metadata/string-icalls.c b/mono/metadata/string-icalls.c
index 60675e3..974a9c8 100644
--- a/mono/metadata/string-icalls.c
+++ b/mono/metadata/string-icalls.c
@@ -22,6 +22,7 @@
#include mono/metadata/object.h
#include mono/metadata/exception.h
#include mono/metadata/debug-helpers.h
+#include mono/utils/mono-io-portability.h
/* Internal helper methods */
@@ -207,9 +208,17 @@ string_icall_is_in_array
Re: [Mono-dev] [PATCH] XSP: Virtual path support on FastCGI Backend (also resulting in MVC support)
Tiaan Geldenhuys wrote: Hello, This patch adds better support for mapping of ASP.NET virtual paths on the XSP FastCGI Backend (previously it primarily assumed mapping to physical files and directories on the file system). As a result, MVC now also seems to be working through FastCGI, which extensively uses URL remapping. The code includes a few workarounds for an issue I ran into with Mono’s HostingEnvironment.MapPath implementation (comments included), but that can be addressed separately (and the workarounds reworked later). For now, this patch does at least get things off the ground and it seems to work as expected. Committed in r146758 (trunk), r146759 (2.6 branch) and r146761 (2.4 branch) - thanks! best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] MONO_IOMAP reporting option
Hello everybody,
Attached is a new version of the patch - it adds a summary of mismatched file names, printed to
stdout on application exit. Please review,
marek
diff --git a/man/mono.1 b/man/mono.1
index 5061f46..7d5e2ef 100644
--- a/man/mono.1
+++ b/man/mono.1
@@ -1282,7 +1282,10 @@ applications that hard-code Windows paths. Set to a colon-separated
list of drive to strip drive letters, or case to do
case-insensitive file matching in every directory in a path. all
enables all rewriting methods. (Backslashes are always mapped to
-slashes if this variable is set to a valid option.)
+slashes if this variable is set to a valid option). Additional option report can
+be set (it is not included in all) to make mapping code print the names of
+files in case a mismatch is found, together with a stack trace showing which managed method
+the misnamed file has been requested from.
.fi
.Sp
For example, this would work from the shell:
diff --git a/mono/utils/mono-io-portability.c b/mono/utils/mono-io-portability.c
index a1aa6a8..3c46a20 100644
--- a/mono/utils/mono-io-portability.c
+++ b/mono/utils/mono-io-portability.c
@@ -6,6 +6,12 @@
#endif
#include errno.h
#include mono/utils/mono-io-portability.h
+#include mono/metadata/metadata.h
+#include mono/metadata/class.h
+#include mono/metadata/class-internals.h
+#include mono/metadata/object.h
+#include mono/utils/mono-hash.h
+#include mono/metadata/gc-internal.h
#ifdef DISABLE_PORTABILITY
int __mono_io_portability_helpers = PORTABILITY_NONE;
@@ -24,10 +30,63 @@ mono_portability_find_file (const gchar *pathname, gboolean last_exists)
#else
+typedef struct
+{
+ guint32 count;
+ gchar *requestedName;
+ gchar *actualName;
+} MismatchedFilesStats;
+
+static CRITICAL_SECTION mismatched_files_section;
+static MonoGHashTable *mismatched_files_hash = NULL;
+
+static inline gchar *mono_portability_find_file_internal (GString **report, gboolean *differs, const gchar *pathname, gboolean last_exists);
+static inline void append_report (GString **report, const gchar *format, ...);
+static inline void print_report (const gchar *report);
+static inline guint32 calc_strings_hash (const gchar *str1, const gchar *str2);
+static void print_mismatched_stats_at_exit (void);
+
#include dirent.h
int __mono_io_portability_helpers = PORTABILITY_UNKNOWN;
+static void mismatched_stats_foreach_func (gpointer key, gpointer value, gpointer user_data)
+{
+ MismatchedFilesStats *stats = (MismatchedFilesStats*)value;
+
+ fprintf (stdout,
+ Count: %u\n
+ Requested: %s\n
+ Actual: %s\n\n,
+ stats-count, stats-requestedName, stats-actualName);
+}
+
+static void print_mismatched_stats_at_exit (void)
+{
+ if (!mismatched_files_hash || mono_g_hash_table_size (mismatched_files_hash) == 0)
+ return;
+
+ fprintf (stdout, \n-=-=-=-=-=-=-= MONO_IOMAP Stats -=-=-=-=-=-=-=\n);
+ mono_g_hash_table_foreach (mismatched_files_hash, mismatched_stats_foreach_func, NULL);
+ fflush (stdout);
+}
+
+static guint mismatched_files_guint32_hash (gconstpointer key)
+{
+ if (!key)
+ return 0;
+
+ return *((guint32*)key);
+}
+
+static gboolean mismatched_files_guint32_equal (gconstpointer key1, gconstpointer key2)
+{
+ if (!key1 || !key2)
+ return FALSE;
+
+ return (gboolean)(*((guint32*)key1) == *((guint32*)key2));
+}
+
void mono_portability_helpers_init (void)
{
const gchar *env;
@@ -36,7 +95,7 @@ void mono_portability_helpers_init (void)
return;
__mono_io_portability_helpers = PORTABILITY_NONE;
-
+
env = g_getenv (MONO_IOMAP);
if (env != NULL) {
/* parse the environment setting and set up some vars
@@ -60,11 +119,19 @@ void mono_portability_helpers_init (void)
} else if (!strncasecmp (options[i], case, 4)) {
__mono_io_portability_helpers |= PORTABILITY_CASE;
} else if (!strncasecmp (options[i], all, 3)) {
-__mono_io_portability_helpers |= (PORTABILITY_DRIVE |
- PORTABILITY_CASE);
-}
+__mono_io_portability_helpers |= (PORTABILITY_DRIVE | PORTABILITY_CASE);
+ } else if (!strncasecmp (options[i], report, 7)) {
+__mono_io_portability_helpers |= PORTABILITY_REPORT;
+ }
}
-}
+ }
+
+ if (IS_PORTABILITY_REPORT) {
+ InitializeCriticalSection (mismatched_files_section);
+ MONO_GC_REGISTER_ROOT (mismatched_files_hash);
+ mismatched_files_hash = mono_g_hash_table_new (mismatched_files_guint32_hash, mismatched_files_guint32_equal);
+ g_atexit (print_mismatched_stats_at_exit);
+ }
}
/* Returns newly allocated string, or NULL on failure */
@@ -104,18 +171,91 @@ static gchar *find_in_dir (DIR *current, const gchar *name)
return(NULL);
}
-/* Returns newly-allocated string or NULL on failure */
+static inline guint32 do_calc_string_hash (guint32 hash, const gchar *str)
+{
+ guint32 ret = hash;
+ gchar
[Mono-dev] [PATCH] MONO_IOMAP reporting option
Hey folks,
The attached patch implements a new option for the MONO_IOMAP mechanism - report. The option
tells the mapping code to print information to stdout each time a mismatch is found. The information
includes requested file name, actual file name and a managed stack trace. The patch makes it easier
to port applications which are full of code accessing files with incorrect case in names. Is it ok
to commit the diff?
marek
diff --git a/man/mono.1 b/man/mono.1
index 5061f46..7d5e2ef 100644
--- a/man/mono.1
+++ b/man/mono.1
@@ -1282,7 +1282,10 @@ applications that hard-code Windows paths. Set to a colon-separated
list of drive to strip drive letters, or case to do
case-insensitive file matching in every directory in a path. all
enables all rewriting methods. (Backslashes are always mapped to
-slashes if this variable is set to a valid option.)
+slashes if this variable is set to a valid option). Additional option report can
+be set (it is not included in all) to make mapping code print the names of
+files in case a mismatch is found, together with a stack trace showing which managed method
+the misnamed file has been requested from.
.fi
.Sp
For example, this would work from the shell:
diff --git a/mono/utils/mono-io-portability.c b/mono/utils/mono-io-portability.c
index a1aa6a8..bc5483e 100644
--- a/mono/utils/mono-io-portability.c
+++ b/mono/utils/mono-io-portability.c
@@ -6,6 +6,10 @@
#endif
#include errno.h
#include mono/utils/mono-io-portability.h
+#include mono/metadata/metadata.h
+#include mono/metadata/class.h
+#include mono/metadata/class-internals.h
+#include mono/metadata/object.h
#ifdef DISABLE_PORTABILITY
int __mono_io_portability_helpers = PORTABILITY_NONE;
@@ -24,6 +28,9 @@ mono_portability_find_file (const gchar *pathname, gboolean last_exists)
#else
+static inline gchar *mono_portability_find_file_internal (GString **report, gboolean *differs, const gchar *pathname, gboolean last_exists);
+static inline void append_report (GString **report, const gchar *format, ...);
+
#include dirent.h
int __mono_io_portability_helpers = PORTABILITY_UNKNOWN;
@@ -60,9 +67,10 @@ void mono_portability_helpers_init (void)
} else if (!strncasecmp (options[i], case, 4)) {
__mono_io_portability_helpers |= PORTABILITY_CASE;
} else if (!strncasecmp (options[i], all, 3)) {
-__mono_io_portability_helpers |= (PORTABILITY_DRIVE |
- PORTABILITY_CASE);
-}
+__mono_io_portability_helpers |= (PORTABILITY_DRIVE | PORTABILITY_CASE);
+ } else if (!strncasecmp (options[i], report, 7)) {
+__mono_io_portability_helpers |= PORTABILITY_REPORT;
+ }
}
}
}
@@ -104,18 +112,67 @@ static gchar *find_in_dir (DIR *current, const gchar *name)
return(NULL);
}
-/* Returns newly-allocated string or NULL on failure */
+static inline void print_report (const gchar *report)
+{
+ MonoClass *klass;
+ MonoProperty *prop;
+ MonoString *str;
+ char *stack_trace;
+
+ fprintf (stdout, -=-=-=-=-=-=- MONO_IOMAP REPORT -=-=-=-=-=-=-\n%s\n, report);
+ klass = mono_class_from_name (mono_defaults.corlib, System, Environment);
+ mono_class_init (klass);
+ prop = mono_class_get_property_from_name (klass, StackTrace);
+ str = (MonoString*)mono_property_get_value (prop, NULL, NULL, NULL);
+ stack_trace = mono_string_to_utf8 (str);
+
+ fprintf (stdout, -= Stack Trace =-\n%s\n\n, stack_trace);
+ fflush (stdout);
+}
+
+static inline void append_report (GString **report, const gchar *format, ...)
+{
+ va_list ap;
+ if (!*report)
+ *report = g_string_new ();
+
+ va_start (ap, format);
+ g_string_append_vprintf (*report, format, ap);
+ va_end (ap);
+}
+
gchar *mono_portability_find_file (const gchar *pathname, gboolean last_exists)
{
+ GString *report = NULL;
+ gboolean differs = FALSE;
+ gchar *ret = mono_portability_find_file_internal (report, differs, pathname, last_exists);
+ if (report) {
+ if (report-len differs) {
+ char *rep = g_string_free (report, FALSE);
+ print_report (rep);
+ g_free (rep);
+ } else
+ g_string_free (report, TRUE);
+ }
+
+ return ret;
+}
+
+/* Returns newly-allocated string or NULL on failure */
+static inline gchar *mono_portability_find_file_internal (GString **report, gboolean *differs, const gchar *pathname, gboolean last_exists)
+{
gchar *new_pathname, **components, **new_components;
int num_components = 0, component = 0;
DIR *scanning = NULL;
size_t len;
+ gboolean do_report = IS_PORTABILITY_REPORT;
if (IS_PORTABILITY_NONE) {
return(NULL);
}
+ if (do_report)
+ append_report (report, - Requested file path: '%s'\n, pathname);
new_pathname = g_strdup (pathname);
#ifdef DEBUG
@@ -146,7 +203,9 @@ gchar *mono_portability_find_file (const gchar *pathname, gboolean last_exists)
g_memmove (new_pathname, new_pathname+2, len - 2);
Re: [Mono-dev] [PATCH] XSP: Unhandled exceptions on FastCGI Backend
Tiaan wrote: This patch prevents abandoned FastCGI connections from staying open indefinitely due to unhandled exceptions by adding last-resort error-handling (including logging) when connections are being accepted and processed. It also implements a more graceful shutdown of the FastCGI Backend by handling two ObjectDisposedException errors that can occur at process termination time. Committed in r146575 (trunk), r146576 (2.6 branch) and r146577 (2.4 branch), thanks! marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] MONO_IOMAP reporting option
Robert Jordan wrote:
Hi Marek,
Hey Robert,
[snip]
trace. The patch makes it easier to port applications which are full of
code accessing files with incorrect case in names. Is it ok to commit
the diff?
+static inline void print_report (const gchar *report)
+{
+MonoClass *klass;
+MonoProperty *prop;
+MonoString *str;
+char *stack_trace;
+
+fprintf (stdout, -=-=-=-=-=-=- MONO_IOMAP REPORT -=-=-=-=-=-=-\n%s\n,
report);
+klass = mono_class_from_name (mono_defaults.corlib, System,
Environment);
+mono_class_init (klass);
+prop = mono_class_get_property_from_name (klass, StackTrace);
+str = (MonoString*)mono_property_get_value (prop, NULL, NULL, NULL);
+stack_trace = mono_string_to_utf8 (str);
stack_trace must be g_free()d.
Good catch, missed that one - thanks :)
marek
+
+fprintf (stdout, -= Stack Trace =-\n%s\n\n, stack_trace);
+fflush (stdout);
+}
Robert
___
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] [PATCH] XSP: Encoding of long string-lengths in FastCGI does not comply with specification
Tiaan wrote: The lengths of strings that are larger than 127 bytes are encoded incorrectly by the Mono.FastCgi.NameValuePair.WriteLength method: The first byte must have its high bit set in this case. To confirm, refer to the implementation of the reverse decoding-logic in the ReadLength method and see the FastCGI specification (section 3.4 on Name-Value Pairs): “The high-order bit of the first byte of a length indicates the length's encoding. A high-order zero implies a one-byte encoding, a one a four-byte encoding.” The attached patch fixes this bug on the trunk. Would someone please check and commit it? Committed to trunk (r146328), 2.6 (r146329) and 2.4 (r146330), thanks a lot! marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Deadlock in System.Web.Caching.Cache class
Ivan Radovanovic wrote: Although this dead lock problem continues to potentially exists it seems that problem is after all OS specific - there is some weird behavior of fam/gamin reporting that bin/*.dll files are changed, causing ASP.Net runtime trying to restart application, while at the same time trying to compile *.aspx, *.ascx etc. The issue might be in FAM FileSystemWatcher backend then. Maybe deadlock can occur in normal conditions too (servicing some request that would need compiling of some control/page that is not compiled yet and replacing something in bin directory at the same time), but that should be rare enough :-) The BuildManager in 2.4 has some bugs indeed, which in certain cases can lead to deadlocks (it's, among others, related to recursive dependencies between application files). For that reason I rewrote BuildManager for 2.6+ - if the problem you're seeing turns out to be an issue with more than few environments, I can just copy the new code to 2.4 branch for a future release. If you can come up with a test case that triggers the issue on your system, then please file a bug report and attach the testcase including OS/environment details. marek Regards Ivan Radovanovic napisa: Hello, I am experiencing weird deadlock in .net applications running latest release version of mono (2.4.2.3) on FreeBSD (I don't think it is OS specific, and it doesn't show all the times, but still often enough so I can trace it) Stack from thread 1: at System.Web.Compilation.BuildManager.RemoveVirtualPathFromCaches(System.Web.VirtualPath virtualPath) at System.Web.Compilation.BuildManager.OnVirtualPathChanged(System.String key, System.Object value, CacheItemRemovedReason removedReason) at System.Web.Caching.Cache.InvokePrivateCallbacks() at System.Web.HttpRuntime.ShutdownAppDomain(System.Object args) Stack from thread 2: at System.Web.Caching.Cache.Add(System.String key, System.Object value, System.Web.Caching.CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, System.Web.Caching.CacheItemRemovedCallback onRemoveCallback) at System.Web.Compilation.BuildManager.AddToCache(System.String virtualPath, System.Web.Compilation.BuildProvider bp) at System.Web.Compilation.BuildManager.GenerateAssembly(System.Web.Compilation.AssemblyBuilder abuilder, System.Collections.Generic.List`1 buildItems, System.Web.VirtualPath virtualPath, BuildKind buildKind) at System.Web.Compilation.BuildManager.BuildAssembly(System.Web.VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetCompiledType(System.String virtualPath) at System.Web.Compilation.AspComponentFoundry+TagNameFoundry.LoadType() at System.Web.Compilation.AspComponentFoundry+TagNameFoundry.GetType(System.String componentName, System.String ByRef source, System.String ByRef ns) at System.Web.Compilation.AspComponentFoundry.CreateComponent(System.Web.Compilation.Foundry foundry, System.String tagName, System.String prefix, System.String tag) at System.Web.Compilation.AspComponentFoundry.GetComponent(System.String tagName) at System.Web.UI.RootBuilder.GetChildControlType(System.String tagName, IDictionary attribs) at System.Web.UI.ControlBuilder.CreateSubBuilder(System.String tagid, System.Collections.Hashtable atts, System.Type childType, System.Web.UI.TemplateParser parser, ILocation location) at System.Web.Compilation.AspGenerator.ProcessTag(ILocation location, System.String tagid, System.Web.Compilation.TagAttributes atts, TagType tagtype, Boolean ByRef ignored) at System.Web.Compilation.AspGenerator.TagParsed(ILocation location, TagType tagtype, System.String tagid, System.Web.Compilation.TagAttributes attributes) at System.Web.Compilation.AspParser.OnTagParsed(TagType tagtype, System.String id, System.Web.Compilation.TagAttributes attributes) at System.Web.Compilation.AspParser.Parse() at System.Web.Compilation.AspGenerator.Parse(System.IO.TextReader reader, System.String filename, Boolean doInitParser) at System.Web.Compilation.GenericBuildProvider`1.Parse() at System.Web.Compilation.GenericBuildProvider`1.get_CodeCompilerType() at System.Web.Compilation.BuildManager.GetCodeDomProviderType(System.Web.Compilation.BuildProvider provider) at System.Web.Compilation.BuildManager+BuildItem..ctor(System.Web.Compilation.BuildProvider provider) at System.Web.Compilation.BuildManager.LoadBuildProviders(System.Web.VirtualPath virtualPath, System.String virtualDir, System.Collections.Generic.Dictionary`2 vpCache, BuildKind ByRef kind, System.String ByRef assemblyBaseName) at System.Web.Compilation.BuildManager.BuildAssembly(System.Web.VirtualPath virtualPath) at
Re: [Mono-dev] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Kornél Pál wrote: Miguel de Icaza wrote: I am not sure why we would include in Mono two classes that are flagged as internal. How would a user even use this? Handlers are mostly used in Web.config and the ASP.NET runtime uses reflection that makes it able to instantiate non-public types. This way users may not even realize that they are using internal types. True, but this is not the case for the two types you implemented. On the other hand if you want to hide or deny requests you can use just like HttpForbiddenHandler but you can have additional HTTP status codes and messages. Of course you could duplicate this functionality in your own classes but it's easier to use existing framework classes. That's what we do now. I just realized that Microsoft documented HttpForbiddenHandler that is internal as well and is implemented in Mono: http://msdn.microsoft.com/en-us/library/ms404282.aspx Originally HttpForbiddenHandler was exposed only in Web.config. HttpNotFoundHandler existed in 1.x but was not exposed in Web.config until 2.0. Ah, indeed, just looked at .NET 3.5 config and it's there. I'm ok with putting in System.Web in that case (modify the global web.config as well, to reference the type in the same fashion as .NET) So people most likely know that these types exist and the might use them. I actually wanted to use it when I found out that we haven't had it. That, in itself, is not a good argument - most Windows developers who work with .NET probably use Reflector to dig into .NET internals, so they are aware of many internal types/fields/methods - we won't implement features based on that knowledge, at least I don't think it's a good idea. HttpNotImplementedHandler is not used in Web.config and is most likely known by much less people but I found it in the prevously referenced book so I just implemented that as well to make the internal simple handler collection complete. I don't think we should include it just for the sake of it. If you want it in, that's fine, but you need to modify all the spots in System.Web code which throw 404 and make sure there are no regressions in exception/error handling because of that. Only then the type can be included. marek Kornél ___ 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] [PATCH] Add HttpNotFoundHandler and HttpNotImplementedHandler
Kornél Pál wrote: Marek Habersack wrote: HttpNotImplementedHandler is not used in Web.config and is most likely known by much less people but I found it in the prevously referenced book so I just implemented that as well to make the internal simple handler collection complete. I don't think we should include it just for the sake of it. If you want it in, that's fine, but you need to modify all the spots in System.Web code which throw 404 and make sure there are no regressions in exception/error handling because of that. Only then the type can be included. These handlers need no special treatment. ASP.NET runtime should be and according to my experiences is able to receive HttpExceptions with status codes from handlers/user code. Yes, it is able to do that, but that's not my point. I don't want practically unused internal code in System.Web for the sake of matching .NET internals. If you want an internal type like this in System.Web, please make some use of it. Only 403 and 404 codes are treated specially, that means a more destrictive error page, but that should not make any distinction based on the origin of the exception, just the status code. That's the theory, yes - I'd like to be sure in practice that there are no regressions from introducing a new type for 404. No maintenance requirements come with these two handlers. They just should be treated just like any other external handler. Their sole purpose is to throw HttpExceptions with the respective status code. Once again, that's fine - but if we include them, I want them to be used and not just sit there. Code which isn't used is likely to erode with time (even if it's as simple as the code you posted) and we want to avoid that. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Nick Berardi wrote: Hi guys, Hey Nick, I looked in to this more and there are a couple issues that popped up when trying to implement the following method: public void TransferRequest(string path, bool preserveForm, string method, NameValueCollection headers) My major hurdle that I wasn't able to over come is the following, probably because I don't know how the actual server was implemented. /TransferRequest is suppose to kick off a new request in the application life cycle, which means that it needs to create a new request which runs all the way through from BeginRequest to EndRequest in the HttpApplication, after it has killed off the current request. / I don't know how I can do this in the Mono code base, because everytime I called Response.End() the request was transmitted back to the client. Which is by design of Response.End(), however I need a way to end the current request life cycle and start a new one giving the path, headers, method, and content body, and not have it transmit back to the client until this second request is done. You can try one of two things: 1. Easier (and imho, enough to emulate IIS7 behavior) - just redirect the request 2. If you want to play with it more, you can emulate a new request by first acquiring a new HttpApplication instance for the current application (see HttpRuntime.Process for info on how to do that), then start asynchronous request on the instance (again, look in Process as above) and after it is started, end the current request. best regards, marek Can either of you guys give me a clue on how to get this implemented, or any code to look at that does something similar? I am trying to get this in the next code release of mono for my users, so if you could help me out that would be great. Nick On Fri, Sep 25, 2009 at 5:32 AM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: Chuck Esterbrook wrote: On Thu, Sep 24, 2009 at 1:20 PM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: Nick Berardi wrote: But by leaving out these stub API's the Mono project is essentially forbidding any application that references these API's from running on their software, even if the application fully supports .NET 2.0 pre and post SP2. (which is when they were introduced) At the very least these API's should be marked with MonoTODOAttribute and committed so that applications that want to work around API's not currently implemented in Mono can do so. Frankly, I don't understand your resistance to implementing the transfer API - what are the technical reasons for not doing it? From MSDN docs it seems it should be pretty simple to implement, why not just do it (I can't do it right now as I'm busy with other things atm) and commit the full support? Marek, if you can't do it now because you're busy with other things, then it's easy to imagine that Nick can't do it now because he's also busy. Also, Nick probably has less knowledge about ASP.NET http://ASP.NET internals which raises the cost of implementation for him. This is the obstacle all of us contributing to Mono encountered at some point. I think Nick and I came to a conclusion regarding the issue. If Nick doesn't have time to implement them, I will - but not right away and not now. This is an opensource project, created and developed by community - usually people submit patches in areas they are interested in, and that works best - as everybody will do their best to implement code as good as they can, because they themselves are going to use it and they themselves know the context in which they are using it. I would think a simple patch that avoids MissingMethodExceptions would be a good thing and easy to accept. On surface, yes, in reality - no. We really try to avoid stubbed methods committed for the sake of having them but with no functionality. It is very likely that after comitting, the stubs will remain unimplemented for unknown time, thus providing a false ilussion that Mono supports this or that API, which will cause (for instance) MOMA reports to show false positives etc. etc. NOT accepting stubs has also the effect that people (including ourselves in the team) are motivated to actually implement the code, IMHO. best regards, marek -Chuck ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing
Re: [Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Chuck Esterbrook wrote: On Thu, Sep 24, 2009 at 1:20 PM, Marek Habersack gren...@twistedcode.net wrote: Nick Berardi wrote: But by leaving out these stub API's the Mono project is essentially forbidding any application that references these API's from running on their software, even if the application fully supports .NET 2.0 pre and post SP2. (which is when they were introduced) At the very least these API's should be marked with MonoTODOAttribute and committed so that applications that want to work around API's not currently implemented in Mono can do so. Frankly, I don't understand your resistance to implementing the transfer API - what are the technical reasons for not doing it? From MSDN docs it seems it should be pretty simple to implement, why not just do it (I can't do it right now as I'm busy with other things atm) and commit the full support? Marek, if you can't do it now because you're busy with other things, then it's easy to imagine that Nick can't do it now because he's also busy. Also, Nick probably has less knowledge about ASP.NET internals which raises the cost of implementation for him. This is the obstacle all of us contributing to Mono encountered at some point. I think Nick and I came to a conclusion regarding the issue. If Nick doesn't have time to implement them, I will - but not right away and not now. This is an opensource project, created and developed by community - usually people submit patches in areas they are interested in, and that works best - as everybody will do their best to implement code as good as they can, because they themselves are going to use it and they themselves know the context in which they are using it. I would think a simple patch that avoids MissingMethodExceptions would be a good thing and easy to accept. On surface, yes, in reality - no. We really try to avoid stubbed methods committed for the sake of having them but with no functionality. It is very likely that after comitting, the stubs will remain unimplemented for unknown time, thus providing a false ilussion that Mono supports this or that API, which will cause (for instance) MOMA reports to show false positives etc. etc. NOT accepting stubs has also the effect that people (including ourselves in the team) are motivated to actually implement the code, IMHO. best regards, marek -Chuck ___ 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] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Nick Berardi wrote:
Hello group,
Hello,
This is my first time submitting a patch. So if anything I have done is
out of the norm, please let me know so that I can correct it.
There are two API's related to IIS 7.0 that were added as part of the
.NET 2.0 SP2 release that I need supported for an Open Source project
that I work on (http://urlrewriter.codeplex.com).
(http://urlrewriter.codeplex.com/WorkItem/View.aspx?WorkItemId=7187)
The patch that I am submitting is for the following APIs:
* HttpRuntime.UsingIntegratedPipeline { get; }
*
HttpServerUtility.TransferRequest(string,[bool],[string],[NameValueCollection])
Since both of these API's are IIS 7.0+ specific and that they require
the Integrated Pipeline to function. I have the first property
UsingIntegratedPipeline always returning false, since it is currently
impossible to put Mono in to the core of IIS 7.0, so Integrated Pipeline
Technically Mono has always been using what IIS 7 calls integrated pipeline -
there are no plans
to make Mono run in the IIS core, so we should try to implement whatever
functionality makes sense
in Mono context without looking whether or not it works in this or that IIS
mode. I'd say
UsingIntegratedPipeline could return 'true' without harm.
can't currently be supported. So I hoped to achieve the 2nd best option
of API completeness. The second method TransferRequest relies on the
Integrated Pipeline so again it will not be supported. So I have the
method just throwing the publically available exceptions shows on MSDN.
This second method will always throw PlatformNotSupported, for API
completeness with the .NET 2.0 SP2 framework.
This method, as well, can be implemented to perform its function on Mono just
fine. If you feel like
giving it a try, I'd welcome a new patch which implements it. If not, I will
accept the patch as it
is now and implement the API fully at some point.
Please let me know what the next steps are or if there is anything that
I need to change in order to get this patch moved into production.
Thanks,
Nick
best regards,
marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Nick Berardi wrote:
Hi Marek,
Hello,
I am a little hesitant to to implement this for Mono for the following
reasons.
/Number 1/ is the description Microsoft provides for it
Gets a value that indicates whether the current application is running
*in the integrated-pipeline mode of IIS 7.0*.
You can ignore this particular part of the description. As I wrote in the
previous mail, Mono
effectively implements what was introduced in IIS 7 and termed
integrated-pipeline mode. Therefore
it's perfectly fine to implement that in Mono.
/Number 2/ is that the key feature of the integrated-pipeline is that
outside processes still run through the .NET framework first, such as,
you can use IHttpModules to process request/response data from for
example PHP code, I don't know enough about Mono/XPS to get something
like this working.
XSP doesn't implement that and it doesn't have to, it's just a development
server. Apache, otoh,
provides a full filter/pipelining infrastructure with which Mono should work
just fine (i.e. you can
define a module to act as a filter and pass its output to another module, etc
etc) - I have never
tried it, but I mod_mono is no different to other modules and it should work
just fine. It will NOT
use IHttpModules, of course, because Apache (being IIS counterpart) doesn't
have that notion, but
functionality is exactly the same. We might (just might) approach it at some
point and extend
mod_mono (or create an auxiliary module) in the way which will expose
IHttpModules etc to Apache,
but it's definitely not a priority. Mono/mod_mono/XSP is much more flexible
than .NET + IIS combo,
so the elements are more losely coupled but they can be arranged to work in the
same way as IIS.
Many developers use the UsingIntegratedPipeline flag to indicate if they
are running in IIS 7.0 integrated mode or the older classic mode. I
really feel that getting both the classic mode and integrated mode
working under Mono would be a huge undertaking, especially in regards to
some of the built in support for their Rewriter Module that they have
We don't have to aim for 1:1 compatibility in this regard - Apache has rewriter
modules which can
easily replace their IIS counterpart, and we do not aim to make Mono a
replacement for .NET under
IIS. Therefore, if a developer deploys an ASP.NET application to
Mono/Apache/mod_mono they should be
aware of architectural differences. But, again, that doesn't stop us from
supporting the APIs (and
other integrated pipeline ones) for the benefit of applications and
developers.
added in to the .NET 2.0 SP2 framework. Also because a number of
sub-routines change in ASP.NET http://ASP.NET depending on this one
flag.
Nothing prevents us from defaulting to false for UsingIntegratedPipeline and
providing a mechanism
to turn it on (by e.g. providing a MonoServerEnableIntegratedPipeline
AppSettings entry - we already
have a number of them, documented in the xsp and mod_mono manpages)
I would like to commit the patch as is for now, to complete some of the
missing parts of the API, and I will look in to what it will take to
really get this supported in the Mono framework.
What the patch generally does is provide stub implementations of the API (with,
perhaps, the
exception of the property) which we don't generally like to do, especially if
the functionality is
relatively easy to implement as in this case. I'd rather vote on not commiting
the patch in this
state, but rather wait till you (or somebody else, perhaps even me) provides
full support for the
APIs together with tests etc.
best regards,
marek
Thanks,
Nick
P.S. I know of a dozen places where having integrated mode turned on
will allow you to do things that you weren't allowed to before. For
example when integrated mode is enabled you can directly add headers
using /HttpRequest.Headers.Add/, instead of getting an exception thrown.
You can do it just fine with Mono as well. As said before, we treat Mono as
working in the
integrated pipeline mode. There's nothing wrong in not having full support for
all of its features
right away, we can implement it step by step.
On Thu, Sep 24, 2009 at 4:56 AM, Marek Habersack
gren...@twistedcode.net mailto:gren...@twistedcode.net wrote:
Nick Berardi wrote:
Hello group,
Hello,
This is my first time submitting a patch. So if anything I have
done is out of the norm, please let me know so that I can
correct it.
There are two API's related to IIS 7.0 that were added as part
of the .NET 2.0 SP2 release that I need supported for an Open
Source project that I work on (http://urlrewriter.codeplex.com).
(http://urlrewriter.codeplex.com/WorkItem/View.aspx?WorkItemId=7187)
The patch that I am submitting is for the following APIs:
* HttpRuntime.UsingIntegratedPipeline { get
Re: [Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Nick Berardi wrote: Hi Marek, Hey Nick, It is ultimately up to the team to apply or not apply the patch. So I support whatever they choose is best for the Mono project. Well... I'm part of the team... and in charge of ASP.NET... :) However I see no reason to wait to add these stub method in place. Because currently any application that relies on either of these API's, get ugly exceptions like this: Stack Trace: System.MissingMethodException: Method not found: 'System.Web.HttpServerUtility.Trans ferRequest'. at System.Web.HttpApplication+c__CompilerGenerated1.MoveNext () [0x0] at System.Web.HttpApplication+c__CompilerGenerated2.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] So there is not even a way to gracefully handle the exception from with in the application. I realize that, but I would really prefer to accept a patch which does implement the API correctly. And there are many ASP.NET http://ASP.NET applications, mine is one of them, out there now that check to see if they are running on the Integrated Pipeline or not. And handle things differently based on this flag. Your report is actually the first one we got regarding the issue, so I'm not sure if it's that common (at least among apps running on Mono) But by leaving out these stub API's the Mono project is essentially forbidding any application that references these API's from running on their software, even if the application fully supports .NET 2.0 pre and post SP2. (which is when they were introduced) At the very least these API's should be marked with MonoTODOAttribute and committed so that applications that want to work around API's not currently implemented in Mono can do so. Frankly, I don't understand your resistance to implementing the transfer API - what are the technical reasons for not doing it? From MSDN docs it seems it should be pretty simple to implement, why not just do it (I can't do it right now as I'm busy with other things atm) and commit the full support? All that I am really asking for is a graceful way to handle support for Mono with in my application. Currently I can't even support Mono because I get a ton of runtime errors about Missing Methods. At least if the stubs where in place, I could work around them, but setting a flag in the Web.config or searching for something Mono specific in the runtime. I understand the issue, but it's not very hard to patch your copy of Mono, recompile and copy just the System.Web.dll assembly to your server. Alternatively you can just introduce an #if in your code to skip that part when compiling for Mono. Adding stubbed APIs just before 2.6 is to be branched is not acceptable IMO and should be the very last resort. best regards, marek Nick On Thu, Sep 24, 2009 at 2:32 PM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: Nick Berardi wrote: Hi Marek, Hello, I am a little hesitant to to implement this for Mono for the following reasons. /Number 1/ is the description Microsoft provides for it Gets a value that indicates whether the current application is running *in the integrated-pipeline mode of IIS 7.0*. You can ignore this particular part of the description. As I wrote in the previous mail, Mono effectively implements what was introduced in IIS 7 and termed integrated-pipeline mode. Therefore it's perfectly fine to implement that in Mono. /Number 2/ is that the key feature of the integrated-pipeline is that outside processes still run through the .NET framework first, such as, you can use IHttpModules to process request/response data from for example PHP code, I don't know enough about Mono/XPS to get something like this working. XSP doesn't implement that and it doesn't have to, it's just a development server. Apache, otoh, provides a full filter/pipelining infrastructure with which Mono should work just fine (i.e. you can define a module to act as a filter and pass its output to another module, etc etc) - I have never tried it, but I mod_mono is no different to other modules and it should work just fine. It will NOT use IHttpModules, of course, because Apache (being IIS counterpart) doesn't have that notion, but functionality is exactly the same. We might (just might) approach it at some point and extend mod_mono (or create an auxiliary module) in the way which will expose IHttpModules etc to Apache, but it's definitely not a priority. Mono/mod_mono/XSP is much more flexible than .NET + IIS combo, so the elements are more losely coupled but they can be arranged to work in the same way as IIS. Many developers use the UsingIntegratedPipeline flag to indicate if they are running in IIS 7.0 integrated mode
Re: [Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
Nick Berardi wrote:
Hi Marek,
Hey Nick,
I guess the misunderstanding is coming in the word trivial. If it
was truly trivial I would just do it. But what may seem trivial to you,
All I said was that it shouldn't be hard to do, not that it was trivial.
seems like climbing a mountain to me. In ASP.NET http://ASP.NET from
Microsoft there is a lot native invoke calls that are made to get the
transfer request working with the underlying server. And I don't know
what these are for XPS and mod_mono, or even how to switch between the
different servers or if even I have to specify each server individually.
My reluctance to jump in head first is that I don't know what I would
be getting myself in to.
Well, the only way to discover is to just do it - that's the opensource way.
You can't lose, you can
only win. FWIW, this call in Mono would be probably just a simple wrapper
around the old transfer APIs.
Also you probably haven't heard much about these API's because they are
closer to the iron than most ASP.NET http://ASP.NET developers get.
I'm hardly an ASP.NET developer as I spent 99% of my time working as close to
the iron as it gets.
My last ASP.NET site was built nearly 3 years ago.
The only reason I use them is because I have to be as close to the
server as possible to get my rewriter to work like mod_rewrite. And the
reason I want to get them implemented is because I have been getting
many requests from developers who use XPS to do development and mod_mono
for production, and the XPS users want to also have my rewriter mimic
the mod_rewrite stuff for they see in the production environment.
If you give me a couple steps of what you think trivial would mean, I am
willing to take a whack at it. But I really have no idea where to
start, because my understanding of the inner workings of Mono ASP.NET
http://ASP.NET is not very deep.
I think, as said above, that at this point the closest we can get is to either
call one of the old
transfer APIs (HttpServerUtility.{Execute,Transfer}) or, should the
functionality of the new API
differ too much from them in _external_ behavior (as evidenced by tests on
.NET), borrow code from
them and use it to implement the new API. All you need to do that is in
mcs/class/System.Web/System.Web/HttpServerUtility.cs in our source tree.
I hope you understand, that I am willing to put the work in, I just have
no idea where to start. And I have a feeling that my knowledge of
Oh, believe me, I do - been there done that. My first contact with Mono and
Mono's System.Web was
quite overwhelming (Gonzalo probably laughed his noble behind off when he
reviewed some of my
patches) - but that's the only way to get started - just dive in head first.
best regards,
marek
Microsoft ASP.NET http://ASP.NET is clouding my understanding of Mom
ASP.NET http://ASP.NET.
Thanks,
Nick
On Thu, Sep 24, 2009 at 4:20 PM, Marek Habersack
gren...@twistedcode.net mailto:gren...@twistedcode.net wrote:
Nick Berardi wrote:
Hi Marek,
Hey Nick,
It is ultimately up to the team to apply or not apply the patch.
So I support whatever they choose is best for the Mono project.
Well... I'm part of the team... and in charge of ASP.NET... :)
However I see no reason to wait to add these stub method in
place. Because currently any application that relies on either
of these API's, get ugly exceptions like this:
Stack Trace: System.MissingMethodException: Method not found:
'System.Web.HttpServerUtility.Trans
ferRequest'.
at System.Web.HttpApplication+c__CompilerGenerated1.MoveNext
() [0x0]
at System.Web.HttpApplication+c__CompilerGenerated2.MoveNext
() [0x0]
at System.Web.HttpApplication.Tick () [0x0]
So there is not even a way to gracefully handle the exception
from with in the application.
I realize that, but I would really prefer to accept a patch which
does implement the API correctly.
And there are many ASP.NET http://ASP.NET http://ASP.NET
applications, mine is one of them, out there now that check to
see if they are running on the Integrated Pipeline or not. And
handle things differently based on this flag.
Your report is actually the first one we got regarding the issue, so
I'm not sure if it's that common (at least among apps running on Mono)
But by leaving out these stub API's the Mono project is
essentially forbidding any application that references these
API's from running on their software, even if the application
fully supports .NET 2.0 pre and post SP2. (which is when they
were introduced) At the very least these API's should be marked
with MonoTODOAttribute and committed so that applications that
want to work
Re: [Mono-dev] ASP:UpdatePanel with UpdateMode=Conditional updates always
Vitalii wrote:
Hi,
I'm facing such a problem:
https://bugzilla.novell.com/show_bug.cgi?id=532064
The situation (and the answer) haven't changed since, Vitalii - it is not
reproducible with latest
Mono, so use the latest. It was a bug in System.Web.Extensions which is
resolved now.
marek
ASP:UpdatePanel with UpdateMode=Conditional updates always, though no
child
controls caused postback, and no triggers were defined.
The are two UpdatePanels on a form. The child control of one UpdatePanel
causes
postback, that's why only this panel should be updated. On windows it works
fine. But with mono both panels are updated.
Here is my page:
%@ Page Language=C# AutoEventWireup=true Codebehind=Default.aspx.cs
EnableEventValidation=false
Inherits=MONO_Ajax_Test._Default %
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head id=Head1 runat=server
script src=js/jquery.js type=text/javascript/script
/head
body
form id=form1 runat=server
div
nbsp;/div
asp:ScriptManager ID=MainScriptManager runat=server
EnablePageMethods=true
/asp:ScriptManager
script language=javascript type=text/javascript
$(document).ready(function() {
ref = setInterval('UpdPanelUpdate()', 4000);
});
/script
script type=text/javascript
function UpdPanelUpdate() {
var button = document.getElementById(%= button.ClientID %);
button.click();
}
/script
table
tr
td style=height: 206px valign=top
asp:UpdatePanel ID=InsertEmployeeUpdatePanel
runat=server UpdateMode=Conditional
ContentTemplate
asp:Label runat=server
ID=InputTimeLabel%=DateTime.Now %/asp:Label
/ContentTemplate
/asp:UpdatePanel
/td
td style=height: 206px valign=top
asp:UpdatePanel ID=EmployeesUpdatePanel
runat=server UpdateMode=Conditional
ContentTemplate
asp:Label runat=server
ID=ListTimeLabel%=DateTime.Now %/asp:Label
asp:Button ID=button runat=server
OnClick=button_Click style=display:none;/
/ContentTemplate
/asp:UpdatePanel
/td
/tr
/table
/form
/body
/html
and Code Behind:
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Collections.Generic;
namespace MONO_Ajax_Test
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void button_Click(object sender, EventArgs e)
{
}
}
}
What can cause such a problem?
___
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] The Mono 1.0 profile.
Gert Driesen wrote: -Original Message- From: mono-list-boun...@lists.ximian.com [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Miguel de Icaza Sent: dinsdag 21 juli 2009 17:50 To: Gert Driesen Cc: 'mono-list'; 'Mono Announce'; 'mono-devel-list' Subject: Re: [Mono-list] The Mono 1.0 profile. Hello Gert, Hello Miguel, Will you be removing all 1.0 specific code (paths)? Will support for building the net_1_1 profile be removed altogether (or will you just need to opt-in)? Yes, I would like to do that: remove all the ifdefs for net_1_1 on post Mono 2.6 releases, and remove all the tests for 1.1 compatibility as well. Personally, I think we'll waste more cycles on this than that it will bring benefit. I disagree. 1.1 is a) mature enough to be moved to a separate location (in our case 2.4/2.6) to be maintained there should a fix be needed, b) slowly being phased out of real projects (not to mention new developments). Us having to carefully examine 1.1 code when we fix 2.0 bugs or add new code is really time consuming and unnecessary. I'm sure there are more urgent matters. I know the ifdefs are a mess, but we'll have them anyway (if we do not only want compatibility with MS's latest and greatest). Changes between 2.0 and 4.0 are not as dramatic as between 1.0 and 2.0 - they are mostly new APIs, or old internal APIs made public. We'll get rid of a real ton of #ifdefs, not to mention separate directories containing different code for 1.1 and 2.0 (like System.Web's configuration and session stuff) Will you discourage packagers to include the net_1_1 profile? I understand that Novell itself cannot continue supporting all profiles, but I think you should at least allow the community to continue this. My feeling is that we should come to a place where you can have two Mono runtimes installed, an older one to run the 1.0 runtime, and another one to run 2.0 and 4.0. Are you planning on creating a branch that can still be actively worked on by/for those that want to maintain the highest level of compatibility with .NET 1.1? From what I understand, 2.4 will is a long maintenance release and 2.6 will also be around with the latest 1.1. It's not a problem to commit a fix from time to time (rather unfrequently) to one, or even both, of those branches. The effort of doing it is much less that having to constantly cope in current code with legacy stuff. I'm not sure if anyone is even interested in this. If there is, then I assume they will even want to create new (bugfix/security fix) releases. This is part of long term maintenance releases anyway, no added effort here. Personally, I don't have any problem with backporting an fix to the maintenance branches once or twice a year. The issue is not only a problem with build times taking longer for each developer, they also take longer one each build bot, it almost doubles the test suite run times, and it wastes developer time (Novell or otherwise) making sure that we do not break the 1.0 profile. Sure, but you could just make the 1.0 profile opt-in. That wouldn't change anything for developers, it would only limit the build/test time. The biggest issue here, IMHO, is the wasted developer time. And perhaps only run the build bot test for that profile once a week (and leave it up to contributors to deal with it). If you have a good, proven release like 2.4 or 2.6 with stable runtime and class libraries, even that won't be necessary - you just know you have to run the tests for 1.1 only if a change is made to either the runtime or the class library. It is really more efficient that way. With the introduction of the 4.0 APIs with a new mscorlib we will end up in a situation where every check in has to be tested and compiled against 3 versions. It is an amount of work that is slowing Mono down as a whole. I understand, and making the 1.0 profile opt-in would deal with that. You should also make it clear that the 1.0 profile is no longer endorsed by Novell. Then why leave it in the source code for the newer releases? I rather invest in finding creative ways of packaging and installing two monos in parallel for those that want to have 1.0 based apps. Is this something that you will do or want to do ? ;-) Note that I'm not opposed to making the 1.0 profile a second-class citizen, but I consider removing it altogether a radical change. It will still be available and maintained at least for quite some time, so it's not removed per se. marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono and MVC - status update
Hello everybody, Recently an update to 2.4.2 has been released which included the Microsoft ASP.NET MVC sources integrated with our source tree and build system. Unfortunately, due to an omission on my part the update did not include a workaround for an mcs bug which, in effect, may cause some MVC applications to work incorrectly in certain circumstances. I have just posted a blog entry describing the situation and possible solutions at http://twistedcode.net/blog/post/2009/07/17/Mono-ASPNET-MVC-saga-update.aspx My apologies for all the trouble this omission might have caused. marek ___ 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] Bug with OutputCache directive in Mono 2.4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maxim wrote: Hi Marek! Hey Maxim, It seems like Mono 2.4.1 removed from Yast repository? I've tried to upgrade Mono again, but can't find version newer than 2.4-19.1. It was something temporal or my mistake? I have no idea - I don't have anything to do with packaging or repositories, sorry :) Later I've compiled Mono 2.4.1 from sources from SVN and run my application on xsp2. It seems like everything is OK with OurputCache directive. Glad to hear! best regards, marek All the best, Maxim Karavaev Marek Habersack wrote: Maxim wrote: Hello! Hello, I've just upgraded Mono to 2.4.1 on my develop machine and found very strange error. On all pages with directive %@ OutputCache Location=None VaryByParam=None Duration=1 % I've got error //CS0103: The name `None' does not exist in the current context// It seems like related to Location attribute. I've downgraded to Mono 2.4-19 and error disappeared. Should I file this bug in Novell Bugzilla? Please do, with a test case attached. Thanks! marek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNrysACgkQq3909GIf5uqpvwCdEQ57kLK+9BCdWeOz7Ni/5A7O xrEAnApZrB0vWkldJ8200/2cm+OhvqMF =PI0G -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Data.SQLite under mono
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arne Claassen wrote: I'm trying to get phxsoftware's System.Data.SQLite managed-only dll working under mono. The readme claims i should just need the binary in the same directory and it works for mono. It does work for windows, i just drop sqlite3.dll in the dir and it works. However, i try the same with sqlite3.so and i get the following on opening the connection: Unhandled Exception: System.EntryPointNotFoundException: sqlite3_next_stmt at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods:sqlite3_next_stmt (intptr,intptr) at System.Data.SQLite.SQLiteBase.ResetConnection (System.Data.SQLite.SQLiteConnectionHandle db) [0x0] at System.Data.SQLite.SQLiteBase.CloseConnection (System.Data.SQLite.SQLiteConnectionHandle db) [0x0] at System.Data.SQLite.SQLiteConnectionHandle.ReleaseHandle () [0x0] at System.Runtime.InteropServices.CriticalHandle.Dispose (Boolean disposing) [0x0] at System.Runtime.InteropServices.CriticalHandle.Dispose () [0x0] at System.Data.SQLite.SQLite3.Close () [0x0] at System.Data.SQLite.SQLiteConnection.Close () [0x0] at System.Data.SQLite.SQLiteConnection.Open () [0x0] at SqliteMixedTest.Program.Main (System.String[ args) [0x0] Same result if i try to rename to .so to .dll or use dllmap in the config. True whether i use the binary for sqlite-3.8.14 or build it from source. I tried this a while back with mono 1.9.1 and now i'm trying it with 2.4. Any suggestions? You need a newer version of sqlite3 native .so (3.6.x) best regards, marek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJp3wACgkQq3909GIf5uqIuQCeI16kIgn/WLjUS4bIcb/endnO NAIAnjYltYFvkzIm0ddeG/qCPW/WqyHw =qTzf -END PGP SIGNATURE- ___ 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] Bug with OutputCache directive in Mono 2.4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maxim wrote: Hello! Hello, I've just upgraded Mono to 2.4.1 on my develop machine and found very strange error. On all pages with directive %@ OutputCache Location=None VaryByParam=None Duration=1 % I've got error //CS0103: The name `None' does not exist in the current context// It seems like related to Location attribute. I've downgraded to Mono 2.4-19 and error disappeared. Should I file this bug in Novell Bugzilla? Please do, with a test case attached. Thanks! marek With best wishes, Maxim Karavaev P.S. Full exception stack: System.Web.Compilation.CompilationException: CS0103: The name `None' does not exist in the current context at System.Web.Compilation.AssemblyBuilder.BuildAssembly (System.Web.VirtualPath virtualPath, System.CodeDom.Compiler.CompilerParameters options) [0x0] at System.Web.Compilation.AssemblyBuilder.BuildAssembly (System.Web.VirtualPath virtualPath) [0x0] at System.Web.Compilation.BuildManager.GenerateAssembly (System.Web.Compilation.AssemblyBuilder abuilder, System.Collections.Generic.List`1 buildItems, System.Web.VirtualPath virtualPath, BuildKind buildKind) [0x0] at System.Web.Compilation.BuildManager.BuildAssembly (System.Web.VirtualPath virtualPath) [0x0] at System.Web.Compilation.BuildManager.GetCompiledType (System.String virtualPath) [0x0] at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath (System.String virtualPath, System.Type requiredBaseType) [0x0] at System.Web.UI.PageParser.GetCompiledPageInstance (System.String virtualPath, System.String inputFile, System.Web.HttpContext context) [0x0] at System.Web.UI.PageHandlerFactory.GetHandler (System.Web.HttpContext context, System.String requestType, System.String url, System.String path) [0x0] at System.Web.HttpApplication.GetHandler (System.Web.HttpContext context, System.String url, Boolean ignoreContextHandler) [0x0] at System.Web.HttpApplication.GetHandler (System.Web.HttpContext context, System.String url) [0x0] at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext () [0x0] ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoCIekACgkQq3909GIf5upjqACdGVq53gQLwczPB2GrVwRx/Y0z vAIAnjzywm6OKso2QxniQRwdqZPgNlFn =18zJ -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug fix for mono-2-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juraj Skripsky wrote: Hi Marek, Hey, I think r130971* fell through the cracks for branches/mono-2-4. May I commit it there as well? Done in r132708 - thanks for noticing it! best regards, marek *) http://lists.ximian.com/pipermail/mono-patches/2009-April/145782.html - Juraj ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn1WcEACgkQq3909GIf5uqxIQCeKDxBoJxNBbBmuGWjBG/1J5nD 7g4An1L1eHgYra1MX4xOh5Io1frF8ogR =KtHb -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoreck wrote: Hello, Hello, I have develop my first mono project, how can I create an installer for it? I need to run it on both Lunux and Windows. Try http://installjammer.com/ marek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknftSUACgkQq3909GIf5ur1gwCfXyoBTTGod8WbrnlTiX0iV8vK m1YAn3SO5qTIiCZOGogEjG8fKOsKgpe6 =/vcH -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Case unaware applications on Mono, IOMAP, FUSE and LD_PRELOAD - a call for discussion
Hello, As most of you know, Mono has an I/O layer mode in which it is able to cover problems with some .NET applications incoherence of dealing with file names. Some operating systems have file systems which are case-aware but not case-sensitive. Mono supports an environment variable called MONO_IOMAP which allows one to quickly work around those issues. When the variable is found in the application's environment, the runtime will look at the file access/open requests and do two things (depending on the IOMAP setting - see man mono(1) for details): 1. Remove any DOS drive references 2. If the file with the passed name is not found, it will become case insensitive and attempt to find the file that way. #2 above can be a a big performance hit if the application is big and/or makes a lot of requests to files on disks. MONO_IOMAP was intended to be an aid utility for those wanting to quickly test some application on Mono/Unix before making a decision of a move to Unix. Ideally, after seeing the application works, developers should make sure that the on-disk files are accessed with their actual names when the application is running on Unix. The assumption is fine, but there are some problems with it: 1. Mixed case in file names is so ubiquitous in Windows applications that if an application is large, it can be a considerable effort to make sure all file names are consistently used across the source code (and/or markup in case of ASP.NET applications) 2. Many Windows developers are unaware of the case-insensitivity problems which may result in bug reports against Mono (the best case) or giving up to use Mono (the worst case) because it does not work 3. It works only for managed code (see below for why it is bad) Items #1 and #2 may lead to the decision of using MONO_IOMAP permanently and, thus, hurting the application performance. Item #3 may affect for instance ASP.NET applications running under Apache, as mod_mono (until recently) wasn't taking any steps to make sure a file name it is passed from the managed back-end to send to the client using sendfile(2) (or an equivalent call) and there had been situations that despite the file name being handled correctly by the manged code, apache would issue a file not found error, thus causing some applications to break. It may also affect applications embedding the Mono runtime, for precisely the same reason - the unmanaged code being passed a file name which doesn't really exist on disk. An intermediate solution for mod_mono (a VERY suboptimal one) has been implemented a few days ago in which mod_mono, failing to locate a file on disk, resorts to the same process as the Mono runtime to attempt to locate the file (this process is triggered only if the application is configured to use IOMAP), thus doubling the time required to locate the file on disk. Of course, this hurts the performance of the application even more if it has a lot of mixed-case file access attempts. The correct solution to this issue would be to modify the Mono iolayer and some classes in System.IO to provide the managed code with the real path to the file. It isn't hard to implement, but I think it's better to remove the IOMAP capability from the Mono runtime and replace it with something else: * FUSE solution. Long ago, Gonzalo developed a FUSE file system which would lowercase all file names and thus take care of the problem (http://gonzalo.name/blog/archive/Mono/2006/Aug-30.html). Given that today FUSE exists for all operating systems we run Mono on, this approach could be used, with small modifications to the code found above, to implement the IOMAP in this way. Mounting a FUSE file system is a user-level operation which does not require root privileges, can be done automatically from inside, say, mod_mono (if the IOMAP environment variable is found) and the fs can even take care of stripping the drive information from the paths. That way both managed and unmanaged code take advantage of the support, the IOMAP code doesn't clutter Mono runtime and also using FUSE may be a more conscious decision on the user part than using IOMAP in the runtime. This is an elegant and portable solution. The disadvantage is that we add a possible dependency on FUSE (not a problem for any modern Linux distribution, might be a problem for other operating systems) * LD_PRELOAD solution. This solution is technically different to FUSE, but the outcome is similar. Instead of using a mounted file system, we would put the code in a shared library which would take over system calls responsible for opening/accessing the files (open, stat, access) and do the rest in the same way as FUSE. While this is more seamless than FUSE and, in theory, lighter than it, it might
Re: [Mono-dev] Building xsp afrom svn
On Thu, 2009-01-29 at 11:13 +, Paul wrote: Hi, Hello I seem to have problems when building both xsp and mono-addins from svn xsp: All goes fine until... /usr/bin/sn -q -R ../../src/Mono.WebServer/MonoWebserver.dll ./../mono.snk Assembly ../../src/Mono.WebSever/Mono.WebServer.dll signed make[2]: *** No rule to make target `ReaderWriterLockSlim.cs', needed by `Mono.WebServer2.dll'. Stop. make[2]: *** Leaving directory /home/paul/rpmbuild/BUILD/xsp-124651/src/Mono.WebServer Any ideas? I've fixed it in revisions 124916 (trunk) and 124917 (2.4 branch). Some files weren't included in the tarball created by make dist. best regards, marek signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Object data source update fails on nullable field.
On Tue, 2008-12-16 at 01:43 -0800, Vladimir Krasnov wrote: Hi Marek, Hey Vladimir, I've found some problems in updating row in GridView control that bound to ObjectDataSource. 1. ObjectDataSource fails to convert values to Nullable properties while creating data object. 2. BoundField should return null when no value entered by the user, it returns empty string and ObjectDataSource fails to convert it. Please review attached patch that fixes both these problems, also find attached test cases. In the BoundField chunk, please store box.Text in a variable, so that the getter is not called twice. Otherwise - ok to check in, thanks! best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Object data source update fails on nullable field.
On Tue, 2008-12-16 at 10:29 +, Ivan N. Zlatev wrote: 2008/12/16 Vladimir Krasnov vladim...@mainsoft.com Hi Marek, I've found some problems in updating row in GridView control that bound to ObjectDataSource. 1. ObjectDataSource fails to convert values to Nullable properties while creating data object. 2. BoundField should return null when no value entered by the user, it returns empty string and ObjectDataSource fails to convert it. Please review attached patch that fixes both these problems, also find attached test cases. Vladimir I don't know if the web databinding layer uses TypeConverters (the WinForms one does), but just in case I should note that I have implemented the NullableConverter two weeks ago in SVN HEAD. It does, when the type being converted is adorned with the TypeConverter attribute best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Fwd: [Mono-patches] r116660 - trunk/mono/data/net_2_0]
On Wed, 22 Oct 2008 13:47:46 +0900 Atsushi Eno [EMAIL PROTECTED] wrote: Hi grendel, Hey Atsushi, How does this break 2.0 apps? They do not exist in .NET, but they do in our 2.0 profile (lib/mono/2.0). If you have an application which uses System.Web.Extensions 1.0, it will break. The Telerik controls (for 2.0), for instance, failed to compile because the compiler complained about duplicate symbols in the assemblies. .NET leaves the assemblies out for the same reason - to support legacy 2.0 apps painlessly. If you want to make it easier to reference 3.5 libraries in a project, I'd recommend adding a .NET 3.5 rule to mconfig (in the similar fashion AJAX is added). See mcs/tools/mconfig/data/config.xml and http://www.mono-project.com/Howto_Mconfig best, marek Atsushi Eno Original Message Subject: [Mono-patches] r116660 - trunk/mono/data/net_2_0 Date: Tue, 21 Oct 2008 14:40:56 -0400 (EDT) From: Marek Habersack ([EMAIL PROTECTED]) [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Author: mhabersack Date: 2008-10-21 14:40:56 -0400 (Tue, 21 Oct 2008) New Revision: 116660 Modified: trunk/mono/data/net_2_0/web.config Log: Revert r116595 - the 3.5 assemblies mustn't be included in the system web.config - it breaks all 2.0 applications Modified: trunk/mono/data/net_2_0/web.config === --- trunk/mono/data/net_2_0/web.config2008-10-21 18:40:38 UTC (rev 116659) +++ trunk/mono/data/net_2_0/web.config2008-10-21 18:40:56 UTC (rev 116660) @@ -75,11 +75,9 @@ add namespace=System.Text.RegularExpressions / add namespace=System.Web / add namespace=System.Web.Caching / - add namespace=System.Web.DynamicData / add namespace=System.Web.SessionState / add namespace=System.Web.Security / add namespace=System.Web.Profile / - add namespace=System.Web.Routing / add namespace=System.Web.UI / add namespace=System.Web.UI.WebControls / !-- add namespace=System.Web.UI.WebControls.WebParts / -- @@ -96,10 +94,6 @@ add assembly=System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a / add assembly=System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a / add assembly=System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a / - add assembly=System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 / - add assembly=System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 / - add assembly=System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 / - add assembly=System.Web.DynamicData, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 / add assembly=System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 / add assembly=* / !-- Add assemblies in bin directory -- /assemblies ___ Mono-patches maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-patches ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Fwd: [Mono-patches] r116660 - trunk/mono/data/net_2_0]
On Thu, 23 Oct 2008 01:44:25 +0900 Atsushi Eno [EMAIL PROTECTED] wrote: Hey Marek, Marek Habersack wrote: On Wed, 22 Oct 2008 13:47:46 +0900 Atsushi Eno [EMAIL PROTECTED] wrote: Hi grendel, Hey Atsushi, How does this break 2.0 apps? They do not exist in .NET, but they do in our 2.0 profile (lib/mono/2.0). If you have an application which uses System.Web.Extensions 1.0, it will break. The Telerik controls (for 2.0), for instance, failed to compile because the compiler complained about duplicate symbols in the assemblies. .NET leaves the assemblies out for the same reason - to support legacy 2.0 apps painlessly. If you want to make it easier to reference 3.5 libraries in a project, I'd recommend adding a .NET 3.5 rule to mconfig (in the similar fashion AJAX is added). See mcs/tools/mconfig/data/config.xml and http://www.mono-project.com/Howto_Mconfig Oh, right. Actually I found an assemblies section in my sample DynamicData application (that I sent you before). So it must be included in every web app instead of having those references in our global web.config. yeah, and modifying mconfig to ease adding that info would be a good thing. Do you think you could do that? Then there should be different problem in our build manager that blocks compiling DynamicData sites. Maybe it is insufficient support for pages/controls (there is a configuration element which is add tagPrefix=asp namespace=System.Web.DynamicData ... in web.config). We support that. best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about AjaxToolkit and System.Web.Extensions on Mono
On Wed, 1 Oct 2008 14:47:52 -0400 Karel Tamayo [EMAIL PROTECTED] wrote: Hi everybody: I'd be glad if anyone could help me here. I'm running a web application on mono. I did port it from asp.net using moma and although I was using VS 2008 I was targeting .net framework 2.0 to be OK with compatibility issues. I got the System.Web.Extensions.dll for the mono framework and copied in Bin folder of my application. The application runs perfectly but the Ajax stuff are not working at all. I mean, I can load the page in which I have 2 linked dropdowns with states and municipalities data but, the update panel in which both are contained doesn't work. My page is making a full postback to the server every time I change the selected item of the states dropdown. I checked the error console and then I sow that the initialization script is setting this error message: *Error: ASP.NET Ajax client-side framework failed to load.* Where do I have to copy the toolkit, the extensions? What am I missing??? You don't need the Microsoft System.Web.Extensions.dll, Mono ships its own version. All you need to do is to is to provide appropriate Web.config options. To add them to your existing config or create a new Web.config, issue this command (assuming you're running Mono 1.9 or later): mconfig af -t:web AJAX As for the Ajax Control Toolkit - download their demos, but make sure you're downloading the version for .NET 2.0, the 3.5 version might still give problems. Run xsp2 in the toolkit demos toplevel dir and everything should work as expected. regards, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Controls within a control in ASP.NET
On Tue, 26 Aug 2008 05:45:00 -0400 Wael Zeenni [EMAIL PROTECTED] wrote: Hello, Petit, Marek, Thanks for the responses so far. I (finally) got XSP2 and Mono to run in debug mode and now there are line numbers into the code files that show up on the error page. Below is what I am getting: Server Error in '/' Application [snip] C:\Users\wzeenni\AppData\Local\Temp\wzeenni-temp-aspnet-0\13ab1697\App_Web_4d5b6eaf_3.cs:1096 at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x00049] in [snip] Does that mean anything to anyone? In the above error that is referring to my Default.aspx page, line 37 and 41 are simply the Dialog control that I am using. In itself it doesn't mean anything - you forgot to attach the generated file (whose path I left above). Note that each time you generate restart the application, the file will have a different name - please copy the file and attach it to the mail along with the new backtrace. regards, marek I have no clue how to read through the source code of mono for the other .cs files. If anyone can help I would REALLY appreciate it. Thank you. Zee. _ From: Marek Habersack [mailto:[EMAIL PROTECTED] To: Wael Zeenni [mailto:[EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com, Petit Eric [mailto:[EMAIL PROTECTED] Sent: Mon, 25 Aug 2008 04:20:06 -0400 Subject: Re: [Mono-dev] Controls within a control in ASP.NET On Mon, 25 Aug 2008 02:17:32 -0400 Wael Zeenni [EMAIL PROTECTED] wrote: Dear Eric, Thanks for the response. I ran the ComponentArt DLL through the MoMA and everything turned out fine. There were no PInvokes and no missing Mono functionality. As to where the error is coming up, I know exactly where it's happening. I started a blank aspx page and placed 2 controls in it. One of them is a Dialog control and then, inside this dialog control, I placed a text box. When I ran this through IIS, it worked fine. However, when I ran it with Mono, I got the same error below. Realistically, I don't need to declare these controls using new at runtime as I am not creating them dynamically. They are already on the page. However, if this is a Mono workaround, I guess I'll have to try that. But where should I declare these controls? In the PageLoad()? And regarding your other solution about tracing, unfortunately, I'm not that experienced with doing this sort of stuff. I just thought that I couldn't be the only person here with this problem. I'm sure someone else must have had some project where a control is contained within another control :p Any ideas? I really need this to work or else it will effectively kill my web app's cross-platformness :( Zee _ It's most likely a bug in Mono. It's hard to fix it given the information in your previous mail, though. Could you, please, run the application with mono --debug (and make sure that compilation debug=true/ is present in your web.config), then post the backtrace together with the generated file. That will give more information and make it easier to see what's going on. regards, marek !DSPAM:2,48b3d7ae238117706610945! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Controls within a control in ASP.NET
On Mon, 25 Aug 2008 02:17:32 -0400 Wael Zeenni [EMAIL PROTECTED] wrote: Dear Eric, Thanks for the response. I ran the ComponentArt DLL through the MoMA and everything turned out fine. There were no PInvokes and no missing Mono functionality. As to where the error is coming up, I know exactly where it's happening. I started a blank aspx page and placed 2 controls in it. One of them is a Dialog control and then, inside this dialog control, I placed a text box. When I ran this through IIS, it worked fine. However, when I ran it with Mono, I got the same error below. Realistically, I don't need to declare these controls using new at runtime as I am not creating them dynamically. They are already on the page. However, if this is a Mono workaround, I guess I'll have to try that. But where should I declare these controls? In the PageLoad()? And regarding your other solution about tracing, unfortunately, I'm not that experienced with doing this sort of stuff. I just thought that I couldn't be the only person here with this problem. I'm sure someone else must have had some project where a control is contained within another control :p Any ideas? I really need this to work or else it will effectively kill my web app's cross-platformness :( Zee _ It's most likely a bug in Mono. It's hard to fix it given the information in your previous mail, though. Could you, please, run the application with mono --debug (and make sure that compilation debug=true/ is present in your web.config), then post the backtrace together with the generated file. That will give more information and make it easier to see what's going on. regards, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Enable reading of the ASP.NET Requests Queued counter from external process
Hello everybody,
The attached patch implements reading the counter mentioned in the
subject
when using a named instance (on Unix it's a process ID). Please review,
best,
marek
Index: mono/metadata/mono-perfcounters.c
===
--- mono/metadata/mono-perfcounters.c (revision 110495)
+++ mono/metadata/mono-perfcounters.c (working copy)
@@ -847,6 +847,13 @@
return TRUE;
}
break;
+
+ case CATEGORY_ASPNET:
+ switch (id) {
+ case COUNTER_ASPNET_REQ_Q:
+ sample-rawValue = vt-counters-aspnet_requests_queued;
+ return TRUE;
+ }
}
return FALSE;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Enable reading of the ASP.NET Requests Queued counter from external process
On Fri, 15 Aug 2008 01:22:05 +0200 Zoltan Varga [EMAIL PROTECTED] wrote: Hi, Hey, Seems harmless. Thanks :) - committed in r110541 best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Cross-compiling mono for Windows on Linux, using Mingw
On Thu, 31 Jul 2008 16:41:51 -0400 Miguel de Icaza [EMAIL PROTECTED] wrote: This looks like a good patch. I've committed it to trunk in revision 109671. The resulting mono works fine on Windows - all one needs to do is to unpack the generated zip file in the root directory of a Windows drive and add the bin subdirectory to the PATH variable. But I would like to see the relevant Wiki pages updated with instructions and with details. The instructions are at http://mono-project.com/Compiling_Mono#Cross-compiling_on_Linux_using_MinGW best, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Cross-compiling mono for Windows on Linux, using Mingw
Hello everybody,
Attached is a patch which makes it possible to cross-compile Mono for
Windows on Linux. In order to do it, after applying the patch, you need to
install
the mingw cross compiler for your system. OpenSUSE 10.3 and 11 users can do it
from
the repository at:
http://download.opensuse.org/repositories/CrossToolchain:/mingw/openSUSE_10.3/
The attached patch contains a script which builds the mono runtime for
Windows (it doesn't build the class libraries) and, by default, it assumes that
the
cross compiler is installed in '/opt/cross' and the mingw target is
'-mingw32msvc'.
You can set the former with the first parameter to the script and the latter
with
the second parameter. The compiled mono will be put in `pwd`/mono-win32.
In order to build and link you will also need the following package
(sorry,
it's only an RPM) with Mono build time dependencies packaged to work with the
cross
compiler from the above OpenSUSE repository:
http://grendel.thanes.org/mono/cross-mono-build-dependencies-1.0.0-1.noarch.rpm
Note that despite having successfully compiled mono I haven't had time
to
actually _run_ it on Windows yet :) - ymmv, then :)
Please review the patch and let me know if it's ok to commit it.
marek
Index: runtime/Makefile.am
===
--- runtime/Makefile.am (revision 109338)
+++ runtime/Makefile.am (working copy)
@@ -75,8 +75,13 @@
cd $(mcs_topdir) $(MAKE) NO_DIR_CHECK=1 PROFILES='$(build_profiles)' run-test-profiles
if PLATFORM_WIN32
+if CROSS_COMPILING
+cur_dir_cmd = pwd
+PLATFORM_PATH_SEPARATOR = :
+else
cur_dir_cmd = cygpath -w -a .
PLATFORM_PATH_SEPARATOR = ;
+endif
else
cur_dir_cmd = pwd
PLATFORM_PATH_SEPARATOR = :
Index: scripts/Makefile.am
===
--- scripts/Makefile.am (revision 109338)
+++ scripts/Makefile.am (working copy)
@@ -126,8 +126,13 @@
endif
if PLATFORM_WIN32
+if CROSS_COMPILING
+plat_bindir = $(bindir)
+mono_instdir = $(prefix)/lib/mono
+else
plat_bindir = $(shell cygpath -m $(libdir))
mono_instdir = $(shell cygpath -m $(libdir))/mono
+endif
else
plat_bindir = $(bindir)
mono_instdir = $(prefix)/lib/mono
Index: build-mingw32.sh
===
--- build-mingw32.sh (revision 0)
+++ build-mingw32.sh (revision 0)
@@ -0,0 +1,33 @@
+#!/bin/bash -e
+CROSS_DIR=${1:-/opt/cross/}
+MINGW=${2:-i386-mingw32msvc}
+CROSS_PKG_CONFIG_DIR=$CROSS_DIR/$MINGW/lib/pkgconfig
+PATH=$CROSS_DIR/bin:$PATH
+
+export PATH
+
+if [ -d ./.git/svn ]; then
+SVN_INFO='git svn info'
+elif [ -d ./.svn ]; then
+SVN_INFO='svn info'
+else
+SVN_INFO=
+fi
+
+if [ -n $SVN_INFO ]; then
+MONO_SVN_REVISION=`$SVN_INFO | grep Revision | sed 's/.*: //'`
+MONO_BRANCH=`$SVN_INFO | grep URL | sed -e 's;.*source/;;g' -e 's;/mono;;g'`
+else
+MONO_SVN_REVISION=rUNKNOWN
+MONO_BRANCH=tarball
+fi
+
+MONO_VERSION=`grep AM_INIT_AUTOMAKE configure.in | cut -d ',' -f 2|tr -d '\)'`
+MONO_PREFIX=/mono-${MONO_VERSION}-${MONO_BRANCH}-r${MONO_SVN_REVISION}
+
+echo Mono Win32 installation prefix: $MONO_PREFIX
+./autogen.sh --prefix=$MONO_PREFIX --with-crosspkgdir=$CROSS_PKG_CONFIG_DIR --target=$MINGW --host=$MINGW --enable-parallel-mark --program-transform-name=
+make
+mkdir -p mono-win32
+rm -rf mono-win32/*
+make DESTDIR=`pwd`/mono-win32 install
Property changes on: build-mingw32.sh
___
Added: svn:executable
+ *
Added: svn:eol-style
+ native
Index: mono/metadata/Makefile.am
===
--- mono/metadata/Makefile.am (revision 109338)
+++ mono/metadata/Makefile.am (working copy)
@@ -2,8 +2,13 @@
# Use -m here. This will use / as directory separator (C:/WINNT).
# The files that use MONO_ASSEMBLIES and/or MONO_CFG_DIR replace the
# / by \ if running under WIN32.
+if CROSS_COMPILING
+assembliesdir = ${libdir}
+confdir = ${sysconfdir}
+else
assembliesdir = `cygpath -m ${libdir}`
confdir = `cygpath -m ${sysconfdir}`
+endif
export HOST_CC
# The mingw math.h has extern inline functions that dont appear in libs, so
# optimisation is required to actually inline them
Index: configure.in
===
--- configure.in (revision 109338)
+++ configure.in (working copy)
@@ -77,8 +77,8 @@
HOST_CC=gcc
# Windows 2000 is required that includes Internet Explorer 5.01
CPPFLAGS=$CPPFLAGS -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS -DFD_SETSIZE=1024
- libmono_cflags=-mno-cygwin
- libmono_ldflags=-mno-cygwin
+ libmono_cflags=-mno-cygwin -mms-bitfields -mwindows
+ libmono_ldflags=-mno-cygwin -mms-bitfields -mwindows
libdl=
libgc_threads=win32
gc_default=included
@@ -491,9 +491,13 @@
AC_CONFIG_SUBDIRS(eglib)
;;
system)
+
Re: [Mono-dev] [PATCH] Cross-compiling mono for Windows on Linux, using Mingw
Hello again,
Attached is an updated patch which does full compilation of both the
cross
runtime and the class library/compilers.
marek
Index: runtime/Makefile.am
===
--- runtime/Makefile.am (revision 109357)
+++ runtime/Makefile.am (working copy)
@@ -75,8 +75,13 @@
cd $(mcs_topdir) $(MAKE) NO_DIR_CHECK=1 PROFILES='$(build_profiles)' run-test-profiles
if PLATFORM_WIN32
+if CROSS_COMPILING
+cur_dir_cmd = pwd
+PLATFORM_PATH_SEPARATOR = :
+else
cur_dir_cmd = cygpath -w -a .
PLATFORM_PATH_SEPARATOR = ;
+endif
else
cur_dir_cmd = pwd
PLATFORM_PATH_SEPARATOR = :
Index: scripts/Makefile.am
===
--- scripts/Makefile.am (revision 109357)
+++ scripts/Makefile.am (working copy)
@@ -126,8 +126,13 @@
endif
if PLATFORM_WIN32
+if CROSS_COMPILING
+plat_bindir = $(bindir)
+mono_instdir = $(prefix)/lib/mono
+else
plat_bindir = $(shell cygpath -m $(libdir))
mono_instdir = $(shell cygpath -m $(libdir))/mono
+endif
else
plat_bindir = $(bindir)
mono_instdir = $(prefix)/lib/mono
Index: build-mingw32.sh
===
--- build-mingw32.sh (revision 0)
+++ build-mingw32.sh (revision 0)
@@ -0,0 +1,72 @@
+#!/bin/bash -e
+CROSS_DIR=/opt/cross/
+MINGW=i386-mingw32msvc
+CROSS_PKG_CONFIG_DIR=$CROSS_DIR/$MINGW/lib/pkgconfig
+PATH=$CROSS_DIR/bin:$PATH
+
+export PATH
+
+if [ -d ./.git/svn ]; then
+SVN_INFO='git svn info'
+elif [ -d ./.svn ]; then
+SVN_INFO='svn info'
+else
+SVN_INFO=
+fi
+
+if [ -n $SVN_INFO ]; then
+MONO_SVN_REVISION=`$SVN_INFO | grep Revision | sed 's/.*: //'`
+MONO_BRANCH=`$SVN_INFO | grep URL | sed -e 's;.*source/;;g' -e 's;/mono;;g'`
+else
+MONO_SVN_REVISION=rUNKNOWN
+MONO_BRANCH=tarball
+fi
+
+MONO_VERSION=`grep AM_INIT_AUTOMAKE configure.in | cut -d ',' -f 2|tr -d '\)'`
+MONO_PREFIX=/mono-${MONO_VERSION}-${MONO_BRANCH}-r${MONO_SVN_REVISION}
+
+echo Mono Win32 installation prefix: $MONO_PREFIX
+NOCONFIGURE=yes
+export NOCONFIGURE
+./autogen.sh
+
+if [ -f ./Makefile ]; then
+make distclean
+fi
+
+if [ ! -d build-cross-windows ]; then
+mkdir build-cross-windows
+fi
+
+cd build-cross-windows
+rm -rf *
+../configure --prefix=$MONO_PREFIX --with-crosspkgdir=$CROSS_PKG_CONFIG_DIR --target=$MINGW --host=$MINGW --enable-parallel-mark --program-transform-name=
+make
+mkdir -p mono-win32
+rm -rf mono-win32/*
+make DESTDIR=`pwd`/mono-win32 install
+cd ..
+
+if [ ! -d build-cross-windows-mcs ]; then
+mkdir build-cross-windows-mcs
+fi
+cd build-cross-windows-mcs
+rm -rf *
+../configure --prefix=$MONO_PREFIX --enable-parallel-mark
+make
+
+PROFILES=PROFILE=net_2_0 PROFILE=net_2_1 PROFILE=net_3_5
+cd build-cross-windows-mcs
+INSTALL_DESTDIR=`pwd`/../build-cross-windows/mono-win32
+cd ../../mcs/mcs
+
+for p in $PROFILES; do
+make DESTDIR=$INSTALL_DESTDIR $p install
+done
+
+cd ../class
+for p in $PROFILES; do
+make DESTDIR=$INSTALL_DESTDIR $p install
+done
+
+cd ../../mono
Property changes on: build-mingw32.sh
___
Added: svn:executable
+ *
Added: svn:eol-style
+ native
Index: mono/metadata/Makefile.am
===
--- mono/metadata/Makefile.am (revision 109357)
+++ mono/metadata/Makefile.am (working copy)
@@ -2,8 +2,13 @@
# Use -m here. This will use / as directory separator (C:/WINNT).
# The files that use MONO_ASSEMBLIES and/or MONO_CFG_DIR replace the
# / by \ if running under WIN32.
+if CROSS_COMPILING
+assembliesdir = ${libdir}
+confdir = ${sysconfdir}
+else
assembliesdir = `cygpath -m ${libdir}`
confdir = `cygpath -m ${sysconfdir}`
+endif
export HOST_CC
# The mingw math.h has extern inline functions that dont appear in libs, so
# optimisation is required to actually inline them
Index: configure.in
===
--- configure.in (revision 109357)
+++ configure.in (working copy)
@@ -77,8 +77,8 @@
HOST_CC=gcc
# Windows 2000 is required that includes Internet Explorer 5.01
CPPFLAGS=$CPPFLAGS -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS -DFD_SETSIZE=1024
- libmono_cflags=-mno-cygwin
- libmono_ldflags=-mno-cygwin
+ libmono_cflags=-mno-cygwin -mms-bitfields -mwindows
+ libmono_ldflags=-mno-cygwin -mms-bitfields -mwindows
libdl=
libgc_threads=win32
gc_default=included
@@ -491,9 +491,13 @@
AC_CONFIG_SUBDIRS(eglib)
;;
system)
+ pkg_config_path=$PKG_CONFIG_PATH
+ unset PKG_CONFIG_PATH
BUILD_GLIB_CFLAGS=`$PKG_CONFIG --cflags glib-2.0 gthread-2.0`
BUILD_GLIB_LIBS=`$PKG_CONFIG --libs glib-2.0 gthread-2.0`
-
+ PKG_CONFIG_PATH=$pkg_config_path
+ export PKG_CONFIG_PATH
+
## Versions of dependencies
GLIB_REQUIRED_VERSION=1.3.11
@@ -2175,7 +2179,11 @@
mono_cfg_root=$mono_build_root/runtime
if test
Re: [Mono-dev] [PATCH] HTML encode attributes that might need encoding
On Fri, 25 Jul 2008 21:52:34 -0700 Dean Brettle [EMAIL PROTECTED] wrote: Hi all, Hey Dean, Please review the attached small patch and let me know if it is OK to commit this to mono-2-0 and trunk. All existing tests pass, but I haven't added any new tests specifically for the changes. It's not clear whether it is worth the effort for this change. Feedback welcome. Here's the ChangeLog Since the current tests don't check whether HTML special chars are encoded, I think it would be a good idea to add tests along with this change. Also, have you compared the output with what .NET produces in such cases? Otherwise, the patch looks good to go in. best regards, marek entry: 2008-07-25 Dean Brettle [EMAIL PROTECTED] * HtmlControl.cs (PreProcessRelativeReference), HtmlForm.cs (RenderAttributes), HtmlInputButton (RenderAttributes), HtmlInputRadioButton (RenderAttributes), HtmlSelect (RenderChildren): Encode attributes that could contain HTML special chars. Thanks, --Dean !DSPAM:2,488aad94243988811816156! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Fixes for races and other bugs in App_Browsers/*.browser processing
On Fri, 25 Jul 2008 17:57:40 -0700 Dean Brettle [EMAIL PROTECTED] wrote: Hey Dean, Please review the attached patch and let me know if it is OK to commit to mono-2-0 and trunk. Attached in an updated patch. It just adds tests for the two non-race bugs: * nBrowser/Node.cs: Fixed bug where capabilities containing literal $ or Please commit, thanks! best regards, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r108492 - in branches/mono-2-0/mcs/class/System.Web: System.Web.UI Test/System.Web.UI
On Tue, 22 Jul 2008 21:12:03 +0200 Gert Driesen [EMAIL PROTECTED] wrote: Hi Dean, Hey Gert, Was this change approved for the 2.0 branch, or did you commit it to the branch by accident? It was approved. Also, your patch was not complete; Stream.Length can/will also throw a NotSupportedException when the stream is unseekable. I'll commit a slighty modified version to SVN HEAD in a few minutes. Please update the branch as well, thanks. regards, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch/2nd Post: mod_mono restart
On Mon, 14 Jul 2008 07:50:36 -0400 Joshua Tauberer [EMAIL PROTECTED] wrote: [Originally posted May 21...] Hello Joshua, I must have missed the mail - sorry about that. I encountered a problem when doing a mod-mono-server restart through the mod_mono control panel that when requests came in while the restart was in progress, the restart would fail, mod-mono-server would be forked but fail to start, and it would be continually forked at each request but still fail to start. My solution was to disallow requests while a restart is in progress. The attached patch allows mod-mono-server backends to be 'paused' with requests coming in dropped with 503s during that time. The control panel restart now pauses and resumes around the restart. You can also pause/resume from the control panel. The patch also changes where locking is done for the active requests counter. (This should have no consequences.) Attached. I'll commit if it's ok. Looks, ok - do commit. Thanks! best regards, marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ResourceReader patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 May 2008 10:21:19 +0200 Andreas Nahr [EMAIL PROTECTED] wrote: Is there any reason for not using structs? No sense in needlessly torturing the GC ;) Makes sense - applied in r104334, thanks! marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIPdA1q3909GIf5uoRAlsvAJ98jcbhTtuNUudBHybCR4xBCD3k1QCfYngI Qougwstb8DzXROt6uTn7aHc= =Gris -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Some questions about ASP.NET
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 May 2008 10:18:32 +0200 Daniel Nauck [EMAIL PROTECTED] wrote: Hello, Hello, the bug i mentioned is already fixed in Mono 1.9.1 Please create a small testcase an open a new bugreport for it, thanks: http://mono-project.com/Bugs Before that, please check what's your LANG variable value. It is likely your apache environment doesn't have it present and resorts to US-ASCII for request encoding, which results in corrupt characters. marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIKs+2q3909GIf5uoRAglDAJ9LXtX3ieL+ZRZ8ysk7q2CHUrRdVwCfY2DB Ns0/dyoeLSdDCRIgJXCBRQ8= =T3Cj -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Changes/fixes to support for App_Browsers and control adapters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 7 Apr 2008 14:04:24 -0700 Dean Brettle [EMAIL PROTECTED] wrote: It's been 2 weeks and I'm still waiting on approval to commit this. Is Marek on vacation or something? The text of my original message is below. The full message with patcheshttp://lists.ximian.com/pipermail/mono-devel-list/2008-March/027264.htmlcan be found in the archive. I thought I'd approved it already, sorry - please commit, thanks! best, marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH+o6jq3909GIf5uoRAvSkAJ4jluElzZhMJcMR53+gmyJbByMaGgCeKcKc aRtGQXuI4QlUDqN1YKENnfk= =3ds3 -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.Web support for *.browser files and control adapters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 9 Mar 2008 16:21:14 -0700 Dean Brettle [EMAIL PROTECTED] wrote: Hi all, Hey Dean, The attached patch adds support for *.browser files and control adapters to System.Web under the 2.0 profile. It doesn't break any existing tests and includes a bunch of new tests. The *.browser processing is based on Owen Brady's implementationhttp://ocean.accesswa.net/projects/Ocean2.Web.HttpCapabilities.zip . This patch doesn't add any *.browser files to the mono installation. For now, users will need to put those files in their apps' App_Browsers folder. OK to commit? Looks good to me, please go ahead and commit. Thanks! marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH1HUuq3909GIf5uoRAp1tAJ9o8QGzcj9bFM4jd/slRBjNUmskTwCfQYXp U0yMz0Pv+5fRaCrhqtrDz3o= =Grci -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mojoportal still broken on lastest svn (r96314)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Feb 2008 08:30:30 -0500 Joe Audette [EMAIL PROTECTED] wrote: Hi All, Hey Joe, I'm still not able to get mojoportal working using mono built from svn since before my vacation Feb 9th. Using mojoportal from svn trunk, it works ok on Mono 1.2.6. (Note to build mojoportal on 1.2.6 you have to remove the compiler directive USESETTINGSMAP as settings map was implemented after 1.2.6). On 1.2.6 you also have to replace the contents of Web.config with the contents from Web.mono.config [snip] Please let me know if there is anything I can do to help pin down the problem. I have already identified the source of the problem - there are some .aspx files which are unused on Mono and whose base classes are partial ones with only the designer part being compiled. With the recent introduction of the batch compilation mode, they result in the error you've pointed out. Please see https://bugzilla.novell.com/show_bug.cgi?id=362038#c1 for more info. best regards, marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHvbhUq3909GIf5uoRApYyAJ0WkAUsZZT2zwn69PhlTbMp5hp1HQCeLbEU 3cVNCC3mwdRxvNQY8cBS4xk= =5re0 -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance improvement for System.Web.UI.Page.RegisterRequiresPostBack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Feb 2008 09:15:23 -0800 Vladimir Krasnov [EMAIL PROTECTED] wrote: Hello, Hello Vladimir, Please review and approve attached patch that improves Page.RegisterRequiresPostBack method, it will give up to 5% for controls that calls this method. Please commit, thanks! marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHvE4eq3909GIf5uoRAhcEAJkBz48splbR3OCRRttE1UwgIPISNgCfbVNq kul/En2iHfSeEm0FS40GmLk= =/8Lw -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] xsp issu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Feb 2008 09:58:06 +0530 Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] wrote: HI, Hi, I run with xsp2, it get this error. Server Error in '/' Application -- *Cannot cast from source type to destination type.* *Description: *Error processing request. *Error Message: *HTTP 500. System.InvalidCastException: Cannot cast from source type to destination type. *Stack Trace: * System.InvalidCastException: Cannot cast from source type to destination type. at System.DateTime.System.IConvertible.ToInt32 (IFormatProvider provider) [0x0] at System.Convert.ToInt32 (System.Object value, IFormatProvider provider) [0x0] at System.Convert.ToInt32 (System.Object value) [0x0] at System.Data.Common.AbstractDataContainer+Int32DataContainer.set_Item (Int32 index, System.Object value) [0x0] at System.Data.DataColumn.set_Item (Int32 index, System.Object value) [0x0] It's impossible to say what the issue is without the application source, but the problem in this case might be either in the data you feed System.Data with, or in System.Data itself. best regards, marek -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHvE6Wq3909GIf5uoRAjB1AJ0fWqjxa80U/Ugn4y1daO8WZZOrmACeMAp5 NZRRqEvmnbTmbeRnjVJSwZg= =1eQh -END PGP SIGNATURE- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono and xsp patches
On Sun, 20 Jan 2008 08:29:01 -0500, Joshua Tauberer [EMAIL PROTECTED] scribbled: Hi, Hey Joshua, I have two sets of patches: for mod_mono and xsp. The mod_mono patch corrects a few minor things, like proper destruction of the new shm's and checking everything is initialized. The xsp patch corrects a check that a request ID is valid by putting it within a lock, because requests could be finished after the check and before the lock is entered. If these are OK, I have another mod_mono patch to follow. They're OK to go in, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono and xsp patches
On Mon, 21 Jan 2008 13:45:54 -0500, Joshua Tauberer [EMAIL PROTECTED] scribbled: Marek Habersack wrote: They're OK to go in, thanks! Great, in that case, I'm attaching another patch for mod_mono that implements rate limiting. I had found that under relatively heavy load, mod-mono-server would deadlock. Incoming requests would hang forever, with the result that all of the Apache child processes would get tied up as more requests came in, and so all websites on the server would stop. There are only so many worker threads in the XSP thread pool, and at a certain point they're going to get used up. I forget how many threads there are by default, maybe 128, but at a few workers per request, that number gets used up quickly. Obviously the right thing to do would be to make sure mod-mono-server doesn't hang when it runs out of worker threads (if this was even the problem), but barring a fix there, this did the job. It would be a good thing to make sure that the thread pool exhaustion was causing the problem, but even without doing it - I think such rate limiting is a good thing to have. In my case, I was having problems when the number of concurrent requests went above 20 or 25. (I forget the details. I've been using this patch for around 3-4 months... modulo changes I made today.) The patch by default limits the number of concurrent requests passed to mod-mono-server to 20. After that, it holds onto (by default) up to 20 more, checking periodically until the initial 20 decreases or a timeout (hard-coded at 10 seconds). The two 20's are configurable with MonoMaxActiveRequests and MonoMaxWaitingRequests. This will only work on Apache2 since it relies on the shared memory dashboards. Great stuff :) - please commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.Web.HttpContext
On Wed, 16 Jan 2008 06:18:30 -0800, Vladimir Krasnov [EMAIL PROTECTED] scribbled: Hello, Hello Vladimir, Please review and approve attached performance optimization patch. Why not use the generic Stack container instead? regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for HttpRequest and HttpCookieCollection
On Wed, 16 Jan 2008 15:40:51 +0100, Juraj Skripsky [EMAIL PROTECTED] scribbled: Hi Marek, Hey Juraj, Did you get this mail? Could you please review my patch? Thanks! Please commit, looks good. Thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.Web.UI.Page.DeterminePostBackMode
On Wed, 16 Jan 2008 06:33:39 -0800, Vladimir Krasnov [EMAIL PROTECTED] scribbled: Hello, Hello Vladimir, This is performance optimization patch, which fixes common flow when no query string in request, please review. Please commit, looks good. Thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] asp.net 1.2.5 and 1.2.6
On Fri, 11 Jan 2008 17:03:33 +0530, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] scribbled: There are one more problem, when I upload this site to hosting server (which runs on MS .net 2.0 ) I get some error in web.config, which I fixed, then there is some other problem occurs. Look at http://manageserver1.info/mfnav/ That means you haven't uploaded/compiled the bin/ directory in your project. The excerpt shown above says that the ASP.NET compiler cannot load the specified base type. Note: I have uploaded original code which work fine with mono 1.2.5 on loca machine. It would work only if you had the correct assembly in bin/. If you want ASP.NEt to compile the code on demand, add the Src=codebehind.cs or CodeFile=codebehind.cs (if your project is a 2.0 one) attribute to the page directive. In the latter case, your code-behind base type must be a partial class. marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] asp.net 1.2.5 and 1.2.6
On Fri, 11 Jan 2008 17:45:02 +0530, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] scribbled: On Jan 11, 2008 5:18 PM, Marek Habersack [EMAIL PROTECTED] wrote: On Fri, 11 Jan 2008 17:03:33 +0530, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] scribbled: There are one more problem, when I upload this site to hosting server (which runs on MS .net 2.0 ) I get some error in web.config, which I fixed, then there is some other problem occurs. Look at http://manageserver1.info/mfnav/ That means you haven't uploaded/compiled the bin/ directory in your project. The excerpt shown above says that the ASP.NET compiler cannot load the specified base type. Note: I have uploaded original code which work fine with mono 1.2.5 on loca machine. It would work only if you had the correct assembly in bin/. If you want ASP.NEt to compile the code on demand, add the Src=codebehind.cs or CodeFile=codebehind.cs (if your project is a 2.0 one) attribute to the page directive. In the latter case, your code-behind base type must be a partial class. If this CodeFile=codebehind.cs is missing why it is working on xsp2? I can only guess, since I can't see the directory you run xsp2 in. You probably have the assembly compiled in there in the bin/ directory, or you have the code in the App_Code directory, or the assemby with the base type is in your gac. marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] System.Web - validators
On Sun, 6 Jan 2008 01:06:04 -0800, Igor Zelmanovich [EMAIL PROTECTED] scribbled: Hi there, Hey Igor, Attached is the patch makes validators work within UpdatePanel. It introduce new internal interface IScriptManager. If page contents instance of IScriptManager, validators call it's API instead Page.ClientScript. ScriptManager implement IScriptManager, that allows it to manage client script of validators as well. Please review and approve the patch. Great stuff! Please commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] shadow copy problem
On Mon, 07 Jan 2008 01:14:53 +0200, Anton Andreev [EMAIL PROTECTED] scribbled: Hi, Hey, I have this problem now with XSP: //Failed to create shadow copy (CopyFile).// Any ideas what I should do next? A small test case triggerring the problem would be great - please attach it to the bug report about that issue, thanks! marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] System.Web.UI.Page.cs
On Thu, 20 Dec 2007 04:08:02 -0800, Igor Zelmanovich [EMAIL PROTECTED] scribbled: Attached patch is refactoring only. It splits method such InternalProcessRequest to several methods. It is required for implementing alternative hosting under TARGET_J2EE. Please review. Please commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is it possible to run ASP.NET from a CD?
On Wed, 19 Dec 2007 10:18:36 -0500, Joe Audette [EMAIL PROTECTED] scribbled: Hi All, Hey Joe, Was wondering if its theoretically possible to run xsp2 directly from a cd. I've seen some posts about embedding mono but don't really know what is involved. If anyone can confirm whether its possible or point me to any information that might help I'd appreciate it. What I'm thinking about is being able to run mojoportal directly from a cd probably with SQLite. Obviously it would be read only but I can see if it could be done it would be great for making demos and also maybe I could make a utility to import export from other db platforms so a site could be backed up and archived to cd in a way that you can see the site as it was at the time of backup. Is this possible? It is doable and doesn't need to be read-only (to an extent). Your live CD system would need to have a writable tmpfs mounted on the temp directory (that is, usually on /tmp), so that ASP.NET can generate and compile assemblies on the fly. Additionally, the user you would be running xsp under would need their home directory writable, so that the .wapi directory can be created and written to. You could create a user whose home would be set to /tmp, and reuse the same tmpfs for both purposes. Other than those two requirements - it should work. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.Web.Compilation.AppSettingsExpressionBuilder
On Tue, 18 Dec 2007 01:23:01 -0800, Vladimir Krasnov [EMAIL PROTECTED] scribbled: Hello, Hello Vladimir, Please review and approve attached patch for AppSettingsExpressionBuilder.GetAppSetting method, It fixes value conversion to the type of property parameter. Please go ahead with the commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.Web.UI.ListControl
On Mon, 17 Dec 2007 05:46:15 -0800, Vladimir Krasnov [EMAIL PROTECTED] scribbled: Hello, Hello, Please review and approve attached patch for System.Web.UI.ListControl that fixes the following problems in viewstate management of ListItem and ListItemCollection: 1. Setting ListItem.Selected to true cause viewstate generation for selected indeces even if not tracked 2. Modifying ListItem directly without touching the collection causes failure at items restore Look at attached tests for more details Please commit, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mod_mono issues on 1.2.6
On Mon, 17 Dec 2007 12:09:53 -0500, Joe Audette [EMAIL PROTECTED]
scribbled:
Hi All,
Hey Joe,
[snip]
First issue encountered was an invalid param exception thrown from
mscorelib on the setup page. The line of code throwing the exception
is testing for writability in the Data subfolder beneath the site
root.
The code that threw the exception is:
public static void TouchTestFile(String pathToFile)
{
if (pathToFile != null)
{
if (File.Exists(pathToFile))
{
// exception thrown here from mscorelib
File.SetLastWriteTimeUtc(pathToFile, DateTime.Now);
}
else
{
StreamWriter streamWriter = File.CreateText(pathToFile);
streamWriter.Close();
}
}
}
By deleting the files I was able to get past this as it hit the else clause.
As far as System.Web goes, it doesn't really matter whether it runs under
xsp or mod_mono - the latter is just a proxy and the backend code is the same
in both cases. What is different, though, is the environment created and
exposed to mod_mono by Apache - file permissions, chroot/no chroot, environment
variables, umask etc. Those factors may affect the behavior of the code running
in an application but they not always might be symptoms of a bug in Mono. In
this particular case it might be a matter of file permissions.
Next error was it could not connect to the database. The cause of this
error is that under mod_mono its not picking up my user.config file
which has the correct connection string. It works fine from the
command line with xsp2.
My connection string is from appSettings section defined in Web.config
to use user.config for overrides like this:
appSettings file=user.config
...
/appSettings
under mod_mono its not picking up my overrides in user.config as it should
Can you attach to the mod-mono-server2 backend process with strace before you
access the website for the first time and see whether it finds the include file
at all? You are using a relative path, and the file is read without mapping it
to the current appdomain's base directory, so if the current working directory
is different to the one where your user.config files, the file will be silently
ignored (see
class/System.Configuration/System.Configuration/AppSettingsSection.cs:73). If
the CWD is indeed different to the app's root directory then it might be a Mono
bug. The only question would be if it is a bug in System.Web/Mono.WebServer
which fails to set the cwd to the appdomain's root, or a bug in the appdomain
setup code in corlib which fails to do the same.
so I put the correct connection string directly in Web.config and was
able to get past the db connection problem
Then I'm back to the same problem about setting the write time of
files but this time with cache files. Stack trace below:
System.IO.IOException: Invalid parameter
at System.IO.File.SetLastWriteTime (System.String path, DateTime
last_write_time) [0x0]
at System.IO.File.SetLastWriteTimeUtc (System.String path, DateTime
last_write_time) [0x0]
at mojoPortal.Business.WebHelpers.CacheHelper.TouchCacheFile
(System.String pathToCacheFile) [0x0]
at mojoPortal.Business.WebHelpers.CacheHelper.TouchMenuCacheDependencyFile
() [0x0]
at mojoPortal.Business.WebHelpers.CacheHelper.GetMenuPagesFromCache
() [0x0]
at mojoPortal.Business.WebHelpers.CacheHelper.GetMenuPagesFromContext
() [0x0]
at mojoPortal.Business.WebHelpers.CacheHelper.GetMenuPages () [0x0]
at mojoPortal.Web.mojoSiteMapProvider.BuildSiteMap () [0x0]
at mojoPortal.Web.mojoSiteMapProvider.GetRootNodeCore () [0x0]
at System.Web.SiteMapProvider.get_RootNode () [0x0]
at System.Web.UI.WebControls.SiteMapDataSource.GetStartNode
(System.String viewPath) [0x0]
at System.Web.UI.WebControls.SiteMapDataSource.GetHierarchicalView
(System.String viewPath) [0x0]
at
System.Web.UI.HierarchicalDataSourceControl.System.Web.UI.IHierarchicalDataSource.GetHierarchicalView
(System.String viewPath) [0x0] at
System.Web.UI.WebControls.HierarchicalDataBoundControl.GetData (System.String
viewPath) [0x0] at System.Web.UI.WebControls.TreeView.PerformDataBinding
() [0x0] at
System.Web.UI.WebControls.HierarchicalDataBoundControl.PerformSelect ()
[0x0] at System.Web.UI.WebControls.BaseDataBoundControl.DataBind ()
[0x0] at System.Web.UI.WebControls.TreeView.DataBind () [0x0]
at mojoPortal.Web.UI.SiteMenu.RenderTreeView () [0x0]
at mojoPortal.Web.UI.SiteMenu.PopulateControls () [0x0]
at mojoPortal.Web.UI.SiteMenu.Page_Load (System.Object sender,
System.EventArgs e) [0x0]
at System.Web.UI.Control.OnLoad (System.EventArgs e) [0x0]
at System.Web.UI.Control.LoadRecursive () [0x0]
at
Re: [Mono-dev] [Patch] System.Web.HttpServerUtility
On Wed, 12 Dec 2007 07:45:12 -0800, Igor Zelmanovich [EMAIL PROTECTED] scribbled: HttpServerUtility.patch Hi there, Hey Igor, Attached is the patch fixes several bugs in Transfer/Execute functionality such: When Transfer/Execute is called with preserveForm=true, transferred page is not processed as PostBack but form collection is preserved. When Execute is called more than once, PreviousPage property is set correct. Please review and approve the patch. The patch looks good - please commit (along with the test cases you provided), thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] some questions abt xsp2
On Wed, 21 Nov 2007 23:37:46 +0530, Sharique uddin Ahmed Farooqui [EMAIL PROTECTED] scribbled: Hello, xsp2 is a really nice small web server . I like it for its ease of use. For me it just works. configuring mod_mono is quite tedious task.xsp2 is more useful in intranet scenarios. I have few questions abt xsp2 - Should I choose xsp2 over mod_mono? atleast for asp.net site. If no then Why? You should choose Apache over xsp. The reason is that xsp, as you've yourself noted above, is a small, simple server. All it does (when used as a frontend server) is to support the smallest possible subset of the HTTP 1.0 protocol, enough to pass data from the ASP.NET runtime to the browser. It doesn't support load balancing, chunking, HTTP 1.1, virtual hosts and much more. - what are the plans for xsp2 ? Well, it stays around and gets improved - if that's what you ask :) - did fastcgi is supported on xsp2 ? It is with 1.2.6 release. - Any plan integrate it with Monodevelop like MS has does in VS? That's a question for the MonoDevelop hackers, but I guess it would be as easy as spawning the server from within the IDE (it could also be linked into the IDE, since bulk of the server is a class library that implements the necessary functionality) best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Regression in AssemblyResourceLoader.GetResourceUrl
On Fri, 02 Nov 2007 10:51:17 +0100, Juraj Skripsky [EMAIL PROTECTED] scribbled: Hi Marek, Hey Juraj, The attached patch fixes a regression introduced with your last change to AssemblyResourceLoader.cs. As the assembly name is encrypted via EncryptAssemblyResource, we mustn't UrlEncode it anymore. May I commit? Please do, thanks! best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mojoPortal broken using latest Mono from svn
On Sat, 20 Oct 2007 13:58:08 -0400, Joe Audette [EMAIL PROTECTED] scribbled: Hi Guys, Hello Joe, [snip] System.IO.FileNotFoundException: Could not load file or assembly 'App_GlobalResources' or one of its dependencies. The system cannot find the file specified. File name: 'App_GlobalResources' at (wrapper managed-to-native) System.AppDomain:LoadAssembly (string,System.Security.Policy.Evidence,bool) at System.AppDomain.Load (System.String assemblyString) [0x0] at (wrapper remoting-invoke-with-check) System.AppDomain:Load (string) at System.Reflection.Assembly.Load (System.String assemblyString) [0x0] at Resources.Resource.get_ResourceManager () [0x0] at Resources.Resource.get_ApplicationStartEventMessage () [0x0] at mojoPortal.Web.Global.Application_Start (System.Object sender, System.EventArgs e) [0x0] at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] [snip] So somewhere in that range of revisions something has gone wrong and mojoPortal no longer works on Mono. The regression was related to the recent changes in the satellite assembly handling in System.Web.Compilation (Application resources compiler would write a preservation file for every satellite assembly, thus overwriting the .compiled file for the main assembly - as a result, assembly resolution handler in HttpRuntime wasn't able to find the actual main assembly). It's been fixed in svn revision 87964. regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Bugs in StaticSiteMapProvider.cs
On Wed, 17 Oct 2007 11:18:21 +0200, Juraj Skripsky [EMAIL PROTECTED] scribbled: Hi Marek, Hey Juraj, The attached patch fixes a few issues with StaticSiteMapProvider: - AddNode doesn't check for key dups before adding items to hashtables - RemoveNode doesn't remove item from keyToNode - full urls (e.g. http://www.google.com) are not supported And it cleans up a few dirty spots. May I commit? Can you use the generic Dictionary instead of Hashtable? it will make the code faster. Otherwise, if no tests fail - do commit. Thanks! regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] error compiling mod_mono 1.2.5 with apache 1.3
On Thu, 27 Sep 2007 10:24:35 +0200, César González [EMAIL PROTECTED] scribbled: Hello, [snip] First i tried to compile mod_mono 1.2.5 against lastest etch debian packages of apache : ii apache-dev 1.3.34-4.1 development kit for the Apache webserver ii libapr1-dev1.2.7-8.2 The Apache Portable Runtime Library - Development Headers I got these first error : mod_mono.h:58:19: error: unixd.h: No such file or directory If i comment these include line i got : [snip] I've just committed (r86462) a few changes to mod_mono which make it compile with apache 1.3 and without apr. Note, however, that the recently added features (dashboard accounting/synchronization, auto-restart support) won't work with apache 1.3 (they require apr and the 1.3 version of the module is not written to support it). If you need the features, I suggest moving to apache2. regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] error compiling mod_mono 1.2.5 with apache 1.3
On Wed, 26 Sep 2007 11:33:33 +0200, César González [EMAIL PROTECTED] scribbled: Hi Marek, Marek Habersack escribió: What is the version of apr 1.3 uses? 0.9.x? On debian, apache-dev (version 1.3.34) depends on apache2-common, wich depends on libapr1-dev (1.2.7). In which case the compile should work, since it's the new APR. Anyway, I have tested mod_mono 1.2.5 with apr 0.9 and change mod_mono.h to not to include unixd.h (apache 2 file). The error with these changes is the following : mod_mono.c:99: error: expected specifier-qualifier-list before 'apr_shm_t' mod_mono.c:121: error: expected specifier-qualifier-list before 'apr_lockmech_e' mod_mono.c:128: error: 'APR_LOCK_FCNTL' undeclared here (not in a function) Seems that mod_mono is not compatible with the old api 0.9. This is weird, though. I've just downloaded the apr 0.9.16 tarball and it contains the apr_shm.h include file, which defines apr_shm_t and apr_proc_mutex.h which contains APR_LOCK_FCNTL. Can you tell me the exact (Debian) version of all the packages you tested it with? I will download them and see what's inside (I'm installing etch right now, too) best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
