I’ll need this again at some point:"

public static HttpContext get_Current()
{ 
    return (CallContext.GetData("HtCt") as HttpContext); 
}

LInk: http://odetocode.com/Articles/112.aspx

The following demonstrates how to use the thread's current IIdentity that has been authenticated using Windows security (and therefore is a WindowsIdentity, and not a GenericIdentity), to perform an action beyond the rights of the current thread's User context (the ASPNET user):

//Impersonate an authenticated user:
using System.Security.Principal;
...
  //Will be ASPNET user:
  //Debug.WriteLine("Current User is {0}", 
  //WindowsIdentity.GetCurrent().Name);

  //Get the WindowsIdentity:
  WindowsPrincipal wPrincipal = (WindowsPrincipal)this.User;
  WindowsIdentity wIdentity = wPrincipal.Identity;

  //Get the context (it's IDisposable):
  using (WindowsImpersonationContext impersonationContext = 
    wIdentity.Impersonate(){

    //Will be impersonation:
    //Debug.WriteLine("Current User is {0}", 
    //WindowsIdentity.GetCurrent().Name);


  //...perform code that requires security Context
  //of authenticated user.
  
   //Not required when using 'using':
   //impersonationContext.Undo();
  }//Undo() & Dispose.

  //Will be ASPNET user:
  //Debug.WriteLine("Current User is {0}", 
  //WindowsIdentity.GetCurrent().Name);

                

Links:

• WindowsImpersonationContext Class
• Page.User Property (System.Web.UI)
• http://support.microsoft.com/kb/306158
• http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToImpersonateAUserGivenHerToken.html

Just parking for later:

http://igorinnet.blogspot.com/

Just parking a link to this:

http://www.cybertouch.info/website-design/aspnet-commonly-used-26-optimization-performance-method.html

Parking a link to a provocative article: http://gadgetopia.com/post/6509

And I also like the 3 other article links at the bottom of the page:

The End of the “PHP sucks” Argument

ASP.Net and the Confusion of GET and POST

The Needless Complexity of ASP.Net ***

If we are talking about the HttpApplication class, like the class that
Global derives from in IDE generated global.asax files, then there are
*multiple* instances of this class. They are kept in a pool, and one
instance is pulled from the pool and associated with a request during
it's lifetime, then returns to the pool.

The sequence that the global events are raised is expressed below:

uiButton.Attributes.Item("onclick") = 
    "this.disabled=true;" +
    GetPostBackEventReference(uiButton);

What we’re doing here is injecting a JScript disabled statement into the button’s onclick attribute, but we’re putting it before the jscript that is already there from the button’s normal postback behavior.

That’s all there is to it.

I would suggest encapsulating both these calls in a uscx, with 2 properties (destination page + window and drop the control on the page:

Using JScript:

body.Attributes.Add(
   "onLoad", 
   string.Format(
        "window.setTimeout(\"window.location.href='{0}'\",{1});",
    "login.aspx",
    (Session.Timeout * 60 * 1000) + (10 * 1000))
);

Using Refresh Meta Tag:

Response.AppendHeader(
    "Refresh", 
    string.Format("{0}; url=\"{1}\"”,
        Convert.ToString((Session.Timeout * 60) + 10),
        "login.aspx"
        )
    );

Further Reading:

Wikipedia: Refresh Meta Tag

Metas: general stuff

I'm touching up the XAct.Web.Controls.ListManager which uses some ClientSide script to manage the ICallBackHandler related stuff...which is not the point of this post.

The point of this post is that I'm using a single TextBox to PostBack a string of text:value;text:value;text:value pairs (the serialized text/value pairs within a ListBox), and when one sends back data like that one quickly runs in to the question of:

"What chars should I use for dividers?"

If you started coding around 2000A.D. you were breast-fed at the CSS udder, and the first set of chars that come to mind might be the ':' and ';' which would do fine for simple cases...but sooner or later,you would have to write a parser for more complex situations -- one that could handle quoted ':' and escaped chars...

If you go back before that, when VB6 and 5 were in vogue (cough!), you might prefer CSV stuff, so the next natural choices would be maybe ('\t' or ',') AND '|', and you still would get all lost in some kind of parser trying to handle exotic quotes, escaped quotes, etc...

Then if you're really old...when computers fit into ...well...my first computer had 1k of memory...so you couldn't even dream of fitting a parser into anything, and you just had to solve it a different way.

Enter ASCII (before it became un-PC to have any acronym start with the word "American") and you'll find these 4 chars:

FS, btw, was from even before my time, when things were on tape reels... I'm long in the tooth, but not that old...geez!

The point is...when transmitting data between computers, you don't have to have a human readable format: using non-printable chars means you don't have to worry about escaping or quoting or any other peculiarity.

Oh...and if you want to see what it was like back in the days of dinosaurs...you can download, and run (oh! the geek joy!) this fantastic job of a ZX-81 emulator...with pops, squeaks, and awful graphics...(you really had to be there to understand what was so damn great about it... 1 friggin K of memory! Yahoo!!!! )

I forget *ALL* the time...so I better write this done.

When writing a class (eg: SampleData) in an aspx's page that's not backed by a *.cs code, , and you want to refer to it from an ObjectDataSource, the TypeName is going to be...

Anyone? Anyone?

Its going to be in a namespace automatically generated by MS as ... ASP

And the class is going to be ...

Anyone? Anyone?

...the name of the file...

So, if you are writing in default.aspx page, and you haven't wired it up, it gets compiled as ...

namespace ASP {
...
  public class alphalistpicker3_aspx {
    ...
    public class SampleData {
      public string[] MySelect(){
      ...
      }
    }
    ...
  }
  ...
}

Voila...Voodoo in the machine... gives you a typename that is ASP.defautl_aspx.SampleData

I uploaded an article earlier this month that I slapped together from notes I found on my hard-drive as I was cleaning up.

As I put it up...I had a niggling feeling about it...that it was just plain wrong.

Turns out that I was right: I/it was wrong.

After doing a quick Investigation last night, I've re-written it to be hopefully right this time...

ASP- The Order in which ControlBuilder parses Declarative Tag attributes and nested tags 

Mea Culpa.

Just in case you missed this in the ASP.NET documentation...and you've been wondering how to use the controls i posted in the System.Web.Controls assembly page...

Also note that in v2.0, you can map multiple namespace/assembly pairs to the same tag prefix... so you could in fact use the tag prefix as sort of a brand identifier of sorts, even if you develop/ship multiple control assemblies

Nikhil Kothari

So its totally valid to:

<%@ Register  TagPrefix="XACT" 
    Namespace ="XAct.Web.Controls" 
    Assembly="XAct.Web.Controls.RepeaterII" %>

<%@ Register  TagPrefix="XACT" 
    Namespace ="XAct.Web.Controls" 
    Assembly="XAct.Web.Controls.XmlTransformer" %>
 
 

Which is why I now put each Control in its own assembly, unlike in the past when I had to decide what assembly to put a new control in, and it would take a long time to compile the whole assembly even though there was just one little change...

I don't do this enough to remember it when I need it...

<%--
   <XACT:XButton runat="server" id="myButton"></XACT:XButton>
--%>

The Default Behaviour: WebControls are Spans

The default behaviour for all custom controls are that they are wrapped in a Spans.
This is because all controls inherit from System.Web.UI.Control, and inherit its TagKey code, which defines that all Controls are wrapped in Spans:

protected virtual HtmlTextWriterTag TagKey {
    get { return HtmlTextWriterTag.Span; }
}

protected override HtmlTextWriterTag TagKey {
    get { return HtmlTextWriterTag.Div; }
}

Comparing the Two:

Spans

1. SPAN elements have 'display:inline' elements, which mean
2. Subsequent Sibling tags are rendered to the right.

Divs

1. DIV elements have 'display:block' elements, which mean
2. Subsequent Sibling tags are rendered after a BR tag is inserted.

The official w3 specs (at http://www.w3.org/TR/REC-CSS2/visuren.html#normal-flow) are:

9.4.2 Inline formatting context
In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block. Horizontal margins, borders, and padding are respected between these boxes. The boxes may be aligned vertically in different ways: their bottoms or tops may be aligned, or the baselines of text within them may be aligned. The rectangular area that contains the boxes that form a line is called a line box. The width of a line box is determined by a containing block. The height of a line box is determined by the rules given in the section on line height calculations. A line box is always tall enough for all of the boxes it contains. However, it may be taller than the tallest box it contains (if, for example, boxes are aligned so that baselines line up). When the height of a box B is less than the height of the line box containing it, the vertical alignment of B within the line box is determined by the 'vertical-align' property. When several inline boxes cannot fit horizontally within a single line box, they are distributed among two or more vertically-stacked line boxes. Thus, a paragraph is a vertical stack of line boxes. Line boxes are stacked with no vertical separation and they never overlap.

This means the following:

Spans

Pros

1. Good for Form elements (INPUT based controls)

Cons

1. Borders applied to SPAN elements propagate to its children. No idea why this happens:
   Line 1 that with no border inside span that has border
   Line 2 that with no border inside span that has border
   Line 3 that with no border inside span that has border
   
   
2. the CSS as a boundary -- but are inherited by its children:
   HELLOLine 1 ...
   Line 2 ...
   Line 3 ...
   
3. SPAN tag doesn't act as a visual box.
4. The don't take up any more space than needed, which is not
5. so useful when laying it out in a page framework of table cells:
   Span CSS rules are not applied to

   Col Left (100px)	Center Col	Col Right (100px)
   Diddlededum...	Hello: Line 1 ... Line 2 ... Line 3 ... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... TableCell... Total Garbage	Diddlededum...

Divs

Whereas Divs have the following:

Pros

1. Borders applied to DIV don't go off and pollute its children:

Cons

1. But they do stretch to 'width:100%' of container control unless a width is defined:

Conclusion:

This is tentative, but...CompositeControls cannot possibly be made wrapped by a span -- unless we are talking about applying no styles to it.
Since 98% of the controls I make are CompositeControls, it means I override TagKey a lot.

I just found this in my notes within XAct.Web.Core and thought it might help someone:

The bare minimum of the lifecycle is:
* Page.PerformPreInit
* Page.OnPreInit
* Page.InitializeThemes
* Page.ApplyMasterPage
* Page.InitRecursive
  * Control.OnInit  (starting from deepest first)
    [this.Page.PreLoad += new EventHandler(this.OnPagePreLoad);]
    [if (this.Page.IsPostBack && !base.IsViewStateEnabled){
      this.RequiresDataBinding = true;
      }
    ]
      [EnsureDataBound]
        [if (!string.IsEmptyOrNull(this.DataSourceID)){DataBind();}]
          [DataBind]
            [BaseDataBoundControl.PerformSelect]
  * Control.TrackViewState (starting from deepest first)
* Page.InitComplete
* Page.LoadViewStateRecursive
  * Control.LoadViewState (starting from page down)
* Page.ProcessPostData[1]
  * Control.FindControl
    * Control.EnsureChildControls
      * Control.CreateChildControls
* Page.PreLoad
  * [OnPagePreLoad]
    * [if (!this.Page.IsPostBack){base.RequiresDataBinding = true;}]
        [EnsureDataBound]
          [if (!string.IsEmptyOrNull(this.DataSourceID)){DataBind();}]
            [DataBind]
              [BaseDataBoundControl.PerformSelect]
* Page.LoadRecursive
  * Control.OnLoad (top down)
    * [if (!this.Page.IsPostBack){base.RequiresDataBinding = true;}]
* Page.ProcessPostData [2]
  * Control.FindControl
    * Control.EnsureChildControls
      * Control.CreateChildControls
* Page.RaiseChangedEvents
* Page.RaisePostBackEvent
  * Control.Click!
* Page.OnLoadComplete
* Page.Validate
* Page.PreRenderRecursive
  * Control.EnsureChildControls/
    Control.CreateChildControls/
      Control.OnPreRender (top down)
        [EnsureDataBound]
          [if (!string.IsEmptyOrNull(this.DataSourceID)){DataBind();}]
            [DataBind]
              [BaseDataBoundControl.PerformSelect]
* Page.PerformPreRenderComplete
* Control.SaveViewState (top down)
* Page.RenderControl
  * Control.Render (top down)
* Unload
* Dispose
 

Not that this should be important...but it is interesting...

http://www.asp.net/get-started/

Read this:

http://www.sitepoint.com/article/aspnet-performance-tips

An summary of an interesting report can be found at http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

It comes from a more complete PDF that I tracked down at http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9652/30543/01408754.pdf

Its got nice nuggets of data such as

<<<

Sun Microsystems' Java Pet Store J2EE BluePrint Application

A team of 2 developers rebuilt the “Sun Microsystems' Java Pet Store J2EE BluePrint Application” using .Net in 4 weeks with 25% of the code.  When tested in a lab, the .Net application ran %1000 faster than a tuned version of the Java application.  The same Pet Store application was rebuilt by both Microsoft and Sun for an independent competition sponsored by The Middleware Company.   Below is a comparison of the results:

	.Net 1.1/Windows 2003	J2EE/Windows 2000
Lines of Code	2,096	14,004
Time required for tuning and optimization prior to performance test	2 man-weeks	10 man-weeks
Price/Performance Ratio – the cost per server divided by the maximum transactions per second the server could handle	$316 – in other words, for a Java application to handle the same amount of website traffic as a .Net application, and additional $989 would need to be spent on server hardware.	$1,305
Maximum Pages served per Second	1,400	600
Maximum Number of Concurrent Users	6,000	4,000
Maximum Number of Transactions per Second	117	59

Test Notes: Each application was executed on identical Compaq Proliant servers; J2EE was tested on>>>

Read this: http://discuss.joelonsoftware.com/default.asp?joel.3.310309.25

I think I could really have used these links last year:

http://blogs.msdn.com/robburke/archive/2005/11/17/494105.aspx

I found this page which I think will answer questions: http://www.pnpguidance.net/Tag/ModelViewPresenter.aspx

Especially, ASP.NET MVC Framework Compared To Web Client Software Factory ( WCSF )

Just found this handy online tool to convert any image to an *.ico file suitable for your websites:

http://www.html-kit.com/favicon/

Quick, simple, works. Voila!

Well look at that...Nice diagram! I could have really used this 3 years ago!

ASP.NET 2.0 page life cycle

Recently, I had to decide how I was going to package up my Server Controls, so that they all shared common code. One option was to package everything in one dll, but thiRecently, I had to decide how I was going to package up my Server Controls, so that they all shared common code.
One option was to package everything in one dll, but this would end up as one big stinkin dll.

Setting up...

To setup the test rig I did the following, I create 3 WebControl projects in C# Express:

using System.Web.UI.WebControls;
ControlA : Button {
    public ControlA : base(){
        this.Text = "ButtonA";
        this.Title = "No External Dll's";
    }
}

using System.Web.UI.WebControls;
ControlA : Button {
    public ControlB : base(){
        this.Text = "ButtonB";
        this.Title = "Using XAct.Web in code -- but NOT in constructor...";
    }
    public void Test(){
        //Use any arbitrary method in external assembly:
        this.Text = XAct.Utils.Strings.PCase(this.Text);
    }
}

using System.Web.UI.WebControls;
ControlA : Button {
    public ControlB : base(){
        this.Text = XAct.Utils.Strings.PCase("ButtonB");
        this.Title = "Using XAct.Web in constructor...";
    }
}

The first project's bin directory was empty of course, but the bin directory of the second and third projects both had a copy of XAct.Web.dll
in it.

My question was, what was going to happen in the IDE?

I then opened Visual Web Developer Express, and created a new website.

My ToolBar had no mention of these 3 controls, so I first created a new Tab to contain them, and then added them by

• clicking 'Choose Items...'
• navigating to the d:\Projects\ProjectA\bin\ directory to select the TestControlA.dll that contained ControlA.

I repeated the process for all 3 projects.

At this point, The Tab showed the icons of 3 controls that I had never used.

Before getting started I checked the bin directory: it was empty with no local copies of any external assemblies.
I then created a new page, and dragged an instance of ControlA onto the page, then checked the bin directory. The bin directory now had
a reference to ControlA.dll - exactly what I wanted.

I then did the same with ControlB. This time, the bin showed ControlB.dll AND XAct.Web.dll. Fantastic -- it actually went through ControlB.dll's
manifest and saw that it relies on other dlls, and imported them. To be sure, I retested by putting some other dll (XAct.GUI.Fonts.dll) in the
same dir as ControB.dll, and tried again, and it imported System.Web.dll, but ignored System.GUI.Fonts.dll, which is exactly what is needed).

My last question, was how far did it recursively go down looking for dependancies?
I double checked, using an in between assembly called XAct.WrapCommon.dll that referenced XAct.Common.dll -- and lo and behold, it did bring
in XAct.WrapCommon.dll AND XAct.Common.dll -- so it didn't just stop at the top dll.

Whew!

What about version numbers?

To see what would happen with different version numbers, ControlC refered to WrapCommon, which referenced XAct.Common.dll with a version id of 1.1
whereas XAct.Common.dll referenced an XAct.Common.dll with version 1.0.

If I imported Button3, then Button2, it noticed that Button2's XAct.Common dll was different and asked me if I want to overwrite it.
WARNING: The prompt is very unclear on this...

If I reverse the order (add Button2 then Button3, it prompts the same thing...) so it is that one version number is different than another,
but that they are not the same.

I tried again with the same dll in both -- and it still asked me if I wanted to overwrite the first XAct.Common.dll with the second. The only
conclusion is that this is

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp
"Note   There is no version checking for assemblies without strong names, nor does the runtime check in the global assembly cache for assemblies without strong names."

http://www.7hertz.com/archives/2004/03/build_revision_numbering_scheme.html