Hristo Deshev's blog

RadControls for WPF -- Now with Filtering Support

Hristo Deshev — Wed, 02 Jul 2008 10:49:00 GMT

Boy, am I excited! We managed to push our second public beta out of the door, getting ready for the big Q2 release. Here is what's new:

I am especially proud with the new filtering support in RadGridView. We designed the feature so that it would both allow you to plug your own filtering logic and have a cool default UI that will let your users quickly filter the grid. An image is worth more than a thousand words, so here it goes:
RadCarousel got even fancier. Check those reflections:
We got several new controls, freshly-ported from the upcoming Silverlight control suite: RadNumericUpDown, RadProgressBar, RadSlider, RadPanelBar, RadTreeView.

Need I say more? Go play with the beta! The live examples (XBAP) are available here. The download should be available from your Client.NET page.

Of course, all type of feedback is welcome. Share it in the forums or in a suppor ticket.

Launching a new blog

Hristo Deshev — Mon, 03 Sep 2007 16:00:00 GMT

I am pleased to announce that I am starting a new web development-oriented blog. I have been honored (Thanks, Joe!) to blog on weblogs.asp.net and I think that, after several years of active development on our ASP.NET control suite, I have something to say about web development.

What will happen with this blog? Don't worry, I will keep posting interesting stuff here too. I am just trying to separate the general ASP.NET content from control development and Telerik-related news and announcements. What is the best way to stay on top of everything happening in my world? Go ahead and click the RSS or ATOM links for my new blog.

See you soon!

Firewalls breaking ASP.NET AJAX!

Hristo Deshev — Sun, 24 Jun 2007 16:00:00 GMT

This one is serious and may bite you any time.

Yesterday Shaun posted this problem in our forums: he and his users were experiencing odd errors when requesting ASP.NET AJAX-based sites, and yes, that means RadControls "Prometheus" based ones as well. Partial rendering requests initiated by UpdatePanel controls failed with the cryptic message:

==============
Sys.WebForms.PageRequestManagerParserErrorExeption: The message received from the server could not be parsed.� Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.� Details:� Error parsing near '<!DOCTYPE html P''.
==============

Of course all that comes without any trace of Response.Write(), HttpModule, response filter or server-side tracing in his code. The horror, the horror...

Having the luxury of being a part of a team that has implemented a framework similar to ASP.NET AJAX, I noticed that something was making ASP.NET AJAX render the entire page and return it back to the browser even when the server code was supposed to be handling a partial rendering request. Note my emphasis (the bold part is the beginning of a normal HTML document):

==============
Sys.WebForms.PageRequestManagerParserErrorExeption: The message received from the server could not be parsed.� Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.� Details:� Error parsing near *****'<!DOCTYPE html P''******.
==============

I dug a bit deeper using the .NET documentation browser (Reflector), trying to find out how ASP.NET AJAX "knows" when to let the page render itself and when to intercept the normal rendering and send the updated UpdatePanels' contents only. The answer is simple: the client code sets a special HTTP header that gets read by the server. The header is "X-MicrosoftAjax" and its value is� "Delta=true". Then it dawned on me that some firewall "solution" may be stripping or tampering with that header. Shaun confirmed this: his company is using a Watchguard router that has this setting of "Remove Unknown Headers". Disabling that, made the problem disappear.

I believe the Watchguard guys should get the X-MicrosoftAjax header into their known headers list pretty quick. Until they do, please disable that setting. I think they are not the only firewall solutions provider that may have this problem.� Are you behind a header-stripping firewall? Please post a comment below! I don't mean corporate solutions only -- personal firewalls can do that as well. The bigger list we have, the greater chance of sparing somebody a tough problem.

On the other hand, is there a good reason for a firewall to strip your HTTP request headers? All I can think of is the age-old sysadmin principle of "Disable all that your users don't need, and then go ahead and disable some more."

Claiming my Technorati blog

Hristo Deshev — Thu, 31 May 2007 01:43:00 GMT

Technorati Profile

TechEd 2007, here we come!

