In my previous post Displaying .NET DataSet with Crystal Reports I discussed one way to report the data that does not come directly from a database. In this way, it is possible to preform more complex data analysis and present the result using Crystal Report engine. Following post addresses similar issue. However, here, the data to be presented is not stored in a DataSet, but rather in a .NET Collection, which implements IEnumerable interface.
More...

Couple of days ago, I started playing with Crystal Reports engine included with Visual Studio.NET. After creating several reports using SQL Express database, I started wondering how to create reports that require more sophisticated data analysis. At first, my thoughts were to utilize stored procedures to create report result, and and then display the result using Crystal Report engine. However, it turned out that Crystal Report engine has some limitations when it comes down to stored procedures. Crystal Reports documentation states that stored procedures can be utilized if they contain at most one SQL SELECT statement. In addition, the documentation states that no return parameters can be utilized (parameters declared by SQL keyword OUT, or INOUT). Clearly, complicated data analysis cannot be performed using single SELECT statement. Considering these limitations, I immediately started to investigate options to present a structure using Crystal Reports. At first, I considered a .NET containers, but Crystal Reports engine did not seem to provide any convenient way of displaying such structures. In addition, I noticed that every report that I designed, required the structure of the data to be known at report design time. At that time, two options came to my mind:
More...

Couple of days ago, I installed BlogEngine.NET on my home server's root directory. Besides being extremely impressed by BlogEngine.NET, I noticed that all of my other sub-applications started crashing. Immediately, I knew that the installation of BlogEngine.NET affected all other web applications. After short investigation, I noticed that all of my sub-applications were trying to load handlers and modules defined in BlogEngine class library. Specifically, all web applications tried to load following:

[...]
<httpModules>
      <add name="WwwSubDomainModule" type="BlogEngine.Core.Web.HttpModules.WwwSubDomainModule, BlogEngine.Core"/>
      <add name="UrlRewrite" type="BlogEngine.Core.Web.HttpModules.UrlRewrite, BlogEngine.Core"/>
      <add name="CompressionModule" type="BlogEngine.Core.Web.HttpModules.CompressionModule, BlogEngine.Core"/>
      <add name="ReferrerModule" type="BlogEngine.Core.Web.HttpModules.ReferrerModule, BlogEngine.Core"/>
      <!--The CleanPageModule below removes whitespace which makes the page load faster in IE. Enable at own risk -->
      <!--<add name="CleanPageModule" type="BlogEngine.Core.Web.HttpModules.CleanPageModule, BlogEngine.Core"/>-->
      
      <!--Remove the default ASP.NET modules we don't need--> 
      <remove name="PassportAuthentication" />
      <remove name="Profile" />
      <remove name="AnonymousIdentification" />
    </httpModules> 

    <httpHandlers>
      <add verb="*" path="file.axd" type="BlogEngine.Core.Web.HttpHandlers.FileHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="image.axd" type="BlogEngine.Core.Web.HttpHandlers.ImageHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="syndication.axd" type="BlogEngine.Core.Web.HttpHandlers.SyndicationHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="sitemap.axd" type="BlogEngine.Core.Web.HttpHandlers.SiteMap, BlogEngine.Core" validate="false"/>
      <add verb="*" path="trackback.axd" type="BlogEngine.Core.Web.HttpHandlers.TrackbackHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="pingback.axd" type="BlogEngine.Core.Web.HttpHandlers.PingbackHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="opensearch.axd" type="BlogEngine.Core.Web.HttpHandlers.OpenSearchHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="metaweblog.axd" type="BlogEngine.Core.API.MetaWeblog.MetaWeblogHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="rsd.axd" type="BlogEngine.Core.Web.HttpHandlers.RsdHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="css.axd" type="BlogEngine.Core.Web.HttpHandlers.CssHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="js.axd" type="BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="rating.axd" type="BlogEngine.Core.Web.HttpHandlers.RatingHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="opml.axd" type="BlogEngine.Core.Web.HttpHandlers.OpmlHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="monster.axd" type="BlogEngine.Core.Web.HttpHandlers.MonsterHandler, BlogEngine.Core" validate="false"/>
      <add verb="*" path="blogml.axd" type="BlogEngine.Core.Web.HttpHandlers.BlogMLExportHandler, BlogEngine.Core" validate="false"/>
</httpHandlers>
[...]

At first, I was very confused that all sub-applications are loading web.config from the root application. I thought that each web application simply used the web.config from it's own virtual folder (besides machine.config). To investigate the issue, I started searching the web and after a short time I found the following article. The article explains the way IIS 6 is handling web configuration loading and inheritance. Frustrated with the result, I was determined to find solution to my problem. And then it hit me: <location> tag! With <location> tag, it is not only possible to control application security, but also selectively load parts of web.config. Actually, the accurate statement would be that <location> option allows user to control if "child" applications will inherit portions of web.config. In this way, I was able to pick and choose, which parts of web.config will be loaded in sub-applications. Following part of web.config explains everything:

[...]
<location inheritInChildApplications="false">
 
  <system.web>
    
  [...]   
 
  </system.web>
  
</location>
[...]

Adding <location> option solved my headache ...

Couple of weeks ago, I needed to parse a set of XML files. As always, my first thought was to search the web for free XML parsers. But then I remembered that I found a solution in the past: Xerces XML parser. Even though, xerces was originally written in Java, there is an excellent port to c/c++. Xerces was developed by Apachi Software Foundation, and it supports wide range of compilers. To use it with Visual Studio 2005 C++ compiler, following steps are required:

1. Download compiler in binary form from here;
2. Unpack into any folder; This step will create subfolders include and lib;
   
3. Add path include and lib folders to VC++ directories;
4. To statically link to a project, link with xerces-c_static_2.lib or (xerces-c_static_2D.lib for debug version);
5. Set to ignore libcmt.lib

Steps 4 and 5 are shown in the screen shot below: