Converting RSS feed to different formats using FeedBurner services

So, why should anyone bother converting RSS feed format? The answer is that RSS feeds can have various formats: RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0, etc. RSS reader has to know these formats and display the feed normally as if its format is the same for all feeds.

At present I’m using SharpReader as my primary RSS reading tool and there is one thing that I’m annoyed with – its memory consumption. I have smth around 180 feeds in my feed list. After SharpReader refreshes them all, its memory consumption rises to more then 200 Mb. It is not appropriate for me.

Recently I've obtained link that lead me to the download page of Internet Explorer 7 Beta3.
Though there was Beta2 out there already for quite long, I didn’t want to bother myself with “raw” product, especially if it is Internet Explorer :8-).

However, now it is Beta3 and I thought why not? Installation was okay. Then I exported RSS feeds from SharpReader into OPML file and imported it into IE.
Import was also fine, feeds hierarchy was preserved, what I really appreciate.

I’ll omit describing some inconveniences with feeds browsing I experienced with IE, and focus myself on the issue that can explain the title of this post :8-).

IE 7 Beta3 supports only several RSS formats!!! I was surprised. Namely, IE doesn’t have support for RDF format.

So, if RDF is not supported I have to convert it to something that is supported, for example RSS 2.0. How to resolve? FeedBurner comes to rescue!

Here are the steps do obtain converted feed:
1) go to http://www.feedburner.com
2) if you have an account there - sign in, if not – register and sign in
3) burn a feed. Put in the url of the feed that has unsupported format
4) after feed is burnt, go to main page, select it and then select “Optimize” tab
5) then select “Convert Format Burner”. This option will let you select appropriate RSS format. Choose “Save” and that’s it, you can use new feed url instead of the old one.

Example of such converted feed is
RDF: http://www.ixbt.com/export/articles.rdf
RSS 2.0: http://feeds.feedburner.com/Ixbt

Microsoft Robotics Studio

Nowadays, robots become more and more popular. Asian countries: South Korea and Japan are the leaders in the robotics.

Recently, member of Windows Mobile team blogged about creation of a robot that works under Windows Mobile ( http://www.wimobot.com ).

Microsoft, recently announced its Microsoft Robotics Studio.

Things get, more and more interesting :8-)

Deferred custom actions with WiX

Definition of Deferred Custom Actions

The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script.


Custom actions that set properties, feature states, component states, or target directories, or that schedule system operations by inserting rows into sequence tables, can in many cases use immediate execution safely. However, custom actions that change the system directly, or call another system service, must be deferred to the time when the installation script is executed.

Purpose of deferred Custom Actions

The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in the form with tag.


<Publish Event="DoAction" Value="CustomActionName">
<![CDATA[1]]>
</Publish>

How to define deferred custom action in WiX

Deferred custom action is defined in the following way:


<CustomAction Id="MyAction" Return="check" Execute="deferred"
BinaryKey="CustomActionsLibrary" DllEntry="_MyAction@4"
HideTarget="yes"/>


Lets describe the sample above:
- Execute=“deferred” – means that custom action with Id “MyAction” will execute in deferred mode ( in-script ).
- DllEntry="_MyAction@4" – the name of the function to be called, when installer executes generated install script.
- HideTarget="yes" - for security reasons, you may transfer confidential info to your custom action, this attribute notifies installer not to log parameters passed to custom action.

How to Transfer Properties to Deferred Custom Action

Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action. Deferred custom actions that call dynamic-link libraries (DLLs) pass a handle which can only be used to obtain a very limited amount of information.


Properties that can be retrieved during in-script execution are:

- CustomActionData - value at time custom action is processed in sequence table. The “CustomActionData” property is only available to deferred execution custom actions. Immediate custom actions do not have access to this property.
- ProductCode - unique code for the product, a GUID string.
- UserSID - set by the installer to the user's security identifier (SID).


If other property data is required by the deferred execution custom action, then their values must be stored in the installation script. This can be done by using a second custom action.
In order to write the value of a property into the installation script for use during a deferred execution custom action we have to do the following:


- Insert a small custom action into the installation sequence that sets the property of interest to a property having the same name as the deferred execution custom action. For example, if Id for the deferred execution custom action is "MyAction" set a property named "MyAction" to the property X which you need to retrieve. You must set the "MyAction" property in the installation sequence before the "MyAction" custom action.


Although any type of custom action can set the context data, the simplest method is to use a property assignment custom action.


At the time when the installation sequence is processed, the installer will write the value of property X into the execution script as the value of the property CustomActionData.