Hristo Deshev — Wed, 30 May 2007 16:00:00 GMT

I am posting this literally minutes before heading to the airport. I, Vassil, Atanas, Vlad, and several blogless people (hint! hint!) are leaving for the US today. Todd will be joining us too!

Come visit us at booth #515. We are delighted to meet you, have a little chat and demo the latest developments on the ASP.NET controls, Sitefinity, WinForms, Reporting, and Silverlight fronts.

Meet you there!

Ubiquitous: a funny word that unearths some PowerShell trivia

Hristo Deshev — Wed, 30 May 2007 16:00:00 GMT

Do you think that the word "ubiquitous" can be hard on a non-native English speaker's ears. It is hard for Bulgarians, that I am sure. I picked it for the title because I really like its the strangeness and because it has a nice allusion to the software development best practice of automating everything that you get your hands on: tests, build procedures, and deployment. You need that to gain predictability in your project and ensure rapid and often delivery of new features.

What surprised me was Jeffrey Snover's (yes, the architect behind PowerShell) comment about the original use of the word with regard to the PowerShell cmdlets (emphasis mine):

=================
I'll buy any book that has the word PowerShell or Ubiquitious in it.

FYI - our "common" parameters are called "common" because the doc people thought we would confuse people by calling them "ubiquitous" parameters. I had been calling them that for years prior to the switch. It's such a wonderful word.

Best of luck with the book. It sounds like it will be a good addition to the pool. It feels like it is going to be in that 2nd generations of books that focuses in on HOW TO USE PowerShell to accomplish a goal vs WHAT IS PowerShell. Both are super important.

Cheers!
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

=================

By the way, if you are not aggregating the Windows PowerShell Team blog, please do it now and start getting your daily dose of useful tips and techniques.

I am writing a book!

Hristo Deshev — Tue, 29 May 2007 16:00:00 GMT

Yes I am! I can finally announce that and I am sooo excited! I have been working with the Apress guys, most importantly Jonathan Hassell, on starting an intermediate-level book on Windows PowerShell (formerly known as Monad). We have finished the book proposal checklist (a huge one, mind you) and it got approved. I am now off to finishing the paperwork related to contracts and other boring stuff and I have already started writing.

The book is tentatively titled Ubiquitous Automation with Windows PowerShell. I am an automation freak and I want to help everyone in the world reap the benefits of becoming one themselves! Software developers, system administrators and, I believe, all power users out there will enjoy a better scripting environment that fully supports the Windows environment and the .NET runtime. PowerShell makes managing processes and services, querying networks, taming file management, and automating program deployment a no-brainer. Doing that effectively is the most important thing I will be showing throughout the book. It will focus on learning useful scripting techniques as quickly as possible and getting real value early on. A unique "feature" of the book is that it will not only cover the shell itself, but it will introduce important tools and libraries that will boost your productivity. Not only we have a �ber-powerful shell, but we already have available helpers, IDEs, even debuggers at our disposal. The PowerShell community on the web is growing and it is covering a lot in using the shell to administer and automate all sorts of systems and software. Reinventing the wheel is not fun and one of the book's goals is to help you use the existing, working round wheels instead of creating your own square ones.

Writing a book has many challenges. One of them is to provide useful content that is not "just another book on the subject." There are several books on PowerShell on the shelves already and some more that will be out soon. Two of the books are written by members of the PowerShell development team! That raises the bar significantly and I am delighted in playing in the same league with those guys. I am sure my passion for tools and bullets of a very shiny material will bring a unique perspective that will complement the existing work in this field.

I have the deadlines set already. I should be done submitting the first three chapters by July 15. This is where I show that I am a serious and dedicated author that will be able to deliver on time. The tentative title and table of contents will get finalized some time after that. My final manuscript submission deadline is November 30, and the book will hit the shelves circa January 2008. I am planning on blogging my progress as I work on the book and provide regular updates. Stay tuned for a lot of PowerShell action and Windows automation black magic.

RadInput 2.0 and Date Parsing: Where Compiler Theory Meets User Needs

