date:20060425

RE: [Mono-dev] System.Web.UI.Page patch

2006-04-25 Thread Andrew Skiba

> 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

2006-04-25 Thread Hubert FONGARNAND





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)

2006-04-25 Thread Aras Pranckevicius

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

2006-04-25 Thread Chris Toshok

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

2006-04-25 Thread Chris Toshok

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

2006-04-25 Thread Marek Habersack

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

2006-04-25 Thread Chris Toshok

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

2006-04-25 Thread Gonzalo Paniagua Javier

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

2006-04-25 Thread Gonzalo Paniagua Javier

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

2006-04-25 Thread Hubert FONGARNAND

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

RE: [Mono-dev] System.Web.UI.Page patch

Re: [Mono-dev] DeadLock Problem in ASP.NET

[Mono-dev] Building mono under VS2003 (was: re: build mono under VS2005)

Re: [WARNING : A/V UNSCANNABLE] RE: [Mono-dev] System.Web.UI.Page patch

[Mono-dev] Re: [Mono-patches] r59521 - in trunk/mcs/class/System.Web: System.Web.Compilation System.Web.UI

[Mono-dev] [PATCH] Login control fixes

Re: [Mono-dev] [PATCH] Login control fixes

Re: [Mono-dev] Incorrect Directory.GetParent behavior

Re: [Mono-dev] DeadLock Problem in ASP.NET

Re: [Mono-dev] DeadLock Problem in ASP.NET

10 matches

Site Navigation

Mail list logo

Footer information