Lets illustrate the above said with WiX sample.


At first we define custom action that will assign CustomActionData property.


<Property Id=”SOME_PUBLIC_PROPERTY”>
<![CDATA[Hello, from deferred CA]]>
</Property>


<CustomAction Id="MyAction.SetProperty" Return="check"
Property="MyAction" Value="[SOME_PUBLIC_PROPERTY]">
</CustomAction>


Then we put above defined custom action into execution sequence along with “MyAction” deferred custom action


<InstallExecuteSequence>
<Custom Action="MyAction.SetProperty" After="ValidateProductID"/>
<Custom Action="MyAction" After="MyAction.SetProperty"/>
</InstallExecuteSequence>


Our custom action will reside in DLL. Below is the sample where we retrieve “SOME_PUBLIC_PROPERTY”, during deferred (in-script) installer execution.


<Binary Id='CustomActionsLibrary'
SourceFile='Binary\CustomActionsLibrary.dll' />


#include <windows.h>
#include <msi.h>
#include <msiquery.h>
#include <tchar.h>


#pragma comment(linker, "/EXPORT:MyAction=_MyAction@4")

extern "C" UINT __stdcall MyAction (MSIHANDLE hInstall)

{

TCHAR szActionData[MAX_PATH] = {0};

MsiGetProperty (hInstall, "CustomActionData",
szActionData,sizeof(szActionData));

::MessageBox(NULL, szActionData, _T(“Deferred Custom Action”),
MB_OK | MB_ICONINFORMATION);

return ERROR_SUCCESS;

}


If there is need to transfer multiple properties into deferred custom action, “CustomActionData” property may contain value pairs e.g. PropertyName=PropertyValue with some separator symbol ( ; ).

WiX: Changing entry name in ProgramMenuFolder in the runtime

Recently I was developing installation package using WiX toolset. And encountered interesting problem.


Installation package after installing application, also installs shortcuts into “Start” program menu, ( in WiX constant for it is “ProgramMenuFolder“ ).

The task was to set the name of Programs sub-entry with specific ( dynamic name ). This name is generated during installation time.

So, how to resolve?

It appears that if you write

<Directory Id="ProgramMenuFolder" Name="PMenu" LongName="Programs">
<Directory Id="ProgramMenuDir" Name='Comp' LongName="Full Company Name">
</Directory>
</Directory>

you expose “ProgramMenuDir” as public property, which you can change.

Okay, the question arises how and when this property should be changed, so that installer used new value for creating the Programs menu sub-entry?

To set property value we can use custom action

<CustomAction Id="DIRCA_SETPROGRAMFOLDER" Return="check" Property="ProgramMenuDir"

Value="[ProgramMenuFolder]Company Title - [PUBLIC_PROPERTY]"></CustomAction>

Values in square brackets correspond to names of properties defined during installation. Square bracket notation means

[PROPERTY1] – take value of property with name “PROPERTY1”.

Good, we have custom action, that changes the property. When should it execute is another question?

Properties that are used as directory names are finally set during CostFinalize process, so to change the values of these properties we have

to launch our custom action before CostFinalize. Piece of cake!

<InstallUISequence>

<Custom Action="DIRCA_SETPROGRAMFOLDER" Before="CostFinalize"></Custom>

</InstallUISequence>

<InstallExecuteSequence>

<Custom Action="DIRCA_SETPROGRAMFOLDER" Before="CostFinalize"></Custom>

</InstallExecuteSequence>

Now, after installer successfully finished we have nice and custom entry in ProgramMenuFolder.

Blog template changes

I've made some changes to the template of this blog. On the right side there is RSS link with standard image, like this

public vs private properties in MSI

Intro

Sooner or later every developer after development stage faces deployment stage. This stage turns out in developing another application, namely installer.

There are a lot of installers out there. Here I will enumerate some NSIS - Nullsoft scriptable install system, InstallShield, WISE, WiX and a lot of others. The latter use Microsoft Installer technology. All of them, except Nullsoft installer, produce .msi and other MS Installer files.

Properties in MSI

Since MSI file is a collection of tables, properties are placed in special table called, I think you will guess - "Property" :8-).So, what’s so special about these properties?

Custom Actions and Properties

Every installer developer should be aware that there are 2 types of properties in MSI. Values from Properties table are used by an installer as global variable during install process.

Information about types of properties is of special value for "custom actions" (CA) developers. CAs are special programs (.exe) or modules (.dll) that are called during installation process to perform special actions.

Now, let’s get back to properties...