Hristo Deshev — Fri, 20 Apr 2007 11:46:00 GMT

Todd beat me to releasing details on our Q1_2007 release, but here it is again: we are finally releasing an update to the RadInput product: RadInput 2.0!!! The new version will include three brand new controls:

RadTextBox: a nice, skinnable <asp:TextBox> replacement control that will help you build slick-looking applications;
RadNumericTextBox: a textbox control, specifically created for numeric data entry: think quantities, currency, percentages;
RadDateInput: a completely rewritten version of the v1.x RadDateInput control that takes a different approach to date entry.

My favorite is RadDateInput as it posed one of the biggest challenges I have met in my work here at Telerik: building a non-restrictive, assistive date input control. The 1.x version of the component would hurt users' feelings by being too restrictive. It would insist on slapping your wrists the first time you would hit the wrong key.

This time we have learned our lesson! We felt that the best approach here is to give the user absolute freedom at entering whatever s/he feels is a correct date. We would then take that and parse it into something meaningful. But how do we do that reliably enough? How do we help users that want us to recognize dates like "1.1.07", "2007-Jan-1", "January 1, 2007", "1/1/07"? How do we handle time entries both all by itself, and accompanied by a date? This is where we found out handling all this with a ton of if-then-else statements would be close to impossible and even if we succeeded we would have never been able to add a feature on top of the first release. That is when somebody asked "can we express all this with a formal grammar!" We toyed with the idea a bit, tried stuff out in the small, and then... just did it. Keep reading to find out how.

Right now RadDateInput features a full-blown lexer, and a recursive-descent parser that implement the date recognition. In total we have three components involved in date parsing and evaluation:

The lexer. This guy splits the string into well known tokens: it looks for separators, numbers, week days, month names (both in full and abbreviated, all culture-specific), time values, AM/PM designators. The result that we get after the lexer finishes is a stream of tokens.
The parser. Here we do not work with raw strings anymore: we deal with tokens and apply the grammar productions to recognize if we are dealing with a number-month pair, a full date triplet, a week day, just an hour-minute-seconds time entry, etc. Some of the grammar, expressed in BNF, might look like this:
DATETRIPLET ::= NUMBER DATEPAIR
DATEPAIR ::= NUMBER NUMBER |
NUMBER MONTH |
MONTH NUMBER
We use rules like the above to produce a tree structure that represents our date and time entry.
The evaluator. This is where we take the number, month, week day, hours, minutes, etc tokens and apply rules and heuristics, taking into account both the specified date format and the current culture to get to the final date. For example if we get a number pair, we would look if the current culture usually specifies dates as month-day or day-month and will respect that. We will do the right thing and will assign values accordingly if we can infer something in addition, say "30 4" is obviously April 30, no matter if you write it as "30 4" or "4 30".

I am really pleased with the final result: we easily handle a myriad of possible input combinations without sacrificing flexibility. The most important thing for us is that the parser is really extensible, and we can extend it by adding advanced rules for things like "+2hrs" or "next Friday" in the future. We will be expecting your feedback on this one :-).

I and the entire team are really proud of the product and we are sure this little control will be of great help to many people. Happy data entry!

Security: JSON Hijacking and the telerik web controls

Hristo Deshev — Wed, 04 Apr 2007 18:56:00 GMT

I have been too slow to get to this! The security experts at Fortify Software have recently discovered a new Web 2.0-specific security vulnerability that may affect some sites passing JSON-encoded data to the client, and I got some nudges from both coworkers and customers to investigate this deeper.

So, what is this vulnerability all about?

In short, you have to be extra careful when using HTTP GET requests to stream JSON-encoded data to the client. You may be thinking that you are using ASP.NET's authentication mechanism and you are conveniently hidden behind the session and forms authentication cookie, but that may not be the case. Imagine that there is an HTTP handler that will serve GET requests and return JSON to the client. The client is your secured ASPX page and you can't get to it without passing through the login page. The JSON handler checks if the user is authorized before sending the data too. But what happens if a malicious site tricks you into visiting it after you have visited the trusted site? That malicious site can request data from the JSON handler if it knows the correct URL. URL's are not hard to guess and remember, you are coming from the trusted site, so you have an authentication cookie set. That means the malicious site can read your mail, get to your files, and do even nastier stuff.

