I bumped into a nice solution that enables you to speed up your websites pages loading.

“Page Speed Service is an online service to automatically speed up loading of your web pages. Page Speed Service fetches content from your servers, rewrites your pages by applying web performance best practices and serves them to end users via Google's servers across the globe”.

I think that this is a good solution for those who doesn’t familiar with the advanced caching solutions or for beginner or not pro developers which want a way to increase performance, but if you are an experienced developer you should get your own solutions coding them under your application like: caching,  load balancer solutions for large website etc…

you get get some more information here.

I had a task at work to get a web page content (using System.Net.WebRequest) in order to send the data by demand by email or in other ways.

The web page holds contents like images and more that need to be send by email in order to display the html content properly.

In order to parse the html content and look out for the images in order to download them to the server manually (a thing that will cause a lot of regex work and parsing issues), I found a great open source module (by Sharon Djabnoun, my allrise.com teammate, recommendation) that called HTML Agility Pack. “This is an agile HTML parser that builds a read/write DOM and supports plain XPATH or XSLT (you actually don't HAVE to understand XPATH nor XSLT to use it, don't worry...). It is a .NET code library that allows you to parse "out of the web" HTML files. The parser is very tolerant with "real world" malformed HTML. The object model is very similar to what proposes System.Xml, but for HTML documents (or streams).”

Now, the work on the html content will be very easy and fast – the only thing that I’ll need to do is to fine the images node, download the images to the server, set the directive of the image’s source and send the email with the attachments and the fixed URL content to point the new location of the images.

You can find it here.

This is quite strange story... but I decided to publish this post because I didn't find any proper solution anywhere; and I mean it ANYWHERE!

It begins like that: I am running an asp.net 2.0 web application that as part of its work, it has to communicate 3rd party assembly, which suppose to retrieve some validation data. Until here everything is just fine right?

In order to invoke the 3rd party service (using an API of course), there is a need to install a X509Cerificate with 'secret' password and to install it on the server that runs the web application. After doing it you must  impersonate the ASP.NET process with the logged-in user that installed the certificate in order to 'grant' this user permission (administrator) to the current context of the web application.

Note: the user credentials will be kept in the web application web.config encrypted of course.

When running this application in my dev box, everything was working just fine, but when done with unit testing and was ready to QA, only when the user that installed the X509Certificate was logged in to the system (windows) the access to this specific certificate could be done. When the user was logged off, the Initialize method that initializes the certificate, couldn't find it in the CurrentUserStore:

public void Initialize(some parameters...)
{
   X509CertificateCollection certificates;
   X509CertificateStore store = X509CertificateStore.CurrentUserStore("My");
   
   store.Open();
   certificates = store.FindCertificateBySubjectName("<subject>");
   if (certificates.Count <= 0)
   {
      thrownew Exception("<message>"));
   }
}

I admit that I didn't have any clue of how solving this acute problem, which of course stuck all the process of dev.

After consulting with some colleagues, we decided to try a 'detour solution', that will raise the user up into the system (will keep it alive, unlike doing log off to the user that terminates it from the OS).

Finally the solution (what you've waited for of course): 

We created a blank window service (with an installer) that actually does nothing, complied it and installed it in the QA server. Now here is the catch: First, the window service's startup type is set to Automatically (will be started always when the OS is up). secondly we adjusted the service's log on to a specific account that held the credentials of the user that installed the certificate of course. The purpose of this action is to keep this user up all time in order let our 3rd party application find its certificate in its store.

Outcome - it is working smoothly like magic. We can continue working...