I faced a 'problem' while needed to add a postback event to the server while generating client code from the server on runtime.

You could think about a way of creating server control in the code behind and attaching it an event to its OnClick (or other event), but this one is good enough only to server controls that knows to do postback.

What will you do if you'll want to add postback event to a generic client control such as html-table-cell of other client controls that doesn't need to contact the server beside the postback event?

The GetPostBackEventReference method of the Page object's ClientScript property supports this action and let you perform this action. By MSDN property summary, this one "Returns a string that can be used in a client event to cause postback to the server. The reference string is defined by the specified control that handles the postback and a string argument of additional event information".

// ...

TableCell tc = new TableCell();
// Add some attributes or styling...
tc.Attributes.Add("onclick", Page.ClientScript.GetPostBackEventReference(this, <argument>));

// Do you stuff (add the cell to the table) etc.

I read a great article about performance and scalability. Some of the issues there were helped me a lot and the rest were sharpen my knowledge.

So, if you are an ASP.NET developer (beginner or senior), It is recommended for you to read that one by Omar Al Zabir at the codeproject site here.

Some if the things that he talks about are: ASP.NET pipeline optimization, Things you must do for ASP.NET before going live, Caching AJAX calls on browse and more...

Worth a reading...

The reason I published this post is because I didn't find any result when googling the error description and solved it myself at last.

If you're asp.net developers you probably know the ObjectDataSource object, which represents a business object that provides data to data-bound controls in multi-tier Web application architectures.

I like this object, most of the time this object can solve you all the annoying steps logic of calling the BL/DAL object in order to retrieve the data and populate the wanted presentation control.

On one of my working on website's pages (which is quite complex one that knows to list data from several sources and procedures), I am using such of object as a data source in the main GridView that renders a list of records. In order to interact with each different select method I had to set every time the SelectMethod property and it's specific parameters in the code-behind. Until now everything is just fine...

It seems that working this way affects the other postback events on the page, (because after event postback, the OnInit and OnLoad events are being called first and just after it the event handler itself is being called), here my page was crashed and gave this error message: "The Select operation is not supported by ObjectDataSource '<objectdatasource_id>' unless the SelectMethod is specified."

This error caused because the page expected the SelectMethod property to be initialized between the OnInit and OnLoad methods and just after it the rest of the events.

The resolution is quite easy in this case;

First, you need to remove the ObjectDataSourceID property definition from the control properties' definitions layout in the control source and set the DataSource for the control to the desired one in the OnInit method. After it, in the OnPreRender method call the control's DataBind method in order to bind the data source. This last action will allow to any event to happen and just after it to set up the Control (the GridView in my case) with data.

protected override void OnInit(EventArgs e)
{
   base.OnInit(e);
   MyGridView.DataSource = MyObjectDataSource;
}

protected override void OnPreRender(EventArgs e)
{
   base.OnPreRender(e);
   MyGridView.DataBind();
}

I hope it'll help anyone...

This post comes as a continues to the previous one. I thought about some insights regarding this issue and in the bottom line, there are some significant disadvantages that I could think about:

1. Get from the starter point that web application is stateless, this is the most important disadvantage - you cannot rely on that admit it or not.
2. What about performance - like the former post, this kind of alive (web) service will grab a thread permanently from the application pool and we'll use it - this thing damage in a matter of time the performance.
3. What about IIS reset action. If being done, the process will be 'dead' and this thing is worth to nothing because we can't rely on anyone to check if it alive.

The main conclusion:

Don't count on web application in order to run scheduled tasks - you can't rely on it in 100% (however you have tools that meant to monitor it).

I takes Ken Egozi's comment of creating a scheduled task (instead of windows service) that will do the scheduled job (I going to keep my local machine alive forever I think ;))

I have a problem (or used to have a problem...). In my working on web 2.0 startup, I bumped in a problem which in first thought looked to me as a simple one but after something like 5 seconds I figured out that it's actually a problem (or something to think about - I like this phrase much better ;)).

So after this introduction, lets introduce the 'something to think about' issue: I had to run each period of time a set of tasks in order to update some database statuses. If my web application was hosted on a dedicated server, this one had be solved very quickly; windows service - I guess you thought about it yourselves...