Normally you can't request URL's from a different domain using an XMLHttpRequest object -- the browser just won't let you. You can't access frames that host documents from another domain either. All that is a part of the "Same Origin Policy" that ensures that you are to touch stuff coming from your own domain only. There is a way to circumvent that policy though! You can insert a <script> tag with a "src" attribute pointing to another domain. You can get only scripts from that domain, but JSON-encoded data is valid JavaScript that can be accessed after being pulled in the attacker's document.

Am I vulnerable?

Your site is vulnerable if it allows streaming JSON data from HTTP GET requests without taking extra measures to prevent requests from unauthorized locations. The extra measures can be really simple: you can inject something that will make the script invalid and unparseable and then strip it on the client before evaluating that or you can switch to POST requests or add extra HTTP request headers and check if the headers are present on the server.

Are telerik's controls exploitable?

You face some risk when using RadTreeView and RadComboBox and their LoadOnDemand feature. Those controls do HTTP GET requests and an attacker can use the mechanism above and get the text contents of your tree nodes and combo items. If you are displaying sensitive data in there, please disable that feature, and contact our support guys. They will get you a hotfix build that has this security hole closed.

The rest of the controls do HTTP POST requests and are not exploitable.

Debugging ASP.NET 2.0 Web Resources: Decrypting the URL and Getting the Resource Name

Hristo Deshev — Mon, 26 Mar 2007 19:25:00 GMT

Today I had another trivial problem that was unbelievably hard to debug just because I could not tell that an error caused by a web resource was caused by exactly that resource. I was dealing with a forgotten [WebResource] attribute that did not have a matching resource built in the assembly and both generated a server side exception and gave browsers a 404 HTTP error.

I wanted to decrypt the query string data that was being passed to WebResource.axd and extract the resource and assembly name from it. MSDN told me that what I needed was the "d" query string parameter, as it contained the encrypted assembly and resource name. The "t" attribute is the assembly time stamp, it is there, so that we have a different URL when we upgrade the assembly and our clients do not cache and use the old web resources.

Back to decrypting that string. I noticed that it was being encrypted using the MachineKeySection.EncryptOrDecryptData() method, so we can easily decrypt that. Unfortunately, the method is declared internal. That should not be allowed to stop us, should it? Here goes the code:

=======================================

        byte[] encryptedData = HttpServerUtility.UrlTokenDecode(urlEncodedData);

        Type machineKeySection = typeof(MachineKeySection);
        Type[] paramTypes = new Type[] { typeof(bool), typeof(byte[]), typeof(byte[]), typeof(int), typeof(int) };
        MethodInfo encryptOrDecryptData = machineKeySection.GetMethod("EncryptOrDecryptData", BindingFlags.Static | BindingFlags.NonPublic, null, paramTypes, null);

        try
        {
            byte[] decryptedData = (byte[])encryptOrDecryptData.Invoke(null, new object[] { false, encryptedData, null, 0, encryptedData.Length });
            string decrypted = Encoding.UTF8.GetString(decryptedData);

            decryptedLabel.BackColor = Color.Lime;
            decryptedLabel.Text = decrypted;
        }
        catch (TargetInvocationException)
        {
            decryptedLabel.BackColor = Color.Red;
            decryptedLabel.Text = "Error decrypting data. Are you running your page on the same server and inside the same application as the web resource URL that was generated?";
        }

=======================================

The tricky part is that we use the MachineKeySection class to do our job and we deal with encryption settings specific to the current application. This means that decrypting web resource URL will work if and only if you run the code on the same server and from the same web application that generated the resource.

I am attaching a standalone page that you can drop in your application's root and request it. You can then paste a web resource URL in the text box and decrypt it. You can even drop controls on the page and the dropdown will be automatically filled with all registered scripts and stylesheets served from web resources. Happy hacking!

