RE: [Mono-dev] System.Web.UI.Page patch
> I'd like to see the test used for this as well. Did you see the standalone test that I sent yesterday? For convenience, I attach it to this message, too. It covers the following patches: ApplyTheme.patch Page.Web.Config.patch PageTheme.patch > At first blush the theme change looks ok, but I really don't > like the idea of adding the ApplyTheme behavior to OnInit. > Unless, of course, this is what actually happens in MS's > implementation. It's not OnInit, it's in CreateChildControls flow. To figure that out in MS implementation I made this: public class MyLogin:Login { protected override void OnInit (EventArgs e) { Trace.WriteLine ("before Login.OnInit"); base.OnInit (e); Trace.WriteLine ("after Login.OnInit"); } protected override void AddedControl (System.Web.UI.Control control, int index) { Trace.WriteLine ("before Login.AddedControl"); base.AddedControl (control, index); Trace.WriteLine ("after Login.AddedControl"); } protected override void CreateChildControls() { Trace.WriteLine ("before Login.CreateChildControls"); base.CreateChildControls (); Trace.WriteLine ("after Login.CreateChildControls"); } } public class MyImageButton:ImageButton { protected override void OnInit (EventArgs e) { Trace.WriteLine ("ImageButton.OnInit"); base.OnInit (e); } public override void ApplyStyleSheetSkin (System.Web.UI.Page page) { Trace.WriteLine ("ImageButton.ApplyStyleSheetSkin"); base.ApplyStyleSheetSkin (page); } public override string ImageUrl { get { return base.ImageUrl; } set { Trace.WriteLine ("Set ImageButton.ImageURL"); base.ImageUrl = value; } } } and changed in aspx and to and the output looked like: before Login.OnInit after Login.OnInit before Login.CreateChildControls ImageButton.ApplyStyleSheetSkin Set ImageButton.ImageURL before Login.AddedControl ImageButton.OnInit after Login.AddedControl after Login.CreateChildControls > > Also, the master page change doesn't seem necessary to me, in > the scope of the greater change. The controls will have > their OnInit methods's called properly when they're added to > the already Init'ed controls. If you do ApplyMasterPage after InitRecursive, then elements defined on master page do not get their themes. Just try the standalone test I sent, the difference is clear. If you have no further comments, I will commit 3 patches I listed at the beginning of this message and the standalone test. Thank you. Andrew. PageLinks.tar.gz Description: PageLinks.tar.gz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DeadLock Problem in ASP.NET
Hi Gonzalo, It seems that i've another deadlock problem, but it's very hard to reproduce exactly I've send a SIGQUIT to mod_mono_server to do a thread dump : - Full thread dump: - - "" tid=0x0xb6ca0bb0 this=0x0x152f00: - in (wrapper managed-to-native) System.Threading.WaitHandle:WaitOne_internal (intptr,int,bool) <0x4> - in (wrapper managed-to-native) System.Threading.WaitHandle:WaitOne_internal (intptr,int,bool) <0xda4> - in System.Threading.WaitHandle:WaitOne (int,bool) <0x34> - in Runner:Start () <0xe6> - in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () <0x57558> - in (wrapper runtime-invoke) System.Object:runtime_invoke_void (object,intptr,intptr,intptr) <0x513ce369> - - "" tid=0x0xb5db7bb0 this=0x0x2562bb0: - in (wrapper managed-to-native) System.Threading.Monitor:Monitor_try_enter (object,int) <0x4> - in (wrapper managed-to-native) System.Threading.Monitor:Monitor_try_enter (object,int) <0xffb3> - in System.Threading.Monitor:Enter (object) <0x13> - in System.IO.FAMWatcher:StartDispatching (System.IO.FileSystemWatcher) <0x27> - in System.IO.FileSystemWatcher:Start () <0x17> - in System.IO.FileSystemWatcher:set_EnableRaisingEvents (bool) <0x27> - in (wrapper remoting-invoke-with-check) System.IO.FileSystemWatcher:set_EnableRaisingEvents (bool) <0xffba2006> - in System.Web.Caching.CacheDependency:.ctor (string[],string[],System.Web.Caching.CacheDependency,System.DateTime) <0x246> - in System.Web.Caching.CacheDependency:.ctor (string[]) <0x31> - in System.Web.Compilation.AspGenerator:GetCompiledType () <0x11e> - in System.Web.UI.UserControlParser:CompileIntoType () <0x27> - in System.Web.UI.UserControlParser:GetCompiledType (string,string,System.Collections.ArrayList,System.Web.HttpContext) <0x2e> - in System.Web.UI.TemplateControlParser:AddDirective (string,System.Collections.Hashtable) <0x304> - in System.Web.Compilation.AspGenerator:TagParsed (System.Web.Compilation.ILocation,System.Web.Compilation.TagType,string,System.Web.Compilation.TagAttributes) <0x1be> - in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_ILocation_TagType_string_TagAttributes (System.Web.Compilation.ILocation,System.Web.Compilation.TagType,string,System.Web.Compilation.TagAttributes) <0xfff3> - in System.Web.Compilation.AspParser:OnTagParsed (System.Web.Compilation.TagType,string,System.Web.Compilation.TagAttributes) <0x23> - in System.Web.Compilation.AspParser:Parse () <0x159> - in System.Web.Compilation.AspGenerator:Parse (string) <0x28> - in System.Web.Compilation.AspGenerator:Parse () <0x2c> - in System.Web.Compilation.AspGenerator:GetCompiledType () <0x9f> - in System.Web.UI.PageParser:CompileIntoType () <0x27> - in System.Web.UI.TemplateControlParser:GetCompiledInstance () <0x10> - in System.Web.UI.PageParser:GetCompiledPageInstance (string,string,System.Web.HttpContext) <0x37> - in System.Web.UI.PageHandlerFactory:GetHandler (System.Web.HttpContext,string,string,string) <0x10> - in System.Web.HttpApplication:GetHandler (System.Web.HttpContext) <0x1a3> - in __1:MoveNext () <0x806> - in System.Web.HttpApplication:Tick () <0x1c> - in System.Web.HttpApplication:Start (object) <0xcf> - in System.Web.HttpApplication:System.Web.IHttpAsyncHandler.BeginProcessRequest (System.Web.HttpContext,System.AsyncCallback,object) <0x70> - in System.Web.HttpRuntime:RealProcessRequest (object) <0x1ab> - in System.Web.HttpRuntime:ProcessRequest (System.Web.HttpWorkerRequest) <0x2a> - in Mono.WebServer.MonoWorkerRequest:ProcessRequest () <0xa> - in Mono.WebServer.BaseApplicationHost:ProcessRequest (Mono.WebServer.MonoWorkerRequest) <0x43> - in Mono.WebServer.ModMonoApplicationHost:ProcessRequest (int,string,string,string,string,string,int,string,int,string,string[],string[]) <0xd3> - in (wrapper remoting-invoke-with-check) Mono.WebServer.ModMonoApplicationHost:ProcessRequest (int,string,string,string,string,string,int,string,int,string,string[],string[]) <0xff0c> - in (wrapper xdomain-dispatch) Mono.WebServer.ModMonoApplicationHost:ProcessRequest (object,byte[]&,byte[]&,int,string,string,string,string,string,int,string,int,string,string[],string[]) <0xb071> - in (wrapper xdomain-invoke) Mono.WebServer.ModMonoApplicationHost:ProcessRequest (int,string,string,string,string,string,int,string,int,string,string[],string[]) <0xff6a> - in (wrapper remoting-invoke-with-check) Mono.WebServer.ModMonoApplicationHost:ProcessRequest (int,string,string,string,string,string,int,string,int,string,string[],string[]) <0x46acca> - in Mono.WebServer.ModMonoWorker:InnerRun (object) <0x57a> - in Mono.WebServer.ModMonoWorker:Run (object) <0x17> - in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object (object) <0xff95> - in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object (object,intptr,intptr,intptr) <0x50f8c3c4> - - "" tid=0x0xb66b5bb0 this=0x0x210c0: - in (wrapper mana
[Mono-dev] Building mono under VS2003 (was: re: build mono under VS2005)
Hi: > > Someone should push me strong enough to find some time and contribute > > the project files back I guess :) > > Here is everything we do to compile mono (currently 1.1.14) with VS2003: http://otee.dk/files/mono/monochanges.html We do make some Unity specific changes though. Mostly related to reducing size (it's very important for our upcoming web plugin) and then to exception handling, secure calls, redirecting output files and hijacking exit()/abort() to print something to the log files. It could be horribly wrong of course. Use at your own risk. -- Aras Pranckevicius Graphics programmer at otee.dk ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev] System.Web.UI.Page patch
On Tue, 2006-04-25 at 02:16 -0700, Andrew Skiba wrote: > > I'd like to see the test used for this as well. > > Did you see the standalone test that I sent yesterday? For convenience, > I attach it to this message, too. It covers the following patches: > > ApplyTheme.patch > Page.Web.Config.patch > PageTheme.patch > > > At first blush the theme change looks ok, but I really don't > > like the idea of adding the ApplyTheme behavior to OnInit. > > Unless, of course, this is what actually happens in MS's > > implementation. > > It's not OnInit, it's in CreateChildControls flow. To figure that out in > MS implementation I made this: ah, sorry - I wasn't looking at the line numbers, I just searched for the surrounding patch context. > public class MyLogin:Login > { > protected override void OnInit (EventArgs e) > { > Trace.WriteLine ("before Login.OnInit"); > base.OnInit (e); > Trace.WriteLine ("after Login.OnInit"); > } > protected override void AddedControl > (System.Web.UI.Control control, int index) > { > Trace.WriteLine ("before Login.AddedControl"); > base.AddedControl (control, index); > Trace.WriteLine ("after Login.AddedControl"); > } > > protected override void CreateChildControls() > { > Trace.WriteLine ("before > Login.CreateChildControls"); > base.CreateChildControls (); > Trace.WriteLine ("after > Login.CreateChildControls"); > } > } > > public class MyImageButton:ImageButton > { > protected override void OnInit (EventArgs e) > { > Trace.WriteLine ("ImageButton.OnInit"); > base.OnInit (e); > } > public override void ApplyStyleSheetSkin > (System.Web.UI.Page page) > { > Trace.WriteLine > ("ImageButton.ApplyStyleSheetSkin"); > base.ApplyStyleSheetSkin (page); > } > > public override string ImageUrl > { > get > { > return base.ImageUrl; > } > set > { > Trace.WriteLine ("Set > ImageButton.ImageURL"); > base.ImageUrl = value; > } > } > } > > and changed in aspx and to > and > > the output looked like: > > before Login.OnInit > after Login.OnInit > before Login.CreateChildControls > ImageButton.ApplyStyleSheetSkin > Set ImageButton.ImageURL > before Login.AddedControl > ImageButton.OnInit > after Login.AddedControl > after Login.CreateChildControls > > > > > Also, the master page change doesn't seem necessary to me, in > > the scope of the greater change. The controls will have > > their OnInit methods's called properly when they're added to > > the already Init'ed controls. > > If you do ApplyMasterPage after InitRecursive, then elements defined on > master page do not get their themes. Just try the standalone test I > sent, the difference is clear. My comment was made under the assumption that the ApplyTheme call was in OnInit (as above.) I'll take a look at this further tonight probably. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-patches] r59521 - in trunk/mcs/class/System.Web: System.Web.Compilation System.Web.UI
Maybe I'm misremembering, but I don't recall approving this patch: > Modified: trunk/mcs/class/System.Web/System.Web.UI/TemplateParser.cs > === > --- trunk/mcs/class/System.Web/System.Web.UI/TemplateParser.cs 2006-04-16 > 05:55:06 UTC (rev 59520) > +++ trunk/mcs/class/System.Web/System.Web.UI/TemplateParser.cs 2006-04-16 > 11:44:14 UTC (rev 59521) > @@ -390,6 +390,20 @@ > } > } > > + internal virtual Assembly AddAssemblyByFileName (string > filename) > + { > + try { > + Assembly assembly = > Assembly.LoadFrom(filename); > + AddAssembly (assembly, true); > + return assembly; > + } > + catch (Exception e) > + { > + ThrowParseException ("Assembly file " + > filename + " not found", e); > + return null; //never gets here, only to > satisfy the compiler > + } > + } > + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Login control fixes
Hello everybody, The attached patch fixes two problems with the Login control in Mono: - As per http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.login.destinationpageurl.aspx the patch makes Login redirect the user to destination page, in the following precedence: - DestinationPageUrl property - Referring page - Forms authentication defaultUrl - The login page itself - When the login control is used inside a content placeholder with a master page (e.g. http://asp.net/QuickStart/util/srcview.aspx?path=~/aspnet/samples/ctrlref/login/Login.src) Mono will throw an exception referring to line 1332 in Login.cs. The patch fixes that by checking whether FormsAuthentication.LoginUrl is not null. I'm not sure whether the fix is correct, though, since the bug might be in FormsAuthentication code. The reason might be that the Initialize method of the FormsAuthentication class is not called before Login.IsDefaultLoginPage(). best regards, marek --- mcs.orig/class/System.Web/System.Web.UI.WebControls/Login.cs 2006-04-11 16:37:01.218843000 +0200 +++ mcs/class/System.Web/System.Web.UI.WebControls/Login.cs 2006-04-25 21:52:44.698745490 +0200 @@ -1285,8 +1285,13 @@ namespace System.Web.UI.WebControls { OnAuthenticate (aea); if (aea.Authenticated) { + FormsAuthentication.SetAuthCookie (UserName, RememberMeSet); + string url = DestinationPageUrl; - FormsAuthentication.SetAuthCookie (UserName, RememberMeSet); + if (url.Length == 0 && Page.Request.UrlReferrer != null) + url = Page.Request.UrlReferrer.ToString(); + if (url.Length == 0 && FormsAuthentication.DefaultUrl != null) + url = FormsAuthentication.DefaultUrl; if (url.Length == 0) { Redirect (FormsAuthentication.LoginUrl); } else { @@ -1320,8 +1325,10 @@ namespace System.Web.UI.WebControls { { if ((Page == null) || (Page.Request == null)) return false; - string url = Page.Request.Url.AbsolutePath; string defaultLogin = FormsAuthentication.LoginUrl; + if (defaultLogin == null) + return false; + string url = Page.Request.Url.AbsolutePath; return (String.Compare (defaultLogin, 0, url, url.Length - defaultLogin.Length, defaultLogin.Length, true, CultureInfo.InvariantCulture) == 0); } signature.asc Description: Digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Login control fixes
For bug fixes, please include along with the patch a test case (standalone aspx/master files is file) that shows the bug in the current code. Chris On Tue, 2006-04-25 at 22:03 +0200, Marek Habersack wrote: > Hello everybody, > > The attached patch fixes two problems with the Login control in Mono: > > - As per > http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.login.destinationpageurl.aspx >the patch makes Login redirect the user to destination page, in the >following precedence: > > - DestinationPageUrl property > - Referring page > - Forms authentication defaultUrl > - The login page itself > > - When the login control is used inside a content placeholder with a master >page (e.g. > http://asp.net/QuickStart/util/srcview.aspx?path=~/aspnet/samples/ctrlref/login/Login.src) >Mono will throw an exception referring to line 1332 in Login.cs. The >patch fixes that by checking whether FormsAuthentication.LoginUrl is not >null. >I'm not sure whether the fix is correct, though, since the bug might be >in FormsAuthentication code. The reason might be that the Initialize >method of the FormsAuthentication class is not called before >Login.IsDefaultLoginPage(). > > best regards, > > marek > ___ > 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] Incorrect Directory.GetParent behavior
On Mon, 2006-04-24 at 12:20 -0400, Emery Conrad wrote: > Hi there, > > Directory.GetParent should return a DirectoryInfo for *both* full path > names and relative path names. (See > http://msdn2.microsoft.com/en-us/library/system.io.directory.getparent.aspx > for microsoft doc). Here's the issue: currently, mono implements > Directory.GetParent using new DirectoryInfo(Path.GetDirectoryName(path)), but > Path.GetDirectoryName *does not* returns an absolute directory name for a > relative path (it returns the String-based relative path information > contained in the argument). So, when mono calls "new DirectoryInfo(relpath)" > for some relative path, it works UNLESS the Path.GetDirectoryName() has > return String.Emtpy (since this is the required behavior for this function > for a relative path of something in the current directory). > > The fix is to make the ctor for DirectoryInfo reset the argument to > Directory.GetCurrentDirectory() when the argument is String.Emtpy. > Diff is below. The problem is that on MS, when you do 'new DirectoryInfo ("")' it fails. Can you provide a test case or a bug report through bugzilla that reproduces the issue? -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DeadLock Problem in ASP.NET
On Tue, 2006-04-25 at 18:25 +0200, Hubert FONGARNAND wrote: > Hi Gonzalo, > > It seems that i've another deadlock problem, > but it's very hard to reproduce exactly > I've send a SIGQUIT to mod_mono_server to do a thread dump : Can you provide more data here? Specifically, the @Page or @Control directive for the page/control that is being compiled and anything else that helps reproducing the problem. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DeadLock Problem in ASP.NET
Le mardi 25 avril 2006 à 18:03 -0700, Gonzalo Paniagua Javier a écrit : On Tue, 2006-04-25 at 18:25 +0200, Hubert FONGARNAND wrote: > Hi Gonzalo, > > It seems that i've another deadlock problem, > but it's very hard to reproduce exactly > I've send a SIGQUIT to mod_mono_server to do a thread dump : Can you provide more data here? Specifically, the @Page or @Control directive for the page/control that is being compiled and anything else that helps reproducing the problem. -Gonzalo The only thing i can provide in the aspx... that sometimes fails... but the entire application is made of more 150 aspx/ascx files... But as i said, I can't reproduce this bug all the time... Thanks Hubert ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. <%@ Register TagPrefix="uc1" TagName="CoMenu" Src="CoMenu.ascx" %> <%@ Register TagPrefix="jlc" Namespace="JLovell.WebControls" Assembly="StaticPostBackPosition" %> <%@ Register TagPrefix="uc1" TagName="CoSearchApplication" Src="CoSearchApplication.ascx" %> <%@ Page language="c#" Codebehind="PageSearchApp.aspx.cs" AutoEventWireup="false" Inherits="IntranetAdmin.PageSearchApp" %> PageSearchApp http://schemas.microsoft.com/intellisense/ie5";> <%@ Control Language="c#" AutoEventWireup="false" Codebehind="CoSearchApplication.ascx.cs" Inherits="IntranetAdmin.CoSearchApplication" TargetSchema="http://schemas.microsoft.com/intellisense/ie5"%> Sélectionnez une application Recherche Rechercher Annuler Rechercher à partir du Le texte suivant Application... Résultats