De Tout Et De Rien

Maybe you have already seen that in some Visual Studio 2005 projects : a item that represents a link to a file (see image below).

It is very handy to reference through a link a file : for example, if you have three projects that uses the same file, just put a link. But when I add item to my project, I cannot see a Link or a similar option. This is because it is a bit after. Here are the steps :

1) Go to the Solution Explorer

2) Select "Add an Existing Item"

3) Select the file to add and click on the arrow at the right of the button "Add", and click on "Add as Link"

4) In Solution Explorer, you see the linked file

If you are developping an application base on the Microsoft RTC API, a big surprise is awaiting you with Windows Vista. The installation of the RTC API miserably failed, because of lack of privileges. The result is that the RTC side-by-side assemblies are not available, thus the application does not want to start. Crawling through the forums doesn't help much. So what can you do to make this application work ? Here is an answer.

The basic idea is that if the RTC side-by-side assemblies cannot be installed, then they have to be deployed within the application, thus making the application isolated. MSDN is a great source of knowledge about isolated applications and side-by-side assemblies. To avoid any problem during the library lookup, the workaround also uses tips about the assembly searching sequence.

To deploy side-by-side assemblies to be used with an isolated application, we must copy them in the same folder that the application exectuable. The naming of the Manifest files is important to enable a proper lookup. The last trick is to force the local resolution of the DLLs, by indicating that no system-wide search is needed. Now that you have the full picture, here are the details.

1. Extract the RTC DLLs and Manifests files from a successful install of the RTC API. This can be done on a Windows XP SP2 system. The files to grab are (for a RTC 1.3 API) :

   C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Networking.Dxmrtp_6595b64144ccf1df_5.2.1002.3_x-ww_021cfae0\dxmrtp.dll
   C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Networking.RtcDll_6595b64144ccf1df_5.2.1002.3_x-ww_92561fce\rtcdll.dll
   C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Networking.RtcRes_6595b64144ccf1df_5.2.1002.3_x-ww_88ef1b2a\rtcres.dll
   C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Networking.Dxmrtp_6595b64144ccf1df_5.2.1002.3_x-ww_021cfae0.Manifest
   C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Networking.RtcDll_6595b64144ccf1df_5.2.1002.3_x-ww_92561fce.Manifest
   C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Networking.RtcRes_6595b64144ccf1df_5.2.1002.3_x-ww_88ef1b2a.Manifest

2. Rename the Manifests. The changes are :

   x86_Microsoft.Windows.Networking.Dxmrtp_6595b64144ccf1df_5.2.1002.3_x-ww_021cfae0.Manifest becomes Microsoft.Windows.Networking.Dxmrtp.Manifest
   x86_Microsoft.Windows.Networking.RtcDll_6595b64144ccf1df_5.2.1002.3_x-ww_92561fce.Manifest becomes Microsoft.Windows.Networking.RtcDll.Manifest
   x86_Microsoft.Windows.Networking.RtcRes_6595b64144ccf1df_5.2.1002.3_x-ww_88ef1b2a.Manifest becomes Microsoft.Windows.Networking.RtcRes.Manifest

3. Copy the files in the direction where lies your application. They must be in the same folder.
4. In your RTC based application, create a Manifest file to reference the exact version of the RTC API. The dependency section in the Manifest file should look like that (taken from the RTC samples) :

   <dependency>
       <dependentAssembly>
            <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Networking.RtcDll"
                version="5.2.1002.3"
                processorArchitecture="X86"
                publicKeyToken="6595b64144ccf1df"
                language="*"
           />
       </dependentAssembly>
   </dependency>

5. Create an empty file, named like your application executable file, with a local extension. If your application executable is WindowsApplication.exe, the empy file should be named WindowsApplication.exe.local.
6. Launch your application. It should work properly.

Maybe you have just spotted the following problem with Visual Studio 2005 : you can create an abstract form, which inherits System.Windows.Forms.Form, and modify it in the visual designer. But if you inherit it, you cannot modify it in the visual designer. You think it is kind of strange, but the explanation is pretty clear. And so is the workaround. You are now armed to modify visual control, even if they inherit from an abstract control.

But the things are slightly different when dealing with generics : you can create a generic form and modify it in the visual designer. But if you create a specialized child of this form, the visual designer refuses to open it. Even with the previous trick, there is nothing to do. After some search and some experiment, I came to the conclusion that the behaviour of the CodeDomDesignerLoader is far away from my understanding. So, are we lost in space when dealing with generic controls ?

No. The workaround to this behaviour is pretty ugly, but it has one huge advantage : it works. So here is an example.

1. Define your generic form, like any other generic class :
   

       1 using System.Windows.Forms;

       2 

       3 namespace AbstractAndGeneric

       4 {

       5     public partial class GenericForm<T> : Form

       6     {

       7         public GenericForm()

       8         {

       9             InitializeComponent();

      10         }

      11     }

      12 }

2. Define your specific form, by inheriting the generic form and specialize it with a type :
   

       1 using System;

       2 

       3 namespace AbstractAndGeneric

       4 {

       5     public partial class SpecificForm : GenericForm<String>

       6     {

       7         public SpecificForm()

       8         {

       9             InitializeComponent();

      10         }

      11     }

      12 }

3. At this point, if you try to open SpecificForm in the designer, you will get a nice error message.
4. Add the following code to the SpecificForm :
   

       1 using System;

       2 

       3 namespace AbstractAndGeneric

       4 {

       5 #if DEBUG

       6     public partial class SpecificForm : __SpecificForm

       7 #else

       8     public partial class SpecificForm : GenericForm<String>

       9 #endif

      10     {

      11         public SpecificForm()

      12         {

      13             InitializeComponent();

      14         }

      15     }

      16 

      17 #if DEBUG

      18     public partial class __SpecificForm : GenericForm<String>

      19     {

      20     }

      21 #endif

      22 }

The explanation is straighforward :

• Considering the behaviour of the designer, if the base class of the control you want to design is not designable, you got an error. That is why, an intermediate class is inserted. Its sole purpose is to provide a designable class for the visual designer.
• The use of compilation directives allows to use the trick in the Debug configuration and to have a direct inheritance in the Release configuration.
• And I repeat, this trick only works if you design in Debug mode. Otherwise, you will get the usual error.

This is the solution I found, but I am looking forward to see an alternative solution, simpler and more elegant.

When dealing with message folder, the temptation is strong to re-invent the wheel when it comes to make a search through its messages. One evident solution is to grab all the messages, test against the criteria, and if the message matches, store it for further need.

Since JavaMail 1.1, a search facility has been provided. It is located in the jaxax.mail.search package. To make a complex search, you just create the needed search terms and compose them with a AND or OR operator. The next step is to call the magic method on the message folder : Folder.search(SearchTerm term) that returns an array of Message instance.

It may be look weird to add such complexity to a simple search in a mail folder, but when it comes to term composition, this solution is the most flexible and above all, when you look at your code, the nicest one.