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-list] Is Mono dead?
On 2012-04-20 13:46, monoton wrote:
Hi,
Hi
no update to Mono since ages! Version 2.12 is overdue looong time. What's
up?
grendel@higgs:~/vc/mono/mono (master)$ git log --shortstat --since 1 month ago | grep files changed | awk
'{files+=$1; inserted+=$4; deleted+=$6} END {print files changed, files, lines inserted:, inserted, lines
deleted:, deleted}'
files changed 1675 lines inserted: 59198 lines deleted: 10672
Far from dead :)
marek
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
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-aspnet-list] issues with intermittent apache hangups
On Wed, 13 Apr 2011 06:42:05 -0700 (PDT) Dan parn...@gmail.com wrote: Marek, Hey Dan, Thanks for all your help so far. You're welcome I've applied the patch (0eff07d0fc4ef1ef3c584e71a8dd54ab708543e8) both on my development machine (to run further mprof tests) and on our test server. The local tests still show many thousands of cache items being generated, although I believe at a slightly slower rate. From your previous mails it seems that you generate lots and lots of session entries, so the rate at which they appear is not dependent on Mono. What happens now is that we don't create the excess entries for session items whose timeouts got reset. Note also that each session entry, not only one with a timeout, will have an associated CacheItem instance. CacheItems are cleared whenever they are removed from the cache, so their memory overhead is very small after they are no longer valid. But the responsibility to remove non-timed entries relies upon the application (or System.Web code in certain cases) - System.Web cannot do anything about them. Could you count the total number of Session items your application creates, what percentage of them are timed ones, log what are the keys of all of the entries and send that data to me off-list? The test server has also been set running again for the past couple of days, although I think the app got restarted at some point (probably killed by the system when it started demanding too much memory). Just watching it for the past two hours it has gone from 19.7% to 26.8% memory usage (1GB of memory Does running with sgen help? available in this old test machine), and is still creeping up. This problem will cause us major issues in a production kiosk system, since it will reach the point where the web app response slows to a halt and then eventually gets killed by the os and restarted by apache. Have you considered rolling your own session state module? Based e.g. on memcached? Unless this can be resolved properly, we may have to resort to setting up a cron job that will automatically force the web server to restart on a regular basis, but we really do not want to have to do that! Well, to resolve it properly we need to know what the problem is :) Let's see what we can read from the data I asked you to collect above. best, marek Regards, Dan Marek Habersack wrote: On Tue, 5 Apr 2011 15:24:25 -0500 (CDT) Dan lt;parn...@gmail.comgt; wrote: Hey Dan, The issue here was the way the in-proc session handler handled item timeout reset. It would first remove the item from the cache (it uses an internal instance of the Cache class) and then insert it back in the cache. With a big number of items, that would grow the timed items priority queue heap much more than was necessary and generate a lot of duplicate internal cache items. The effects would be different depending on the application's usage of session data. I've just committed a possible fix for the issue to Mono's master branch (I haven't committed it to the mono-2-10 branch since it is a potentially breaking change which needs to be tested in real life first) in commit 0eff07d0fc4ef1ef3c584e71a8dd54ab708543e8 (tests have been committed in c00c5d00fddf18969c9869492f7e1235d960076b if you're interested). The fix applies cleanly to the 2.10 branch, so please apply it and test with your application to see whether it fixed the issue. Please let me know about the results, thanks :) marek -- View this message in context: http://mono.1490590.n4.nabble.com/issues-with-intermittent-apache-hangups-tp3264509p3447198.html Sent from the Mono - ASP.NET mailing list archive at Nabble.com. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] MVC 3 - Error on first site hit
On Fri, 8 Apr 2011 09:15:52 -0400 Jeff Zellner j...@odyl.net wrote: I ran into this problem running MVC3 on 2.10.1 as well. This can be fixed by ensuring the location of your registry ($PREFIX/etc/mono/registry I believe) is writable by the mono process. (Though it sounds like I should try out Marek's suggestion as well) Well, my suggestion is a must-follow one :) The .NET assembly will just not work with Mono's System.Web :) marek -Jeff On Fri, Apr 8, 2011 at 9:01 AM, Marek Habersack gren...@twistedcode.net wrote: On Fri, 8 Apr 2011 12:54:02 + Daniel J. Summers daniel.summers.2...@gmail.com wrote: I've successfully gotten ASP MVC 3 running with Mono 2.10, using the bin deploy technique described at http://www.hanselman.com/blog/default.aspx?page=11 (as I write this, the post is at the top of the page; the permalink seems to be broken). Once the app is restarted, the first hit returns an error. After that, it flies! :) [snip] Any ideas? You must not use the .NET version of Microsoft.Web.Infrastructure on Mono. Remove it from bin/ and rely upon what is in Mono's GAC. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] ASP.NET MVC 3 under Windows with MonoDevelop
On Fri, 8 Apr 2011 18:30:21 +0200 Tanguy Krotoff tkrot...@gmail.com wrote: Hi all, Hey, I've managed to execute the ASP.NET MVC template that you provide with MonoDevelop under Windows using ASP.NET MVC 3. Here the steps: * Install Mono (tested with 2.10.1), MonoDevelop (tested with 2.6 beta 1) and friends * Install ASP.NET MVC 3 from Microsoft http://www.asp.net/mvc/mvc3 * Create a new solution ASP.NET MVC Project inside MonoDevelop * Inside this new project, change runtime version to Mono / .NET 4.0 instead of the default one which is Mono / .NET 3.5 * Copy-paste into the bin directory of the MVC project the following dlls given with Microsoft ASP.NET MVC 3 (check C:\Program Files\Microsoft ASP.NET) Microsoft.Web.Infrastructure.dll This is incorrect - you must not use the .NET M.W.I assembly with Mono, it won't work (see http://twistedcode.net/blog/post/2011/01/17/Mono-and-ASPNET-MVC-v3.aspx) marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] issues with intermittent apache hangups
On Tue, 29 Mar 2011 11:32:11 -0400 Gonzalo Paniagua Javier gonzalo.m...@gmail.com wrote: On Tue, 2011-03-29 at 03:42 -0700, Dan wrote: Do you happen to know which commit potentially fixes this issue, so that we could take a look. I'll let Marek fill in the details. The CacheItemPriorityQueue in 2.10.1 is the same as in master. Frankly, looking at the code I can't see how it would behave like that (unless the post-decrement operator behaves as pre-decrement one, that is...). Certainly, the bug is happening, but alas I would need to see some test case to be able to fix the issue. So, if anyone experiencing it can come up with one, please file a bug on bugzilla. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] ASP.NET MVC 3 on Mono 2.8.1
On Sat, 15 Jan 2011 09:03:53 -0800 (PST)
adrin adri...@gmail.com wrote:
After a long Console.WriteLine() debugging session I've found a possible
reason for these problems.
It seems that ASP.NET MVC 3 uses BuildManager.GetObjectFactory(virtualPath,
false) != null condition to check if given view file exists.
Mono 2.8 implementation of BuildManager.GetObjectFactory() (System.Web 4.0)
method looks like this:
[MonoTODO(A no-op until we use IWebObjectFactory internally. Always returns
null.)]
public static IWebObjectFactory GetObjectFactory(string virtualPath, bool
throwIfNotFound)
{
return null;
}
Are there any plans to add ASP.NET MVC 3 support to mono anytime soon?
I'm working on it. The issue is a bit more complicated with this MVC release as
it relies upon
several assemblies which aren't open source (don't even come with source) so I
need to first
implement at least parts of them. Please file a bug for the Sys.Web component
and attach your
sample application as the test case - it will help in solving the issues,
thanks.
marek
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-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-list] does asp.net detect changed files?
On Thu, 25 Nov 2010 00:33:53 +0800 Foo jhfoo...@extracktor.com wrote: Hi guys, can anyone confirm if mono's implementation of asp.net can and will detect modified .aspx files, and automatically recompile the affected page? Yes ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] does asp.net detect changed files?
On Wed, 24 Nov 2010 13:01:52 -0500 Abe Gillespie abe.gilles...@gmail.com wrote: I can attest from personal experience this works fairly well. However, sometimes with newly dropped assemblies I'll get an Internal Server Error from Apache. But usually a subsequent request / refresh You will get it if the event comes in the middle of a request. The request is aborted, mod_mono fails to communicate with the backend and sends error 500. marek will fix it. It will just recompile the application at the next request. marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono 2.8 .net 4.0 MembershipProvider not found
On Sat, 6 Nov 2010 06:39:12 -0700 (PDT) Gunnar Sønsteby gunnar.sonst...@netcom.no wrote: Hi, Hey, I am trying to write a custom membershipprovider for Postgres. public sealed class MyMembershipProvider : MembershipProvider This compiles using Mono .net 3.5 Switching to .net 4.0 I get the error message MembershipProvider type or namespace not found. Anything I have forgotten to do? You must reference System.Web.ApplicationServices marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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-aspnet-list] All pages recompile after apache restart
On Wed, 28 Jul 2010 13:09:04 -0700 (PDT) dugc dug...@dolce.co.uk wrote: Hey, Hi All, This is probably an obvious one, but bear with me. I recently upgraded the mono installation on my server from 1.1 to 2.4 (on Ubuntu 10.04). Previously, pages would take 10 seconds to compile the first time they were accessed and thereafter would appear instantly, even after mono/apache/system restarts. Since the upgrade, I can access a page (wait while it compiles) reaccess it (it is now instant) restart apache, and it is then it seems to need to compile again. This is slowing everything down a great deal, as the server restarts nightly. Any ideas how to avoid this behavior? I have set debug=false as I thought that this might help, but to no avail. http://msdn.microsoft.com/en-us/library/s10awwz0.aspx - you need to set batch=false marek Thanks, Dugald ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] MVC 2 Precent-Colon Syntax
On Wed, 28 Jul 2010 18:23:00 -0400 Abe Gillespie abe.gilles...@gmail.com wrote: IIRC 2.6.7 shipped with MVC 2 support. Do we have to do something special to turn on the %: syntax? Or is that not supported yet? It's supported only in the .NET 4.0 profile, on master marek Thanks. -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MVC 2 Precent-Colon Syntax
On Wed, 28 Jul 2010 18:34:00 -0400 Abe Gillespie abe.gilles...@gmail.com wrote: I'm not sure what this means. Is that a branch in the source that wasn't shipped with 2.6.7? Is that a switch or environment variable that I can set? It means that it's going to be available when the current master branch is released as Mono 2.8 - support for %: % is a .NET 4.0 thing and is not backported to the 2.6 branch. marek Thanks. -Abe On Wed, Jul 28, 2010 at 6:30 PM, Marek Habersack gren...@twistedcode.net wrote: On Wed, 28 Jul 2010 18:23:00 -0400 Abe Gillespie abe.gilles...@gmail.com wrote: IIRC 2.6.7 shipped with MVC 2 support. Do we have to do something special to turn on the %: syntax? Or is that not supported yet? It's supported only in the .NET 4.0 profile, on master marek Thanks. -Abe ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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-list] Bug with non-secured resources in ASP.NET
On Wed, 10 Mar 2010 19:11:50 -0500 Abe Gillespie abe.gilles...@gmail.com wrote: Hello, I replaced my System.Web source directory with the latest. Unfortunately this did not fix the problem. After being offline for four days I just decided to roll back to 2.4. At least I'm working again. I'll retry the next official 2.6 release. File a bug and attach a standalone, self-contained test case which reproduces the issue. best, marek Thanks. -Abe On Tue, Mar 9, 2010 at 11:46 AM, Abe Gillespie abe.gilles...@gmail.com wrote: Cool. Thanks, Marek. I'll get the new System.Web source and recompile. I appreciate the help on this! -Abe On Tue, Mar 9, 2010 at 11:09 AM, Marek Habersack gren...@twistedcode.net wrote: On Tue, 9 Mar 2010 09:40:42 -0500 Abe Gillespie abe.gilles...@gmail.com wrote: Any word on this? It's really hurting my business right now. It should be fixed in trunk and the 2.6 branch, try System.Web from there marek Thanks! -Abe On Fri, Mar 5, 2010 at 4:05 PM, Abe Gillespie abe.gilles...@gmail.com wrote: This seems to be new since somewhere around 2.4.x. I my Web.config I've got resources protected and others globally available a la: system.web customErrors mode=Off/ authorization deny users=?/ /authorization authentication mode=Forms forms name=.ASPXAUTH loginUrl=~/login.aspx/ /authentication /system.web location path=callback.aspx system.web authorization allow users=*/ /authorization /system.web /location location path=common system.web authorization allow users=*/ /authorization /system.web /location Mono grants public access to files (like images and css files) in the common directory as expected. However, callback.aspx is forwarding the page to the login page which is not expected. This one's critical for me in that the callback.aspx page is the end point for Google Checkout. Now that it's erroneously forwarding to the login page Google Checkout is unable to send checkout events to my system thus preventing online sales. I'll be happy to file a bug but was hoping there was a quick work-around in the mean time just so that I can get functioning again. Again, this has been working all along in Mono up until at least 2.4.x. Thanks. -Abe ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Bug with non-secured resources in ASP.NET
On Tue, 9 Mar 2010 09:40:42 -0500 Abe Gillespie abe.gilles...@gmail.com wrote: Any word on this? It's really hurting my business right now. It should be fixed in trunk and the 2.6 branch, try System.Web from there marek Thanks! -Abe On Fri, Mar 5, 2010 at 4:05 PM, Abe Gillespie abe.gilles...@gmail.com wrote: This seems to be new since somewhere around 2.4.x. I my Web.config I've got resources protected and others globally available a la: system.web customErrors mode=Off/ authorization deny users=?/ /authorization authentication mode=Forms forms name=.ASPXAUTH loginUrl=~/login.aspx/ /authentication /system.web location path=callback.aspx system.web authorization allow users=*/ /authorization /system.web /location location path=common system.web authorization allow users=*/ /authorization /system.web /location Mono grants public access to files (like images and css files) in the common directory as expected. However, callback.aspx is forwarding the page to the login page which is not expected. This one's critical for me in that the callback.aspx page is the end point for Google Checkout. Now that it's erroneously forwarding to the login page Google Checkout is unable to send checkout events to my system thus preventing online sales. I'll be happy to file a bug but was hoping there was a quick work-around in the mean time just so that I can get functioning again. Again, this has been working all along in Mono up until at least 2.4.x. Thanks. -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] XSP issue
On Mon, 8 Mar 2010 10:22:10 -0600 Dan Winslow dwins...@aiminstitute.org wrote: Hello, It's fixed in r153272, best regards, marek Hi Folks. Compiled XSP from sources. Cd'd into the 'test' directory. Started xsp, it said : xsp2 Listening on address: 0.0.0.0 Root directory: /root/mono-2.6.1/xsp-2.6/test Listening on port: 8080 (non-secure) Hit Return to stop the server. Then browsed to 8080 on that IP ( from another computer, i.e. wasn't localhost:8080 ) and got Could not load file or assembly 'SiteMapReader_1.1' or one of its dependencies. The system cannot find the file specified. Description: HTTP 500. Error processing request. Stack Trace: System.IO.FileNotFoundException: Could not load file or assembly 'SiteMapReader_1.1' or one of its dependencies. The system cannot find the file specified. File name: 'SiteMapReader_1.1' at System.AppDomain.Load (System.String assemblyString, System.Security.Policy.Evidence assemblySecurity, Boolean refonly) [0x0] in filename unknown:0 at System.AppDomain.Load (System.String assemblyString) [0x0] in filename unknown:0 at (wrapper remoting-invoke-with-check) System.AppDomain:Load (string) at System.Reflection.Assembly.Load (System.String assemblyString) [0x0] in filename unknown:0 at System.Web.UI.TemplateParser.AddAssemblyByName (System.String name) [0x0] in filename unknown:0 The SiteMap dll appears to be built and available at that root. Just looking for a hint. Dan Winslow Director of Information Technology, AIM INSTITUTE 1905 Harney Street, Suite 700 Omaha, NE 68102 402-345-5025 x156 dwins...@aiminstitute.org www.aiminstitute.org ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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-list] Problem with System.Web.Mvc
On Wed, 10 Feb 2010 12:21:37 -0500 Abe Gillespie abe.gilles...@gmail.com wrote: Hello, Using .Net Reflector I noticed there are compiled-in resources for System.Web.Mvc.dll on Win/MS .Net. However, these resources are not present for Mono included System.Web.Mvc.dll. On mono you can use monodis --presources assembly.dll to list the embedded resources This site runs on Windows / MS .Net and Mac OS X / Mono. It's just my Linux box that's having this problem. Mind you, my Mac is running 2.6 where the Linux box is running 2.6.1. It's fixed in r151926 (trunk) and in r151927 (2.6 branch) best regards, marek -Abe On Wed, Feb 10, 2010 at 12:07 PM, Juan C. Olivares juan...@juancri.com wrote: On Wed, Feb 10, 2010 at 1:08 PM, Abe Gillespie abe.gilles...@gmail.com wrote: Here's the stack trace if that helps: System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure System.Web.Mvc.Resources.MvcResources.resources was correctly embedded or linked into assembly System.Web.Mvc at compile time, or that all the satellite assemblies required are loadable and fully signed. I have had this problem. There's a problem with the resources, but that will not fix the real problem. The MVC is trying to display other error related with the application. Sometimes, it's because the action doesn't exist. Try to test this app on .NET and check the controller and action. -- Atte, Juan Cristóbal Olivares חואנכרי == Renovarse o morir: Mi PC de los sesenta tenía veinte mil militantes. Y mi PC del siglo XXI tiene cuarenta gigabytes. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] System.InvalidCastException with ScriptManager
On Tue, 16 Feb 2010 01:16:08 -0800 (PST) ornitorrinc ornitorr...@gmail.com wrote: Hello everybody, Hello, I am attempting to create a small test site using Mono and AJAX to test ExtJS_Extender_Controls, with: - Mono 2.6.1 - VS 2008 - Mono Tools 1.0 - ExtJs Extender Controls 3.3.0 [snip] The problem is that assembly version redirection doesn't seem to work correctly in the runtime. I filed a bug describing the issue at https://bugzilla.novell.com/show_bug.cgi?id=580185. To make your application work for the time being, just recompile the Bin/ExtExtenders.dll assembly with System.Web.Extensions v3.5.0.0 marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-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-aspnet-list] Global.asax isn't working
On Mon, 8 Feb 2010 01:41:20 -0800 (PST)
eSPiYa vdol...@gmail.com wrote:
Hello,
I'm building a web service project with static variables but it seems
Application_Start doesn't fire if I run my test project on XSP2 using Mono
2.6.1 on MS WinXP.
Please file a bug with a _full_ sample source, not just your global
code-behind, thanks
(http://mono-project.com/Bugs, the System.Web component)
marek
Here is my sample code:
public class Global : System.Web.HttpApplication
{
public static Random rand;
protected virtual void Application_Start (Object sender,
EventArgs e)
{
rand = new Random();
}
protected virtual void Session_Start (Object sender, EventArgs
e)
{
rand = null;
}
}
This sample works fine with IIS and .NET2.0.
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] error CS1679: Invalid extern alias for /reference [...] makes me afraid
On Wed, 03 Feb 2010 23:33:43 +0100
Christian Herzog cher...@web.de wrote:
Guys, once again - give me a test case and I'll fix the issue.
marek
I have the same error.
While testing a while I found out that it seems to be a problem with the
App_Code-Folder.
For me, it is not possible to create a file there without getting the
error. (Btw: Even an empty file will end with the error.)
It is possible to compile the file with gmcs (gmcs -target:library
DB.cs) without errors. The file:
using System;
using System.Data;
public class DB
{
public DB()
{
//CheckDB();
}
}
So I don't think the problem is due to the code.
I develop with Visual Studio Web Developer via FTP on a Debian Etch
System (Mono-Version from the Backports).
error CS1679: Invalid extern alias for /reference. Alias ' Version'
is not a
valid identifier
Not without seeing some source - please create a small test case, and
open a bug report
(http://mono-project.com/Bugs, file for the System.Web component) with
the test case attached.
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
___
Mono-aspnet-list mailing list
Mono-aspnet-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] Telerik Radgrid's Pager not working with Mono ASP.NET
On Mon, 21 Dec 2009 08:32:21 + (GMT) Ferdinand Funke dr_doom1...@yahoo.de wrote: Hello, Von: Marek Habersack gren...@twistedcode.net Betreff: Re: [Mono-aspnet-list] Telerik Radgrid's Pager not working with Mono ASP.NET An: Ferdinand Funke dr_doom1...@yahoo.de CC: mono-aspnet-list@lists.ximian.com Datum: Freitag, 18. Dezember 2009, 13:53 On Fri, 18 Dec 2009 12:32:50 + (GMT) Ferdinand Funke dr_doom1...@yahoo.de wrote: Hello list. Hello, I am implementing a project using the Telerik RadGrid. In my grid I have paging enabled. The page itself has a rather simple setup: just the grid with an SqlDatasource bound to it. The problem is that under Mono ASP.NET the grid's pager is not shown while the pager works correctly unter MS.NET. After some debugging I found out that the grid does not seem to have the correct number of all elements in the datasource. As I could see from the code the grid's Count property is set by the value of a property in the framework. But as a matter of fact I do not know what to do next. And I am not quite sure if the error is lieing in the Mono fraemwork or the Telerik components. Is there anybody out there who has experienced this error before or who has an idea what to do next? The error occured with Mono 2.4.2.3 and Mono 2.6 and Telerik Components Q2/2009. Please file a bug report (http://www.mono-project.com/Bugs, the System.Web component) and attach to it a self-contained test case (no need to attach Telerik assemblies). It is most likely a bug in Mono introduced after we tested Telerik controls. best regards, marek Thanks in advance Ferdinand __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list Hi Marek, thanks for the answer. After some communication with Telerik I now know that their 2.0 controls have to be used. If the 3.5 Telerik controls are also intended to work with mono just tell me and I file a bug report. If not consider the problem solved. Indeed, you have to use the 2.0 controls at this point. best, marek Best regards Ferdinand __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
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-list] Mono and NPGSQL problems, help please!!
MNEU wrote: Hi! Hello I'm using mono in Windows environment (using npgsql), when i run the proyect with MS compiler i have no errors and work fine. But when i use the mono compiler i get this error: ** (C:\Program Files\Mono-2.4.2.3\lib\mono\2.0\winhack\xsp2.exe:4188): WARNING **: Missing method Mono.WebServer.XSPWebSource::.ctor(IPAddress,int,SecurityProtocolType,X509Certificate,PrivateKeySelectionCallback,bool,bool,bool) in assembly C:\Program Files\Mono-2.4.2.3\lib\mono\gac\Mono.WebServer2\0.2.0.0__0738eb9f132ed756\Mono.WebServer2.dll, referenced in assembly C:\Program Files\Mono-2.4.2.3\lib\mono\gac\xsp2\2.4.2.0__0738eb9f132ed756\xsp2.exe I have the Mono.Security.dll referenced and in the same directory. Remove it and it will work marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and NPGSQL problems, help please!!
Martín Neu wrote: Hi Marek! Hey, I can't remove it becouse i need the npgsql library to connect my application to PostgreSQL. Yes, you can remove it. Mono has its own copy of Mono.Security and the one distributed with Npgsql (for the benefit of .NET), that is the one you're most likely using, is too old for your Mono. marek Any other idea? Thanks! On Mon, Nov 16, 2009 at 10:32 AM, Marek Habersack gren...@twistedcode.net mailto:gren...@twistedcode.net wrote: MNEU wrote: Hi! Hello I'm using mono in Windows environment (using npgsql), when i run the proyect with MS compiler i have no errors and work fine. But when i use the mono compiler i get this error: ** (C:\Program Files\Mono-2.4.2.3\lib\mono\2.0\winhack\xsp2.exe:4188): WARNING **: Missing method Mono.WebServer.XSPWebSource::.ctor(IPAddress,int,SecurityProtocolType,X509Certificate,PrivateKeySelectionCallback,bool,bool,bool) in assembly C:\Program Files\Mono-2.4.2.3\lib\mono\gac\Mono.WebServer2\0.2.0.0__0738eb9f132ed756\Mono.WebServer2.dll, referenced in assembly C:\Program Files\Mono-2.4.2.3\lib\mono\gac\xsp2\2.4.2.0__0738eb9f132ed756\xsp2.exe I have the Mono.Security.dll referenced and in the same directory. Remove it and it will work marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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-aspnet-list] [Mono-list] sqlite questions?
Dale E. Moore wrote: Is this a good place to ask questions about sqlite? Can somebody please tell me where to go;) On SQLite itself - no, in relation to Mono/ASP.NET - yes. Has everybody (or anybody) worked with monodevelop to put together an asp.net http://asp.net application that uses an sqlite database that they then put into production? I don't use MonoDevelop, but for a production application which can use SQLite as an option, see BlogEngine.NET. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] [Mono-aspnet-list] sqlite questions?
william leader wrote: I would suggest you consider using another database altogether. SQLite is meant to interface with c and c++ programs, neither of which is a language mono supports. Most asp.net applications are developed for Microsoft SQL server or MySQL server depending on where the developer wants the asp.net application to be run. Personally I would suggest MySQL as it has good support for ASP.net features like membership and role providers. Additionally the MySQL server can be run on a range of operating systems such as Windows and Linux. The MySQL libraries that allow .net languages such as C# to easily communicate with the MySQL server are known to work in both Microsoft and Mono environments. As a plus the community version of MySQL can be had for no cost, or if you need business support a commercial version is also available. First of all, I suggest what Gonzalo did in his mail - do some research before ill-advising somebody and spreading misinformation. In addition to what Gonzalo pointed out (the google search), there is also a pure C# port of SQLite (http://code.google.com/p/csharp-sqlite/). As for recommending MySQL... I beg to differ - MySQL is not the only and not the best (IMHO) choice out there for .NET developers on any platform. One problem with MySQL provider for .NET is not really technical, but is never the less important - the connector is GPL-ed, so if your plan is to use it for a closed-source application which you want to sell (or even just provide in binary-only form) then you will either need to purchase commercial license from MySQL, open your code or resort to various tricks to circumvent GPL. Much better choice, as somebody else suggested, is PostgreSQL - its .NET driver (Npgsql) is LGPL, has all the features you mentioned (membership, profile, role) and is shipped with Mono. Also, in my personal opinion, PostgreSQL offers much higher quality product (reliability, advanced features, security) than MySQL. marek -Will On Tue, Nov 3, 2009 at 5:01 AM, Dale E. Moore daleemo...@gmail.com wrote: Is this a good place to ask questions about sqlite? Can somebody please tell me where to go;) Has everybody (or anybody) worked with monodevelop to put together an asp.net application that uses an sqlite database that they then put into production? hello, hello, hello ... is there anybody out there? ___ Mono-aspnet-list mailing list mono-aspnet-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list mono-aspnet-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] sqlite questions?
Dale E. Moore wrote: Is this a good place to ask questions about sqlite? Can somebody please tell me where to go;) On SQLite itself - no, in relation to Mono/ASP.NET - yes. Has everybody (or anybody) worked with monodevelop to put together an asp.net http://asp.net application that uses an sqlite database that they then put into production? I don't use MonoDevelop, but for a production application which can use SQLite as an option, see BlogEngine.NET. marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
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-list] Compiling ASP.NET MVC 1.0 on Mono.
Tom Opgenorth wrote:
Hello all,
Hello,
For my own curiousity, I tried to compile the ASP.NET MVC 1.0 source
code on Mono 2.4.3 (Ubuntu 9.10 x64). When I do so under either
MonoDevelop or xbuild, I get this error message:
Mvc/FormCollection.cs(24,6): error CS0246: The type or namespace
name `FormCollectionBinder' could not be found. Are you missing a
using directive or an assembly reference?
Now, FormCollectionBinder is an attribute that adorns the class
System.Web.MVC.FormCollection. The declaration of
FormCollectionBinderAttribute is a private sealed class inside of
FormCollection. If I move the code for this attribute outside of the
class declaration for FormCollection and then try to compile, there
seems to be no problems.
Could this be a bug with the compiler? A simpler case is this:
Yes, and the bug was fixed after 2.4.3 was released.
using System;
namespace Test
{
[MyAttribute]
public class MyClass
{
private sealed class MyAttribute: Attribute
{
}
public void MyMethod()
{
Console.WriteLine(Hello World!);
}
}
}
I could not get this to compile on Mono 2.4.3. Or, is there something
special one must do to get this to compile?
A workaround is to move the attribute class outside its containing type.
marek
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] mod_mono parallel requests dont’t run in parallel
michaeltheplumber wrote: hi, Hey, using jquery ($.get(..) ) I call 3 times the same ASP.NET MVC controller method in one go. Since the responses are handled asynchronously, the requests go out almost in parallel. I know they go off in parallel, because I pass in the client's current time as a parameter, but they seem to be processed (serverside) one after the other. To proof this, I response out the start and end time in my controller routine. In VS2008, using the little debug webserver, it works perfectly in parallel (same start time). But running mod_mono on Apache, I never get the calls to start in parallel. The processing of the individual calls takes some time (about a second to call an external sevice), so i can see the delay very clearly, i'm not talking about milliseconds. The user experience on the page is not very good, the user sees the returning data areas one after the other instead of building up simultanously. We develop a public website, utilizing shopping apis from amazon,ebay etc. Setup: Mono 2.4.latest, Linux OpenSuse 11, Virtual Server, showing 4 cpus in cpuinfo, Apache (running worker MPM with high performance settings), hosted by a professional service. Since they are separate requests, I don't see a reason they wouldn't be handled in parallel on a 4-way machine unless there's a lock held somewhere on the way which serializes them. It's impossible to tell what's happening for sure without having sample code which exposes the issue. Please follow http://mono-project.com/Bugs and file a bug report for the System.Web component with attached simple, self-contained test case which reproduces the problem. Any ideas ? Is this something I have to worry about ? I do worry about scalibility in large, when all requests are handled one after the other.. will it scale better if the request would come from different machines (users) ? We have tested Mono's ASP.NET under very high load and it scaled pretty well. Our garbage collection is not as good as we'd wish it to be, but overall the performance was more than satisfactory. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] OutputCache in ASP.NET MVC ?
michaeltheplumber wrote: i worked around it by implementing this http://blog.maartenballiauw.be/post/2008/06/26/Creating-an-ASPNET-MVC-OutputCache-ActionFilterAttribute.aspx works great ! Then it's weird OutputCacheAttribute doesn't work - they both do, in essence, the same thing. Please file a bug with a sample which reproduces the issue. marek Thanks Michael ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] EnableEventValidation not working
APS wrote: Hi, Hey, I have some page where mono gives me the error: Invalid postback or callback argument. Event validation is enabled using pages enableEventValidation=true/ in configuration or %@ Page EnableEventValidation=true % in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation. The same page works correctly on MS.NET but the problem is another. Even inserting EnableEventValidation=false in Page directive or pages enableEventValidation=false/ in web.config file the error still raise. Maybe EnableEventValidation is not implemented in Mono? Or I'm doing something wrong? As the above message reads, event validation is enabled. It is implemented by Mono but you might have hit a bug. Create a simple, self-contained and ready to run test case and file a bug report for the System.Web component attaching the test case (see http://www.mono-project.com/Bugs) marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] System.InvalidCastException on LoadViewState
APS wrote: Thank you Marek, I'll check for some error in rebuilding objects but it's not strange that it works on 2.0.1? It might be a regression, of course - but to make sure I'd need a test case from you (file a bug report and attach a test case to it - ready to run) best, marek At 21.45 09/10/2009, Marek Habersack wrote: Marek Habersack wrote: Stifu wrote: It sounds a lot like a regression in Mono. Maybe you could file a bug report with a reduced test case, to bring it to the attention of the developers? I am working on this issue now. Fix should land in svn tonight. I'll follow up when that happens. No commit has happened as it turned out not to be a bug in Mono. APS, can you check that you recreate the controls on post-back in the same order and number as during normal request? Code which is not symmetrical in that regard might work on .NET (by sheer accident, as .NET uses the same types to serialize most control's view state whereas Mono doesn't do that), even though particular viewstate item might be sent for restore to a control which hasn't created the state. marek marek aps-3 wrote: Probably I have some custom object inside viewstate, maybe this could be the problem, but why it works on MS and Mono 2.0.1? What I can check? At 11.46 05/10/2009, APS wrote: Hi, yesterday I moved my web application from Mono 2.0.1 to Mono 2.4. Now in some page, during postback I obtain the following error. I will check what there is in viewstate but I can't understand why it works on 2.0.1 and not on 2.4 Some change in Mono can cause this problem? It works on MS. Thanks in advance. System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. --- System.InvalidCastException: Cannot cast from source type to destination type. at System.Web.UI.StateBag.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Page.LoadPageViewState () [0x0] at System.Web.UI.Page.RestorePageState () [0x0] at System.Web.UI.Page.InternalProcessRequest () [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] --- End of inner exception stack trace --- 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] -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da http://www.mailscanner.info/MailScanner, ed e' risultato non infetto. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo
Re: [Mono-aspnet-list] System.InvalidCastException on LoadViewState
Marek Habersack wrote: Stifu wrote: It sounds a lot like a regression in Mono. Maybe you could file a bug report with a reduced test case, to bring it to the attention of the developers? I am working on this issue now. Fix should land in svn tonight. I'll follow up when that happens. No commit has happened as it turned out not to be a bug in Mono. APS, can you check that you recreate the controls on post-back in the same order and number as during normal request? Code which is not symmetrical in that regard might work on .NET (by sheer accident, as .NET uses the same types to serialize most control's view state whereas Mono doesn't do that), even though particular viewstate item might be sent for restore to a control which hasn't created the state. marek marek aps-3 wrote: Probably I have some custom object inside viewstate, maybe this could be the problem, but why it works on MS and Mono 2.0.1? What I can check? At 11.46 05/10/2009, APS wrote: Hi, yesterday I moved my web application from Mono 2.0.1 to Mono 2.4. Now in some page, during postback I obtain the following error. I will check what there is in viewstate but I can't understand why it works on 2.0.1 and not on 2.4 Some change in Mono can cause this problem? It works on MS. Thanks in advance. System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. --- System.InvalidCastException: Cannot cast from source type to destination type. at System.Web.UI.StateBag.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Page.LoadPageViewState () [0x0] at System.Web.UI.Page.RestorePageState () [0x0] at System.Web.UI.Page.InternalProcessRequest () [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] --- End of inner exception stack trace --- 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] -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da http://www.mailscanner.info/MailScanner, ed e' risultato non infetto. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] System.InvalidCastException on LoadViewState
Stifu wrote: It sounds a lot like a regression in Mono. Maybe you could file a bug report with a reduced test case, to bring it to the attention of the developers? I am working on this issue now. Fix should land in svn tonight. I'll follow up when that happens. marek aps-3 wrote: Probably I have some custom object inside viewstate, maybe this could be the problem, but why it works on MS and Mono 2.0.1? What I can check? At 11.46 05/10/2009, APS wrote: Hi, yesterday I moved my web application from Mono 2.0.1 to Mono 2.4. Now in some page, during postback I obtain the following error. I will check what there is in viewstate but I can't understand why it works on 2.0.1 and not on 2.4 Some change in Mono can cause this problem? It works on MS. Thanks in advance. System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. --- System.InvalidCastException: Cannot cast from source type to destination type. at System.Web.UI.StateBag.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewState (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Control.LoadViewStateRecursive (System.Object savedState) [0x0] at System.Web.UI.Page.LoadPageViewState () [0x0] at System.Web.UI.Page.RestorePageState () [0x0] at System.Web.UI.Page.InternalProcessRequest () [0x0] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x0] --- End of inner exception stack trace --- 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] -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da http://www.mailscanner.info/MailScanner, ed e' risultato non infetto. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-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-aspnet-list] [PATCH] support WCF proxy in ASP.NET AJAX
Atsushi Eno wrote: Hi, Hey Atsushi, I have created a patch that adds WCF support to ASP.NET AJAX ProxyGenerator. The change is not small and it involves some structural changes to existing asmx support, but what I basically did was to make LogicalTypeInfo and LogicalMethodInfo abstract and create sets of derived types for asmx and WCF. Everything looks good from a quick review, but could you please add some tests which check the functionality? All dependent changes other than this patch is already made in mcs trunk. Please review - I feel sorry to have such a large change though... ;/ It looks fine to commit, but please don't do it till after 2.6 is branched - we should consider this code experimental and untested, so it wouldn't be a good idea to commit it at this point, imho. best, marek Atsushi Eno ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] xsp2 and *nux question
Xu, Jiangyan wrote: Oops, this option doesn't show up in the man page but does show up with xsp2 --help, which I forgot to check. Thanks! Do not use xsp2 as a server for production code - it's not suited for that purpose. Perfectly ok for testing/development, though. best, marek Best, Jiangyan 2009/9/17 Kornél Pál kornel...@gmail.com: Hi, Use xsp2 --nonstop Kornél Xu, Jiangyan wrote: Hello, I am using xsp2 as a lightweight server for my web application. I wanted to run it as a daemon process but when I use xsp2 the process immediately exits. I guess the problem here is that xsp2 reads 'Return' (Console.ReadLine()) as a signal to stop but when run as a daemon, the stdin gives the process EOF or something. Is there a way to get around this? Best, Jiangyan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] Debugging web apps on Mono
Mike Christensen wrote: Just pinging on this (last time, sorry).. I'm quite curious if any further work is being done on this. Thanks! http://monodevelop.com/Download/What%27s_new_in_MonoDevelop_2.2#Debugger marek On Fri, Aug 21, 2009 at 12:55 PM, Mike Christensen m...@kitchenpc.com mailto:m...@kitchenpc.com wrote: Hi all - Does anyone know when the Mono debugger will support debugging code running on XSP (And when MonoDevelop will support this as well)? I heard some people were working on this, but I cannot find any updates in over a year. Mike ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] ProfileCommon not automatically generated under XSP
wleader wrote: Hello, What is the Mono version you're using? ProfileCommon has been supported in Mono since 2006. If you're using the latest mono and still see the issue, then this is a bug - please file a bug (http://mono-project.com/Bugs) with a self-contained test case attached. If you're using some old version of Mono, please upgrade. marek I am building my ASP.Net 2.0 application using Visual Studio as my IDE. As I make changes I like to test with both the development server included with Visual Studio, and also with XSP running inside the mono runtime in Windows. My presumption is that testing this way I can be sure to write code that works on .Net hosts and Mono hosts. Currently I am working on adding a feature that uses Profiles, and I have things working using the MySQL Profile Provider under the Visual Studio web server. So far I have added the following to my web.config profile defaultProvider=MySQLProfileProvider providers remove name=MySQLProfileProvider/ add name=MySQLProfileProvider type=MySql.Web.Profile.MySQLProfileProvider, MySql.Web,Version=5.2.5.0,Culture=neutral, PublicKeyToken=C5687FC88969C44D connectionStringName=LocalMySqlServer applicationName=/ / /providers properties group name=GameStats add name=GamesJoined type=Int32 serializeAs =String defaultValue=0/ /group /properties /profile Once that was done inside visual studio, I was able to start using the ProfileCommon object which appears to be automatically generated by the compiler. In the code I can then do the following: ProfileCommon profile = (ProfileCommon.Create(ValidUsername) as ProfileCommon); LabelUsername.Text = profile.UserName; TextBoxGamesJoined.Text = profile.GameStats.GamesJoined.ToString(); This works great under the visual studio developement server, but when I attempt to load a page with this code on XSP I get the error message: Compiler Error Message: CS0246: The type or namespace name `ProfileCommon' could not be found. Are you missing a using directive or an assembly reference? Does anyone have advice about what I can do to get profile code that works on both .Net and Mono hosts? Thanks, -William Leader ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
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-aspnet-list] ASP.NET MVC V2
Gary Thomas wrote: I saw ScottGu's blog post about the ASP.NET MVC V2 Preview release the other day and was wondering if/when it'll come to Mono. It looks like they will ship it with VS.NET 2010. If the license permits, yes. Does anyone on the mono team have any insight here? Will Microsoft release it under MS-PL? Sorry, no idea there. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] USB hardware detection using Mono on Linux
Danny Haak wrote: Hi, Hello, That seems like a good approach, but on the HAL site it states that HAL is in maintenance mode - no new features are added. All future development focuses on Software/DeviceKit-disks, Software/DeviceKit-power, NetworkManager, PulseAudio, udev, ... [1]. Therefore, it seems not a good idea to me to use it in new software. You won't be using HAL directly though. By connecting to DBus and listening for events there you will separate yourself from whatever backend is being used by DBus to generate and deliver the notifications (right now it's HAL, tomorrow it might be something else - you won't care). regards, marek Best regards, Danny [1]: http://www.freedesktop.org/wiki/Software/hal -Original Message- From: mono-list-boun...@lists.ximian.com [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Adam Tauno Williams Sent: dinsdag 18 augustus 2009 12:49 To: mono-list Subject: Re: [Mono-list] USB hardware detection using Mono on Linux On Tue, 2009-08-18 at 12:06 +0200, Danny Haak wrote: Hi all, I am currently writing a piece of software that needs to detect which USB devices are attached to the computer. Event-based notifications of attaching and detaching hardware while the software is running is nice, but not required. I first used DeviceKit-Sharp (by Ben Gamari), but when observing a bug and asking the DeviceKit mailing-list, Kay Sievers answered: The DeviceKit daemon is dead and will not run, or be installed on any usual system. You need to use libudev, or the GUdev to retrieve this information. This is a pity, because DeviceKit was working nicely, despite the bug in the daemon. I can't find any Mono-bindings for libudev, and diving deeper in the documentation, libudev seems quite low-level and talking to HAL. Looking for HAL abstractions, I discovered that HAL will be obsolete as well in the near future. This leaves me completely confused about 'the way to go' for hardware detection in Mono on Linux. Is there anybody who can suggest a (sort of) future-proof approach to this? I believe you can attach to the system D-BUS and you will receive HAL events. http://www.ndesk.org/DBus_Documentation -- OpenGroupware developer: awill...@whitemice.org http://whitemiceconsulting.blogspot.com/ OpenGroupare Cyrus IMAPd documenation @ http://docs.opengroupware.org/Members/whitemice/wmogag/file_view ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] Error: The imported type 'user control is defined' multiple times
Jyoti Seth wrote: Hello All, Hello, I have defined user control on a content page. It is throwing the following error on mono 2.4.2 The imported type 'ASP.controls_testcontrol_ascx' is defined multiple times. Whereas it was executing properly on previous version of mono. You will need to create a small test case out of it and file the bug using instructions at http://mono-project.com/Bugs marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] Mod_mono and apache issue.
dejavu wrote: Hey, Hey gary, thanks for the reply. I did try installing the following packages that u mentioned. Sadly, it still shows no sign of working. Could it be because i'm doing something else wrong? Try to generate your config using this utility: http://go-mono.com/config-mod-mono/ Let us know how it worked, marek Regards, Vijay. gazzyt wrote: I'm using ubuntu rather than openSUSE. I seem to remember having to install the following packages before it would work but I can't remember what the actual error message was. apache2-mpm-prefork apache2-threaded-dev Regards, Gary -Original Message- From: mono-aspnet-list-boun...@lists.ximian.com [mailto:mono-aspnet-list-boun...@lists.ximian.com] On Behalf Of dejavu Sent: 14 August 2009 12:28 To: mono-aspnet-list@lists.ximian.com Subject: [Mono-aspnet-list] Mod_mono and apache issue. Hello all. Ive been stuck with this problem for a few days now. I cant seem to figure out what the real problem is. I've installed apache 2.2, mono-2.4.2 with xsp, and mod_mono. I have the same setup in a linux openSUSE 11.1 and a windows system. Im exactly following the instructions that are given http://www.codeproject.com/KB/cross-platform/introtomono2.aspx here. Towards the end of that article, it's mentioned 2 ways to serve ASP.NET pages using mono. 1) Running the xsp server. 2) Modifying the httpd.conf file of the apache server to include the mod_mono module. Now by both the ways, i should be able to see my ASPnet page. But I'm able to get it only throug the 1st way, ie through xsp. When i try the same through apache, it gives me a 503. Service temporarily unavailable error. Also in the error log, i get Failed to connect to mod-mono-server after several attempts to spawn the process. Could somebody please point out to me what im doing wrong. Ive literally swept google for solutions on this. I couldnt fine any, or ive missed it. Hopping someone could help me out with this. Thanks, Vijay -- View this message in context: http://www.nabble.com/Mod_mono-and-apache-issue.-tp24934731p24934731.htm l Sent from the Mono - ASP.NET mailing list archive at Nabble.com. ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] Is this a serious flaw or just my mistake?
Batchwood wrote: Diego Frata wrote: Try setting the configuration for each virtual host instead using the mod_mono.conf. Eg: VirtualHost *:80 ServerName my-mono-site.com ServerAdmin web-ad...@my-mono-site.com DocumentRoot /srv/www/my-mono-site.com * MonoServerPath my-mono-site.com /usr/bin/mod-mono-server2 MonoSetEnv my-mono-site.com MONO_IOMAP=all MonoApplications my-mono-site.com /:/srv/www/my-mono-site.com * Location / Allow from all Order allow,deny *MonoSetServerAlias my-mono-site.com* *SetHandler mono* SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary /Location IfModule mod_deflate.c AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript /IfModule /VirtualHost Diego Frata diego.fr...@gmail.com thank you for your response, Diego. I tried for many hours to make this work with no luck. It appears that virtual hosting is not possible in mono. It is of course possible (and used heavily by us at Mono as well as on quite a few websites). In your original post you don't say why apache doesn't start. This suggests an error, errors are logged in apache's error.log. Mod_mono itself has nothing to do with virtual hosting, it's just a module which passes requests to an _application_ running in background, with said application again having nothing to do with virtual hosting. So the error is not related to virtual hosting, but rather to some misconfiguration of Apache (which might, of course, be related to Mono). Until you give us more info on what errors are in apache's error log, we can't tell much about the causes. I think you should start by going to http://go-mono.com/config-mod-mono/ and generating valid mod_mono configuration. Therefore, unfortunately, it's back to PHP where I know that virtual hosting works in native Apache. This is really too bad because ASP.net is so much cleaner than PHP. You seem to be a bit confused about how mod_mono works. The apache side of it (the mod_mono.so module) is almost no different than PHP. The difference is that as long as PHP (in most installations) is embedded in the shared module, mod_mono is not embedding the Mono runtime but rather passing the requests along to a backend process which then executes the request within the application. Each virtual host corresponds (roughly) to a single backend process. And, once again, neither mod_mono or Mono runtime deal with virtual hosting. mod_mono looks at and selects backends to service a request by looking at the server alias (the one set with MonoSetServerAlias). marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-list] how to change asp.net version
Bharti Mishra wrote: hi, Hey, I got your reply, but I am not satisfied with your answer. please describe me following error : I want to migrate vb.net code onto opensuse11.1 platform using mono2.4.2. but this mono version support asp.net 2.0 version , and when I execute my project through browser it displays mono2.0 asp.net2.0 , but my project uses asp.net 1.0 version. I tried to change asp.net version in mono by adding mod-mono-server1 inside mod_mono.conf file. After changing the version I got in browser window mono 1.1 asp.net 1.1 , also I got following error : explanation Compilation of Visual Basic code is not supported for v1.0/v1.1 assemblies, please use the v2.0 assemblies. -If this is a web application, use xsp2/mod_mono_server2 instead of xsp/mono_mono_server(see http://www.mono-project.com/Mod_mono#ASP.NET_2_apps_do_not_work). -If this is a desktop application, use gmcs to compile your application instead of mcs. explanation please explain me the way to enable asp.net 1.0 in mono2.4.2. and explain me this error. Explanation is shown above, right in the error message. marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-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
Re: [Mono-list] [Mono-dev] 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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] null ref. exception
Peter Hagen wrote: Hi Gonzalo I did some tests on ./mcs/class/System.Web/System.Web.UI/Control.cs and noticed if the TemplateSourceDirectory is empty, I get the crash. [snip] So, i added this line, which is probably not ok, but it works now. Im not sure what the TemplateSourceDirectory should be in this case. Do you have a suggestion? It should always be set to the virtual directory of the current control's parent. TemplateSourceDirectory can be empty only in those cases (2.0 profile): 1. this.TemplateControl is null and HttpContext.Current is null and the current control is not a TemplateControl 2. current control is a TemplateControl and this.AppRelativeVirtualPath is null, which can happen only if AppRelativeVirtualPath is never initialized from code generated by ASP.NET compiler. 3. We have a bug in 2.0 logic for Control.TemplateSourceDirectory My bet is on #2, which would mean that your application is incorrectly ported to 2.0 - make sure that you run it with the 2.0 runtime, that all your code-behind and referenced assemblies are compiled with the 2.0 compiler. It is possible that some of your controls use the 1.1 version of System.Web and thus hit the 1.1 path in Control.TemplateSourceDirectory. regards, marek Cheers Peter On Mon, 2009-07-20 at 00:02 -0400, Gonzalo Paniagua Javier wrote: On Sun, 2009-07-19 at 18:40 +0200, Peter Hagen wrote: Hi Gonzalo well, i have a bit a problem of recreating the bug in a new project. If i make a new project from MonoDevelop, it works as planned. But inside my project it doesn't. But this is originally a 1.1 application. Uploading the entire project isnt really an option. So, ill try to figure out more about the project first :s If you can build System.Web from sources, sprinkle a few Console.WriteLine() in Contorl.AppRelativeTemplateSourceDirectory and ToAppRelative. That will at least tell you where the 'null' is used for the first time. -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] null ref. exception
Peter Hagen wrote:
Ow, and I forgot to mention, it does work under 2.0.1, but not with
2.4.2.2
Well, it's hard to determine what causes it without seeing the app/sample/test
case. If you can give
Gonzalo or I access to a server with the application (shell would be required),
or share (privately)
the source with either us, that'd be helpful.
regards,
marek
Cheers
Peter
On Mon, 2009-07-20 at 15:27 +0200, Peter Hagen wrote:
Hi Marek
you are right, there were some projects at 1.1. Yesterday I changed
that, but I seemed not to have checked in my changes. I now am sure
that all the controls (even NeatUpload) are compiled as 2.0, but still
the exception occures. Im sure that the exception is throw by the
IsAbsolute method:
public static bool IsAbsolute (string virtualPath)
{
if (StrUtils.IsNullOrEmpty (virtualPath))
throw new ArgumentNullException (virtualPath);
return (virtualPath [0] == '/' || virtualPath [0] == '\\');
}
when I print the value of virtualPath, it is indeed empty (but not null). If
I just compile a control which was made for 1.1 as a 2.0 project, then
things should be ok? The control that gives the exception is the neatupload
inputcontrol which is derived from the FileContol, which comes from the
System.Web.UI.WebControls.WebControl. I guess that should be no problem?
public abstract class FileControl : System.Web.UI.WebControls.WebControl,
System.Web.UI.IPostBackDataHandler
Cheers
Peter
On Mon, 2009-07-20 at 13:18 +0200, Marek Habersack wrote:
Peter Hagen wrote:
Hi Gonzalo
I did some tests on ./mcs/class/System.Web/System.Web.UI/Control.cs and
noticed if the TemplateSourceDirectory is empty, I get the crash.
[snip]
So, i added this line, which is probably not ok, but it works now. Im
not sure what the TemplateSourceDirectory should be in this case. Do you
have a suggestion?
It should always be set to the virtual directory of the current control's
parent.
TemplateSourceDirectory can be empty only in those cases (2.0 profile):
1. this.TemplateControl is null and HttpContext.Current is null and the
current control is not a
TemplateControl
2. current control is a TemplateControl and this.AppRelativeVirtualPath is
null, which can happen
only if AppRelativeVirtualPath is never initialized from code generated
by ASP.NET compiler.
3. We have a bug in 2.0 logic for Control.TemplateSourceDirectory
My bet is on #2, which would mean that your application is incorrectly
ported to 2.0 - make sure
that you run it with the 2.0 runtime, that all your code-behind and
referenced assemblies are
compiled with the 2.0 compiler. It is possible that some of your controls
use the 1.1 version of
System.Web and thus hit the 1.1 path in Control.TemplateSourceDirectory.
regards,
marek
Cheers
Peter
On Mon, 2009-07-20 at 00:02 -0400, Gonzalo Paniagua Javier wrote:
On Sun, 2009-07-19 at 18:40 +0200, Peter Hagen wrote:
Hi Gonzalo
well, i have a bit a problem of recreating the bug in a new project.
If i make a new project from MonoDevelop, it works as planned. But
inside my project it doesn't. But this is originally a 1.1
application. Uploading the entire project isnt really an option. So,
ill try to figure out more about the project first :s
If you can build System.Web from sources, sprinkle a few
Console.WriteLine() in Contorl.AppRelativeTemplateSourceDirectory and
ToAppRelative. That will at least tell you where the 'null' is used for
the first time.
-Gonzalo
___
Mono-list maillist - Mono-list@lists.ximian.com
mailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] SIGSEGV error, no idea why?
Piercy wrote: OK right just to make sure i did this right ill list exactly what i did: 1) open shell 2) cd /home/user/public_html/weddingsite 3) MONO_OPTIONS=--trace xsp2 --nonstop --port 8181 --applications /home/user/public_html/weddingsite:. trace.log 21 4) wget http://localhost:8181 5) tail -n100 trace.log output: http://piercy.pastebin.com/da70995a this file is 164mb big and it was only running about 30 seconds. maybe i will need to analyze the whole file? It would seem so, alas. Fortunately, it should be pretty easy - you need to look for increasing line indentation, which singals recursive calls, so you don't really need to read the log until you find that pattern. The part you pasted deals with reading some XML input and looks pretty standard. If you have a chance, try running your app with Mono from svn trunk to see if it still breaks there (here's a short HOWTO: http://mono-project.com/Compiling_Mono_From_SVN) marek Many thanks for your help, Piercy Robert Jordan wrote: Piercy wrote: Ok, i tried my best to trace this. I didnt do it on xsp (because i have no idea how that works or anything so jsut used apache). i navigated to the ASP .Net sites bin folder and did mono --trace WeddingSite.dll fileOut.txt (is this correct?). The output i got was this: It's not correct. Try this: 1) open a shell 2) change into your app's directory 3) execute: MONO_OPTIONS=--trace xsp2 --nonstop --port 8181 --applications /:. trace.log 21 4) navigate to http://localhost:8181/ and try to trigger the crash 5) execute tail -n100 trace.log 6) post the output of (5) If your application's virtual root isn't / then adjust the --applications switch accordingly: --applications /foo:. Robert ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-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
[Mono-list] 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-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Reading application settings from web.config file
Andrus Moor wrote: I have VS generated web.config file which contains application settings: ?xml version=1.0? configuration configSections ... applicationSettings MyApp.Service.Properties.Settings setting name=Server serializeAs=String valuemyserver.com/value /setting /MyApp.Service.Properties.Settings /applicationSettings /configuration [snip] This was fixed for trunk sometime ago, look at this bug https://bugzilla.novell.com/show_bug.cgi?id=491531 I've just backported it to the 2.4 branch (r135562) marek ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] Disable ASP.NET 2?
dugaldcurtis wrote: I am still unable to fix this. I tried purging all mono related packages and reinstalling but it doesn't help. If I install the mono-apache-server2 package again I start getting this in my apache log: [snip] I am desperate to get this sorted - can anyone suggest a course of action? In latest Mono versions mod-mono-server and mod-mono-server2 both run ASP.NET 2.0. If you want 1.1 use mod-mono-server1 marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] Failed to connect to mod-mono-server after several attempts to spawn the process.
samgod wrote: [snip] I tryed wirh apachectl too but the problem still remain the same, mod_mono process doesn't restart. After restarted all (apache , mod_mono and cleaned dirs) all websites works fine for some hour but random, one of them shows the message The server is temp Any idea? Thx Im running fedora core 10 with mono and I get the exact same problems as vereno. I've been searching for two weeks non stop for a solution and never found one. I'm also wondering if its normal that mono runs very slow, It takes about 10 seconds for a page to load. Denis 300, you wrote you found the solution to this problem, and it had to do with the permissions. Can you be a little bit more clear... or perhaps someone else has a solution to this. You should all upgrade to Mono 2.4. All of those problems were fixed before 2.4 got released IIRC. marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-aspnet-list] Dummies guide to setting up Mono with Apache on OS X
Siôn wrote: I'm a MS ASP.NET developer by trade and after many, many, years I've come back to using an Apple Mac in my spare time. Basically, I know nothing about Unix and very little about Apache and so I would like to ask the Mono community help on getting started. I've downloaded and installed the MonoFramework-2.4_7.macos10.novell.universal.dmg, but I'm not sure what to do next? Read the following document: http://mono-project.com/Mod_mono And use this utility to generate the config: http://go-mono.com/config-mod-mono/ marek ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