WebDD: slides and demo code

Hristo Deshev — Tue, 06 Feb 2007 23:05:00 GMT

As promised earlier, here are the slides and the sample code from my WebDD talk.

The code builds an image slide show control and an extender that will zoom its target in on mouse hover and zoom out on mouse unhover doing that with a fancy animation stolen from the AJAX Control Toolkit. Some info that you may find useful when reading the code in no particular order:

The ScriptControls project is the real control library. It contains the JavaScript and server-side controls and is being used by some of the pages in the demo site (ImageSlideShowServer, ImageSlideShowUpdatePanel, HoverZoomExtender).
The DemoSite project is well... a demo site. It contains several pages that have the JavaScript code in different stages of its development. All *.aspx files have their corresponding code-behinds in *.aspx.cs and their accompanying script files in *.aspx.js:

ImageSlideShowEmptyClass: this one shows a simple class that inherits from Sys.UI.Control.
ImageSlideShowDispose: here we demonstrate resource disposal triggered both by a window close and an update panel refresh. I've kept the JavaScript error you saw on the demo, so that it reminds me to be more careful in the future. It is caused after an update panel refresh when our code tries to recreate both controls and ASP.NET AJAX complains that you can't have a control for a DOM element that already has a control attached (We should not recreate the control outside the update panel).
ImageSlideShowEvents: here we have code that handles DOM events using the $addHandler() API and in turn raises a custom component event that is handled by a plain JavaScript object living on the page.
ImageSlideShowServer: the working server control. Look, Ma, no JavaScript!
ImageSlideShowUpdatePanel: the server control, happily living in an UpdatePanel.
HoverZoomExtender: an image of a pair of lazy pandas chewing at bamboo sticks being extended to provide a zoom in animation on hover.

You can extend the ImageSlideShow control by adding an extender for every image. Just add this code to the end of the AddSlide() method:

////////////////////////////////////////////////
HoverZoomExtender imageZoomer = new HoverZoomExtender();
imageZoomer.ID = imageID + "ZoomExtender";
this.Controls.Add(imageZoomer);
imageZoomer.TargetControlID = slideImage.ID;
imageZoomer.ZoomFactor = 1.5;
////////////////////////////////////////////////

That's it! Happy coding!

WebDD - pure web dev enjoyment

Hristo Deshev — Tue, 06 Feb 2007 00:41:00 GMT

Last Saturday was quite an eventful day! Me and Zhivko attended the WebDD conference in Reading, England, and I have been meaning to post a small review about the entire thing.

The sessions I attended were really great. This was my first time seeing Scott Guthrie present and I can only say that he's a real presentation machine. He gave 4 talks in a single day and then repeated one of them, so that people that did not have the chance to attend it could do so. I watched Dave Verwer give an incredible talk on writing unobtrusive JavaScript or script that works when it can and leaves your site usable for browsers with scripting disabled. I got some really cool ideas on improving the radControls suite! Glenn Jones really impressed me with his microformats presentation. While I already knew the concept, I could not think of anything usable that you could build with microformats. The presentation was a real eye opener.

I gave a presentation about developing ASP.NET AJAX components. I have been playing with the new framework for quite some time and I wanted to share my experience in creating client-side controls and behaviors as well as using them on the server via script controls and extenders. My opinion is that both ASP.NET AJAX controls and behaviors are a good addition to a web developer's bag of tricks and having them at your disposal can significantly decrease the time to ship a complex web app. I am posting my slides and demos tomorrow, right after I dig my USB thumb drive out of my suitcase (talk about late packing and unpacking).

Speaking at WebDD was one of my first presentation engagements, and I still can't just be myself before many people. As some people noticed, I was quite nervous about standing in a crowded room, but I hope I managed to show some cool stuff that aroused some interest in ASP.NET AJAX-style JavaScript. I have gotten some feedback that the tech content is too heavy for a short presentation, and I think I should be splitting it in two: maybe script controls vs. behaviors/extenders. Having more examples and covering some of the trickiest parts in greater detail should definitely make the matter accessible to a broader public.

