As a part of a client portal project we had a requirement to load documents displayed in the portal from a SharePoint document library. This seems like quite an interesting idea, because you don't need to build any fancy Content Management System (CMS) into your site for people to upload content and documents; they will just use standard SharePoint user interface to save documents into document library and your portal will take the content from there.

That's why I decided to create a generic component which will take documents from a document library on SharePoint and publish them as a part of any website.

The component loads data from a SharePoint Document Library:

And displays them inside a standard ASP.NET web application:

This article describes how you can build such solution.

Read more »

"A complete guide to avoid memory leaks and unwanted caching in Office"

You may wonder why one should worry about memory management in C# (or any .NET application); the mighty Garbage Collector (GC) built into Common Language Runtime (CLR) should spare us from messing around memory management till the end of time (this is one of the reasons why we chose .NET and why we make fun of C/C++ developers, right ?). Well Garbage Collector may serve us well as long as we are inside our "managed world", but as soon as your code make calls to COM (which is exactly what you have to do if you want to work with Outlook or any other Office application) Garbage Collector won't always save you. I'm not saying GC will not do its job (it eventually will), but the problem is that you cannot tell when it will happen, i.e. when the GC will free unused objects and their COM references. In this article I'd like to illustrate using an example of Outlook automation that this may sometimes be a problem.

Read more »

Lately I came across a requirement for an ability to remotely turn on computers in our company. Couple of team members (including me...) tend to work from home sometimes so they leave their PCs running when they leave the office so the next day they could access it over Remote Desktop. Do you spot a problem already? To be honest I did not realise this was a problem either ... until an electricity bill came in. The workstation PCs are running nonstop (no one really bothers to switch them off, what if they did not go to the office tomorrow ...), which obviously has very negative impact on the electricity consumption in our office.

So it was clear we need to do something about it. One can switch off a PC using Remote Desktop very easily (you can do it directly from Start menu), but having ability to switch off a computer remotely is useless unless you can then remotely switch on the computer again. And that is where Wake on LAN finds its place.

"Magic Packet"

Wake On LAN (sometimes referred as WOL or WoL) is a marketing term used for ability to bring computer out of Stand-By mode by sending it a special packet, called "Magic Packet".

When you shutdown Windows, all modern ATX-power based PCs do not switch off completely. Instead they enter a Stand-By mode, which means RAM, CPU and hard drives are switched off, but motherboard itself and a network card are still powered. To determine if your network card supports WOL, shut down your PC and check the Link LED on the network card - if it is still active, your network card is still powered and should support Wake on LAN.

Even though a PC is shut down, the network card is listening on the data layer (usually Ethernet) level and scans incoming packets for special character sequence. If it detects the sequence, it will turn on the PC. This sequence, called Magic Packet, has following structure:

Read more »

If you develop client applications, very often you come across an operation which is taking long to complete. Basically, you have 2 options; You can either do nothing about it, let the application "freeze" and let user wait for end of the operation. The problem is that the user doesn't know what is happening so he will become frustrated ("Damn, this app is really slow...") and may even eventually kill the application from the task manager, thanks to the "feature" of Windows which will mark the window as "Not Responding" and will offer the user an option to end the process.

That is why asynchronous processing (aka. processing in background) comes in place. The idea is that you display a dialogue to the user that informs him/her that there is something going on and that it may take some time to complete; or you can even let the user work with the application and literally do all the processing in the background.

Read more »