BUT, we are not going to host this web 2.0 application in a dedicated server (at least not now) and the scheduled task became a task itself, because (if you are web developers you'd better know) application is lives as long as there is at least one client that consumes it. When the last consumer is going home, also the application in going home to relax...

Now to the main question: how can we keep it alive?

After doing some thinking between me and myself, gathering up some good resolutions and not I thought about good one; in your web application create a web service that most of its job is to expose a KeepAlive web method that will return a dummy value and will keep the web application alive all the time and also will perform the tasks that you to establish for permanent period of time.

In your local PC, create a small desktop application in order to handle the tasks. This application will be a windows service that will run automatically under your machine every X interval and will ping the web service in order to keep the web application alive.

Note: the web service itself will know to execute the specific task itself every predefined period of time.

What about performance? This solution could affect your web application performance (I think that you know the reason why), in this case you can create another wen application that will be placed in the same server and all its job is to be kept alive and perform your tasks.

Any addition will be appreciated... I am going to write this web service now...

Have you also had some mysterious AJAX error/bugs/strange behavior? If does, this following link maybe will be helpfull for you... Dave Ward speards 2 common mistakes about it here.

BTW, Found it through ScottGu's blog.

Enjoy

I had a little debate (friendly one of course) with one of my work colleagues, caller Lior Alon about the usage and the necesasry of this technique. At the start of our conversation we disagreed on several things like: "It must stay for the good work flow", "This is by Microsoft design - do not touch" and more and more...
But at least we agredd that in some cases this ViewState is unnecessary and it has some disadvengtages that come over the adventages in some cases.

From the initial point of view, I would change the ViewState behavior. By defaut the ViewState of each ASP.NET web page is always on, so when you develop a new page you need to consider that the ViewState is on - so expect to amount of encrypted lltterals on the top of your page (according  the web server controls that you rendered on your page).

This issue has some disadvanteges as I said earlier:

1. Big size of data that comes from the sevrer to the client (response time concerns).
2. SEO (Search Engines Optimization) - Most of the seerch engines doesn't indexes the whole page (and I think non of then but I am not sure of it). The exsitance of the ViewState in the top of the prevent these search engines from index the relevant data from the specific page and here the ViewState takes its place. Here comes the question why the ViewState must be on the top of the page instread of its bottom?
3. By default the ViewState in on; In some cases, static pages contains web server controls that doesn't need to be updated from the server by the user demand. In this case each control has its own ViewState and it being populated to the bunch of the ViewState's encrypted data. (In that case you can develop this page using HTML controls that doesn't drag to the page 'added value'...

So, to the conclution...

ViewState is not bad thing, but like everything in life has some good and bad 'habbits'. After time of thinking, I think that the default behavoir of the ViewState should be off and the developer that creates her ASP.NET web page should be smart enough to use it wisely.

What do you think?

Lately I am focusing more and more on the Ajax.Net extenstions and framework in order to assimilate it wisely in my woring on web application. In general the .NET guys did here great job, created here realy a whole framework that includes new controls, namespaces etc... The outcome of it is good, it supplies us what we want doing it in quite easy way, there are nice webcasts, tutorials and lots of documentation that explains how to use it, but it's has also a (little?) disadventage - the actions' performance are quite bad in comparison to other open source tools, like Anthem.Net and more, you can impress of it here.

Until here is the post's intro... ;)

I investigated some the UpdateProgress control, it is nice one and supplies great usage and can gives us great UI results in a few minutes of simple actions. By investigating the source code of a web page that uses this control, I resolves this related code:

<script type="text/javascript">
<!--
Sys.Application.initialize();
Sys.Application.add_init(function() {
$create(Sys.UI._UpdateProgress, {"associatedUpdatePanelId":null,"displayAfter":500,"dynamicLayout":true}, null, null, $get<Update_Progress_Control_Client_ID>));
});
// -->
</script>

It's nice and being generated automatically of course, but what if you need to do some more actions while the callback action is under progress (you can think of tons client side actions, right?).

In this case I would suggest to abandon the UPdateProgress (great!) control and to implement this action by yourself in javascript using the Ajax client-side API, take a look of this one:

<script type="text/javascript">
    Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(
        function ()
        {
            // Do your actions...        
        }
    );
    
    Sys.WebForms.PageRequestManager.getInstance().add_endRequest(
        function ()
        {
            // Do your actions...
        }
    );
</script>

Using the Sys.WebForms.PageRequestManager object, you can add/remove handlers to the Ajax client-side Life-Cycle events and do your stuff in a focused and single place -> much more easier to handle and to maintain.

I wouldn't call it a problem/error/bug/you can call it how you want, I'll call it a moment of idiotic lack of attention?

I struggled with a very common problem (it seems to be a common after some googling): "My Global.asax events are not being constructed/called - what should I do?"; this one was so familiar and I was sure that I've done everything like it has to be, so again what was it?

Finally I figured out my problem myself and was supprised of it (I'm seriously not jocking), the Global.asax file was not placed under the root folder of my web application (my web aplication structure is quite 'complex' because it suppose to serve many web sites that sits also in the same solution). I replaced it in the right folder (the one that the IIS is pointed to) and that's it.

I think that post can solve to (starter?) web developers this (common?) problem while it occurs, because google's results didn't supply very good solutions for this one.

What aobut me? Even after developing and designing many web applications, things like that could happen to anyone

As I posted in the last post, I didn't have much time to update my blog last month (even most of this month), so I hope I could catch up these days and post some more about the on going issues that comes up.

Last month, a gut named Roni Schuetz send me an email regarding my post about Maintaining Data over Multi-Servers (Load Balancing on Web Farm) (direct link here).
Roni is the creator of a project named, Shared Cache which supplies high-performance, distributed memory object caching system, generic in nature, but intended to speeding up dynamic web and / or win applications by alleviating database load. He suggested me to use his project regarding maintaining cached data between multiple servers and I acceded testing it.

By Roni's documentation and project usage explanations the project is friendly usable and for a free-to-use-software I think it is highly recomended using it (or at least testing it).

Unfortunatly (or not), my company (IDT Global) has purchased (an expensive and also a great one) tool called ScaleOut SessionState In order to maintain session data over multiplae servers.

So, if you have an answer regarding this issue or just want to read about it, you can try Roni's indeXus.Net Shared Cache here.

Every site (or site admin in that case) desires to serve the users that are visiting the site on the best way, handle the traffic situation on the best side (if doesn't it's annoying the user and there is a chance that they won't come again).

Well known solution to this problem is to hold two (or more) servers needed to handle user requests. The main idea behind this web farm is to share pooled resources. There is a need to hold a common front end dispatcher to perform load control and manage customer requests.

My working web application answers these criterions mentioned above, it should be serving hugh amount of clients, therefore there is a usage of multi servers to give the best outcome, and I had to deal with that situation...

There several approach to deal this 'problem' that I could think of and listed ahead:

Session Management

There are 2 solutions supplied by ASP.NET regarding sharing state information between multiple servers:
State Server - In the specific web farm, you must approve that each web server holds the same <machinekey>. On the second step, if we'll want to maintain the session state across the web servers, each website's application path in the IIS metabase should be the same in the web farm.
One more important thing is to make sure of all the objects should (that you want to store in the session of course) be serializable (remember previuos post?).

SQL Server - Although I am using Oracle Database to store the current application data, I just wanted to mention this solution and will expand some basic details about this solution; Firstable, you should make sure all the objects are serializable, and like before, each website's application path in the IIS metabase should be the same in the web farm. This solution requires some SQL Server configuration in order to maintain the session management. You can read about it in more details here and here. Some very important security issues that you must consider are:

• Don't forget to encrypt your connection string (stored in the web.config or somewhere else).
• Use Windows authentication to the database and limit the application's login in it.
• Run the application in a secure channel.

Machine Authentication Check (MAC)

This solution comes for maintaining the form's information after firing events that are causing server postback. If you are working on one webserver, well... everything will act just fine; A common user behavior will fire a postback event which will go back to the server and deal with the sent data. BUT, what will happen if the event's data will be posted to another webserver? (All data will be lost...)

To solve this 'problem' you should modify the pages element in the machine.config of each webserver and set the enableViewStateMac attribute:

<system.web> 
   <pages enableViewStateMac="false" />
</system.web>

This will mention that the process should run a machine authentication check (MAC) on the pages' view state when the page is posted back from the client; true if the view state should be MAC checked and encoded; otherwise, false. The default is false.
"A view state MAC is an encoded version of the hidden variable that a page's view state is persisted to when sent to the browser. When you set the EnableViewStateMac attribute to true, the encoded and encrypted view state is checked to verify that it has not been tampered with on the client." (from MSDN).

Data Caching

• Shared Cache Application -You should use a cache application in order to cache you application's data. A good solution is to create am application that will be place in a single location. Each application (or each webserver) will send its data to this cache application to be cached. Each data retrieval will requested from the cache apllication firstly, otherwise will grab it from the specific data source (database etc...).
• SQL Server Caching - You can cache the data into Sql Server, it's quite easy to apply using ADO.NET and the .NET Framework provides a common development model to use with existing data access components. You can read some details about it here. Since in most case there is a single database that holds the data, you can use this kind of solution.

These are some of the ways for maintaining data over multi servers. I will be glad to hear about some more solutions and ways...

Post Prolog: Out of the record, as a continues to the previous post, I want to say that I am enjoing my life as a father, if I had know it I would do it earlier, BTW the little one named by my wife and me as Ori. More pics will be publish soon...)

Now, to this post issue...

I bumped in on a strange scenario; In my current working application, I have a page that holds a repeater that displays some data. This data is being declared in each partner's web.config's configSection. In order to read it once, I set this custom object as a Serializable one (which implements the ISerializable interface of course) and saved it into the ViewState of the page.

Now, when reading this object and saving it into the ViewState, everything has worked just fine (the server serialized this data properly).
But, when trying to grab this data from the ViewState (de-serialize this data) an annoying and vauge error message has been displayed was saying that: "The state information is invalid for this page and might be corrupted".

After a long and frustrating research about it, it turns out that the server will have NO KNOWLEDGE of the assembly name (Note: It was randomly generated when your site compiled on first run) because its own version of that assembly will have been compiled with a completely different random name, and it will not be able to de-serialise the viewstate and get the requested data.

To get around this problem, we should AVOID PLACING custom types into the viewstate (place'em somewhere else, like session, application etc.).

If you've got some more complex objects (or some custom types), these will need to be moved into a seperate class library project that is pre-compiled before deploying to the web-server. By doing it, it can be ensured that every web server has a copy of the same assembly and that the assembly has the same signature/name!  Try to avoid creating custom types in your App_Code or any of your web site files.  Rather create custom types in their own project to be compiled into a seperate assembly.

Cheers by now...

I am working against 3rd level party assembly in my current web application. I need to send US address information to this assembly and to retrieve an answer whether this address is exist or not. This assembly requires validation against X.509 certificate (to ensure that only permited client could use the 3rd level's services), which is installed on the server that runs the application (in dev environment this is my local PC).
More details about it here.

The problem: In order to authenticate against this certificate, the process that runs the application need to 'hold' sufficient credentials in order to get an access to the certificate and to do the authentication. Here comes our problem; when trying to access this certificate through the asp.net application, we run into a problem - It's impossible, because the process that runs the web application is ASPNET and doesn't has the needed credentials in order to authenticate the certificate and get the info from the 3rd level.

Suggested solutions:

1. Credentials. Read the credentials from the web.config (username, password and domain) and impersonate the user using these credentials. This will 'save' the impersonated user all over the impersonation context (System.Security.Principal.WindowsImpersonationContext) and the authenicate action against the certificate will be done using this credentials. One more important thing, to ensure this data protected, encrypt it before puting it into the web.config.
2. I thought about IIS Application Pool. This is a great feature that came up in IIS 6.0, which enables you the ability of creating one or more applications and allows us to configure a level of isolation between different Web applications. You can set the identity of an application pool which will be the account under which the application pool's worker process runs. So I thought to set it over there, but I had one big problem, an IIS 5 was installed on the production server and it is not a dedicated server. (More details about application pool here).
3. Host .NET component in COM+. This is the third solution and the best for me at the current circumstances; Because I am working with a several applications (assemblies) I want to host the component that validates the user against the 3rd level party, this will give me a unified behavoir for all the applications while doing this action (Instead of setting these properties in web.config file of each web application we want to use {solution 1, remember?}). In other words, I'll set the username and password on the COM+ component just once in order to grant the process that runs this component the right and sufficient credentials. .NET provides a way to host your .NET components inside COM+ environment. All the functionality you need to write a COM+ aware component in .NET can be found in System.EnterpriseServices namespace.

So how we do it (hosting .NET assembly in COM+)?

Take a look on this code:

using System;
using System.Collections.Generic;
using System.Text;
using System.EnterpriseServices;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;

namespace ComPlusTest
{
    [Transaction(TransactionOption.Required),
        ObjectPooling(MinPoolSize=2, MaxPoolSize=5, CreationTimeout=20000),
        ComVisible(true)]
    public class TestClass : ServicedComponent
    {
        protected override void Activate()
        {
            base.Activate();
            DoSomeAction(Action activate)
        }

        protected override void Deactivate()
        {
            base.Deactivate();
            DoSomeAction(Action deactivate)
        }

        protected override bool CanBePooled()
        {
            DoSomeAction(Action pooled)
            return base.CanBePooled();
        }

        public void ValidateAddress(string address)
        {
            try
            {
               // Do the validation against the 3rd party
               ContextUtil.SetComplete();
            }
            catch(Exception ex)
            {
               // Handle exception
               ContextUtil.SetAbort();
            }
        }

        [AutoComplete()]
        public void JustAction()
        {
            DoSomeAction(Action simpleAction);
        }

        private void DoSomeAction(Action act)
        {
            // Do the action
        }
    }
}

Lets dissect it:

1. Firstable you can see that the class is derived from ServicesComponent (which sits in the System.EnterpriseServices namespace). I marked our TestClass with some attributes. The first one in Transaction; The values for this attribute are same as in traditional VB/VC++ development i.e. Required, RequiresNew, Supported etc. MinPoolSize and MaxPoolSize specifies values for minimum and maximum object instances. The ComVisible attribute must be set to true to give the accessibility of an individual managed type or member, or of all types within an assembly, to COM (I spent lots of time trying to figure out some exceptions that I had while overriding the ServicesComponent class).
2. the class is marked to require a transaction each method will execute in a transaction (existing or new). Once the ValidateAddress has been executed we need to either commit or rollback the transaction. This is done via static methods of ContextUtil class. The method SetComplete is used to commit a transaction where as SetAbort is used to rollback a transaction.
3. Just for example, I defined a methid called JustAction. This method is marked with an attribute AutoComplete which means that once the method execution is over the transaction is automatically committed (equivalent to ContextUtil.SetComplete). In case of any error the transaction will be rolled back (equivalent to ContextUtil.SetAbort).
4. Overrided Activate, Deactivate and CanBePooled methods are just for testing (in order to observe the flow behavior).

Now, you have to sign your assembly with a strong name and to add the following attributes to the AssemblyInfo class of your project:

[assembly: ApplicationName("ComPlusTest")]
[assembly: ApplicationActivation(ActivationOption.Library)]
[assembly: AssemblyKeyFileAttribute("ComPlusKey.pfx")]

I had a performance problem in my current working on web application; In one of my flows in this application, I had needed to call the database and to update some large amount of data over there, but this action had taken lots of time and the outcome was that users had to wait a long time until this action will be done, admit it, it is frustrating...

My first kind of solution to this problem was to create a new thred from the IIS's thread pool and to assign this action under it - quite good resolution not? BUT, I reminded that asp.net 2.0 (also 1.X) already implements it in a better and friendly way, using Asynchronous Pages.

But first, some Background...
As we all know (or not), when ASP.NET receives a request from the user, it ask for a thread from a thread pool and assigns that request to the thread. In order to this action, the synchronous page holds this thread for the duration of the request, and preventing it from being used by other requests. That leads us to my problem: when I am calling to the database and doing the long long action (an UPDATE query), the thread assigned to the request is stuck doing nothing until the call returns. (This happens because the thread pool has a finite number of threads available).

The Resolution is (of course) Asynchronous Pages.

Asynchronous pages offers a neat solution to such kind of problems. Once an asynchronous operation begins in response to a signal from ASP.NET, the page returns the used thread to the thread pool. When this operation completes, this mechanism asks for another thread from the thread pool and finishes processing the request. This mechanism helps us to manage more efficiently the threads manipulation from the thread pool, because threads that were stucked earlier, now can be used for other porpuses.

Lets see some code:

Firstable, you need to set the Async property on the top on the asp.net page in order to use this thing:

<%@Page Language="C#" Async="true" ... %>

This property set to true, says the page to implement the IHttpAsyncHandler. Regarding this, you need to register the Begin method and End method of to the Page.AddOnPreRenderCompleteAsync.

// Register async methods
AddOnPreRenderCompleteAsync(
   new BeginEventHandler(BeginAsyncOperation),
   new EndEventHandler(EndAsyncOperation)
);

By these actions, the starts its normal life cycle, until the end of the OnPreRender event invocation. At this point the ASP.NET calls the Begin method that we registered earlier and the operation begins (calling the database etc...), meanwhile, the thread that has been assigned to the request goeas back to the thread pool. At the end of the Begin method, an IAsyncResult is being sent automatically to the ASP.NET and let it determine in the operation had completed, a new thread is being called from the thread pool and there is call to the End method (that we registered earlier, remmember?).

Note: We do not need to implement the IAsyncResult interface, the Framework implements it for us.

The Begin and End Methods:

IAsyncResult BeginAsyncOperation (object sender, EventArgs e, AsyncCallback cb, object state)
{
   // Do your things...
   // Call the DB and run the long long query...
}

void EndAsyncOperation(IAsyncResult ar)
{
   // Do your things...
   // Get a response from the DB that the operation is DONE...
}

Nide ahhhu? So use it wisely...

I had a debate (friendly one of course...) with a co-worker of mine, called Maayan. We discussed about what is the best place to save quite large of data that need to be used frequently in my web application, should we store it in the Application object or the prefered way - store it in the Cache object?

Before we'll go to the conclution, lets get some details about these 2 terms and the vast term called Caching in applications.

2nd before - I am not going to invent the wheel on this post, just to sharpen some points that I think that are missing or came up for most of us...

Caching is the most effective technique you can use to improve the performance of your ASP.NET web application. Designing your application with caching in mind, improves both the performance and the scalability of that application. Caching is about storing data in memory the first time it is requested and then re-using it for the following requests for a specified period of time.

ASP.NET provides very convenient API in order to use this term for the best and easy way, reffered also to Application data object and Output Cache of course.

You can cache the application data using the System.Web.Caching.Cache class. One instance of this class is created per application domain, and it remains valid as long as the application domain remains active. This object is global which means its data is avaiable anywhere at the application scope.

Now, to the big question: What is more recomended for storing the data, Cache object or Application object?

Well, the main difference between them is that he cache object has some more powerful features that allows you to control the cached data. Which this object, each of the data item has its priority state and expiration time. This object has 2 important issues handling: When your system's memory becomes short, the chache object knows to remove data items with low priorety and free its memory, by that the cahce ensures that unnecessary items does not consume valuable server resources.

One more good adventage (in ASP.NET of course) is to cache the pages' data. ASP.NET allows you to cache web pages or portions of them, calling this an output caching. By caching frequently requested pages or portions of them, you can substantially increases your web server throughput and get a fast page response. You can cache pages on devices like: the web browser making the request, the web server responding to the request, and any other cache capable devices such as proxy servers. To read some more information about it go here).

Conclution: I think that for more complex data manipulation caching, the recommended way is to use the cache object and API, but if you want to use and cache some 'dummy' data (or just data that not has to be modified and managed during the application), use the application object (or session object - per user's session) to chach your data.