As a conclusion I would really like to thank Dave and Phil for a great event. Adding Zi's geek dinner made that Saturday unforgettable. I am really looking forward to meeting you all, folks, again!

Oops! Almost forgot about the photos! Check out Dave's photostream!

WebDD: I'll be there

Hristo Deshev — Thu, 18 Jan 2007 13:25:00 GMT

I am very excited to spread the news: I will be presenting at the WebDD conference. I am giving a talk on developing ASP.NET AJAX components -- one of my pet projects for some time now. Wait! There's more: Zhivko, our usability master and design guru will have a session on usability testing. Don't miss it out!

I am looking forward to meeting a lot of interesting people at WebDD. I have registered at the backnetwork and signed up for the geek dinner Zi is organizing. Talking about JavaScript is waaay easier after 2 beers!

The Book! Finally Out!

Hristo Deshev — Thu, 04 Jan 2007 06:13:00 GMT

I just have to brag about this one! I have been contributing articles for the Windows Developer Power Tools book. The book project has been lead by Jim Holmes and James Avery and I have been brought in by Mr. Holmes. I started writing my first article some time in January last year (if I remember correctly), and I am now extremely glad that the wait is over and I can see my work being published.

The book is a collection of articles and recipes about using 170+ free and open-source tools that can boost your developer productivity on any Windows and .NET project. I am sure that even knowing about those tools' existence will help each and every programmer out there with his/her career.

I have contributed a total of three articles (listed in the order of their writing):

Eliminating Memory Leaks in Internet Explorer with Drip -- the first article. This is the piece of work that made me dig deeper into the dreaded memory leak problem under that browser. Writing this article has meant so much for me: I contacted Matthias Miller, a really nice person, a very gifted programmer, and the maintainer of the Drip project; I got to learn a lot of stuff about the memory leaks problem under IE and managed to improve a lot of our ASP.NET products; I even registered as a developer on the Drip open source project (even if I did not find the time to contribute that much to the project)
Building Sophisticated AJAX Applications with ASP.NET's Atlas -- the article is a bit outdated right now as it is based on the MS AJAX (formerly known as Atlas) CTP's and the product has changed a lot since the first beta release. Anyway the info there is still useful as an introduction to the spirit of the framework.
PowerShell - a New Generation Command Line and Scripting Tool -- my favorite! PowerShell is a really nice addition to the Windows toolbox and every person can benefit from knowing it. The shell combines the power of the traditional UNIX shells with a full-fledged programming language that gives you access to virtually any object on your system: WMI, COM, .NET, you name it. cmd.exe is dead, long live PowerShell.

You can look at the table of contents and read the sample chapters online. Jim, thank you for bringing me aboard! I enjoyed the project and I would do it again any day.

UPDATE: fixed a sexist-sounding part born by the part of my brain that does its thinking in Bulgarian

HACK: debug modifications to the ASP.NET session

Hristo Deshev — Tue, 21 Nov 2006 16:00:00 GMT

Today I had some strange experience.� I have been hunting a strange bug that caused something to be placed in the ASP.NET session at a time that it was not supposed to be.� My biggest problem was finding out who was putting an object in the session and what that object actually contained.

I already knew that the HttpSessionState instance was being stored in the current HttpContext's Items collection (thanks to Mr. Lutz Roeder, of course), and my initial plan was to inherit from HttpSessionState and intercept the calls made to methods like Add, Remove, etc.� Alas, HttpSessionState is marked as sealed, and none of its methods is virtual.

And then I found it!� Every HttpSessionState object takes a storage parameter on its creation -- an IHttpSessionState implementor.� All I had to to was create an object that implements this interface, and pass it to a new HttpSessionState instance.� My interface implementation simply delegates everything to the real HttpSessionState instance.� Here is how to replace the built-in session object.� Note that we need some reflection to call the internal constructor:

protected override void OnPreInit(EventArgs e)
{
�� HttpSessionState session = HttpContext.Current.Session;
�� Type[] parameters = new Type[] { typeof(IHttpSessionState) };
�� ConstructorInfo constructor = session.GetType().GetConstructor
�� (BindingFlags.Instance | BindingFlags.NonPublic, null, parameters, null);

�� object[] paramValues = new object[] { new FakeSessionState(session) };
�� HttpSessionState fakeSession = (HttpSessionState)constructor.Invoke(paramValues);

�� HttpContext.Current.Items["AspSession"] = fakeSession;

�� base.OnPreInit(e);
}

I replace the session object for my page only.� It should be possible to do that for the entire application with an HttpModule or something, but all I needed was troubleshooting a single page.

Here is my FakeSessionState class.� I can set breakpoints in its methods, debug it, log method calls, etc:

public class FakeSessionState : IHttpSessionState
{
�� HttpSessionState _realSession;
�� public FakeSessionState(HttpSessionState realSession)
�� {
�� _realSession = realSession;
�� }

�� #region IHttpSessionState Members

�� public void Abandon()
�� {
�� _realSession.Abandon();
�� }

�� public void Add(string name, object value)
�� {
�� _realSession.Add(name, value);
�� }

�� public void Clear()
�� {
�� _realSession.Clear();
�� }

�� public int CodePage
�� {
�� get
�� {
�� return _realSession.CodePage;
�� }
�� set
�� {
�� _realSession.CodePage = value;
�� }
�� }

�� public HttpCookieMode CookieMode
�� {
�� get
�� {
�� return _realSession.CookieMode;
�� }
�� }

�� public void CopyTo(Array array, int index)
�� {
�� _realSession.CopyTo(array, index);
�� }

�� public int Count
�� {
�� get
�� {
�� return _realSession.Count;
�� }
�� }

�� public System.Collections.IEnumerator GetEnumerator()
�� {
�� return _realSession.GetEnumerator();
�� }

�� public bool IsCookieless
�� {
�� get
�� {
�� return _realSession.IsCookieless;
�� }
�� }

�� public bool IsNewSession
�� {
�� get
�� {
�� return _realSession.IsNewSession;
�� }
�� }

�� public bool IsReadOnly
�� {
�� get
�� {
�� return _realSession.IsReadOnly;
�� }
�� }

�� public bool IsSynchronized
�� {
�� get
�� {
�� return _realSession.IsSynchronized;
�� }
�� }

�� public System.Collections.Specialized.NameObjectCollectionBase.KeysCollection Keys
�� {
�� get
�� {
�� return _realSession.Keys;
�� }
�� }

�� public int LCID
�� {
�� get
�� {
�� return _realSession.LCID;
�� }
�� set
�� {
�� _realSession.LCID = value;
�� }
�� }

�� public SessionStateMode Mode
�� {
�� get
�� {
�� return _realSession.Mode;
�� }
�� }

�� public void Remove(string name)
�� {
�� _realSession.Remove(name);
�� }

�� public void RemoveAll()
�� {
�� _realSession.RemoveAll();
�� }

�� public void RemoveAt(int index)
�� {
�� _realSession.RemoveAt(index);
�� }

�� public string SessionID
�� {
�� get
�� {
�� return _realSession.SessionID;
�� }
�� }

�� public HttpStaticObjectsCollection StaticObjects
�� {
�� get
�� {
�� return _realSession.StaticObjects;
�� }
�� }

�� public object SyncRoot
�� {
�� get
�� {
�� return _realSession.SyncRoot;
�� }
�� }

�� public int Timeout
�� {
�� get
�� {
�� return _realSession.Timeout;
�� }
�� set
�� {
�� _realSession.Timeout = value;
�� }
�� }

�� public object this[int index]
�� {
�� get
�� {
�� return _realSession[index];
�� }
�� set
�� {
�� _realSession[index] = value;
�� }
�� }

�� public object this[string name]
�� {
�� get
�� {
�� return _realSession[name];
�� }
�� set
�� {
�� _realSession[name] = value;
�� }
�� }

�� #endregion
}

That is all.� Happy bug hunting!