Docs say:
- Private properties: The installer uses private properties internally and
their values must be authored into the installation database or set to values determined by the operating environment.
- Public properties: Public properties can be authored into the database and changed by a user or system administrator on the command line, by applying a transform, or by interacting with an authored user interface.

You will ask, how Installer determines which are private and which are public?
It is very simple public properties must be uppercase, and that’s it.

So, if your custom action stopped working and the problem is that it cannot read property from msi, then the first thing you should check is if this property is public.

Issues when using MarshalByRefObject instances from several application domains

At first let’s consider why we need to inherit our classes from MarshalByRefObject.
The reason is very simple - we want use them in separate application domains.

Let’s suppose we have to appdomains: appdomain1 and appdomain2.
(In this post I will not cover the details of application domain creation)

public class MainAppD : MarshalByRefObject
{
public SlaveAppD slaveAppDomain;
public void DoInPrimaryAppDomain()
{
}
}

//this class will be executing on second app domain
public class SlaveAppD : MarshalByRefObject
{
public MainAppD mainAppDomain;
public void DoInSlaveAppDomain()
{
}
}

What's wrong with these classes?

Recently I had similar scenario, and wondered why did my objects get disconnected from other appdomain.
When object is disconnected and you try to call its methods you get RemotingException...

Let’s consider lifetime of the above mentioned
class members that are references, namely SlaveAppD.slaveAppDomain and MainAppD.mainAppDomain
will become __TransparentProxy references. All calls will go through these transparent proxies.

Notions of proxies and application domains are directly connected with notion lifetime.

If we will consider classes above neither of them cares about its lifetime.
MarshalByRefObject has InitializeLifetimeService() method that returns time lease. The lease specifies
how long this object can be "alive" (Basically this means that proxy connection is alive).
The default lease value is 5 minutes. To increase lifetime
one has to override InitializeLifetimeService. Lets set lease time to 15.

public override Object InitializeLifetimeService()
{
ILease lease = (ILease)base.InitializeLifetimeService();
if (lease.CurrentState == LeaseState.Initial)
{
lease.InitialLeaseTime = TimeSpan.FromMinutes(15);
lease.SponsorshipTimeout = TimeSpan.FromMinutes(2);
lease.RenewOnCallTime = TimeSpan.FromSeconds(2);
}
return lease;
}

If you want infinite proxy connection lifetime the you simply return null.

//Infinite lifetime lease
public override Object InitializeLifetimeService()
{
return null;
}

Blog connectivity

In order to stay always connected to this blog ( if I will change hosting ), please use this link for syndication link

Beware of asynchronous methods calls that can complete synchronously. Part 1

In .NET every method can be executed asynchronously, it means that it will be executed in the separate thread, typically ThreadPool thread. Here is sample code…

class Program
{
public delegate void LongMethodDelegate();

static void Main(string[] args)
{
Console.WriteLine("Main thread: {0}",
Thread.CurrentThread.ManagedThreadId);

LongMethodDelegate @delegate =
new LongMethodDelegate(LongRunningMethod);

IAsyncResult ar = @delegate.BeginInvoke(
new AsyncCallback(OnComplete), null);
ar = @delegate.BeginInvoke(new AsyncCallback(OnComplete), null);
//@delegate.EndInvoke(ar);

Console.ReadLine();
}

static void LongRunningMethod()
{
Thread.Sleep(10000); //long running task
Console.WriteLine("--------- LongRunningMethod");
Console.WriteLine("Executing on thread: {0}",
Thread.CurrentThread.ManagedThreadId);
}

static public void OnComplete(IAsyncResult ar)
{
Thread thread = Thread.CurrentThread;

Console.WriteLine("--------- OnComplete");
Console.WriteLine("Completed on thread: {0}\n" +
"Synchronously: {1}\n" +
"ThreadPool thread: {2}\n" +
"IsBackground thread: {3}",
thread.ManagedThreadId,
ar.CompletedSynchronously.ToString(),
thread.IsThreadPoolThread.ToString(),
thread.IsBackground.ToString());
}
}

Everything is pretty simple here, LongRunningMethod() is executed on the separate thread, OnComplete is called when LongRunningMethod()is completed. The thread that completes the work is called WorkerThread.

While using this approach – method that is being called asynchornously will be executed on the separate thread… However, if you noticed IAsyncResult has CompletedSynchronously property. What for? It is a good question, and I hope soon it will be answered :8-)

Ukrainian version of blog started

Since I live in Ukraine ( not so small republic in the central-east Europe ) I decided to start a mirror blog in Ukrainian.

You can find it here