I've been examining Visual Web Gui for a while. VWG promises nice functionality with an innovative but very familiar paradigm. So I decided to test capabilities of VWG with a known domain to me as a software developer and implementor of Pragma Issue Tracker Module for Cuyahoga Framework.

Pragma Issue Tracker (PrgIT) will try to meet the following basic requirements

• Open source
• Multi database support
• Use NHibernate with Castle ActiveRecord as Model Layer
• Use VisualWebGui as View and Controller Layers
• Service based Authentication and Membership for integration with existing web applications.
• Define Projects
• Define Components for each project
• Global and project based issue type definitions
• Global and project based priority definitions
• Link users for special roles for each project and/or component
• Issue comments and attachments
• Issue change history tracking and reporting
• Issue linking
• Custom issue tagging
• Custom fields for projects and components
• Issue work logging
• Project and component versioning
• Predefined dashboard reports
• Custom reports
• Functionality exposed via web services
• Custom and programmable issue actions per project and/or component
• Fulltext indexing and fulltext search
• Access to issues with user friendly url's

You can ask that why we need another open source issue tracker software, we already have open source issue trackers developed with Asp .Net meeting the requirements stated above? We do not actually need another issue tracker, PrgIT project was established simply to test the ecosystem composed of VisualWebGui, NHibernate and ActiveRecord, this is the main motivation behind this effort. 

Some PragmaSQL users were notifying me about a strange but deadly serious error caused after recovering from a server connection transport-level error. To reproduce the error follow these steps:

1- Open PragmaSQL Editor and choose a connection from Saved Connections list to connect. I will assume that Default Database of the selected connection is DatabaseA 

2- In the opened script editor change database to DatabaseB

3- Open to Microsoft Sql Server Management Studio and from Management node select Activity Monitor. Find the process for DatabaseB created by PragmaSQL application and kill that process.

4- Return to PragmaSQL editor and try to execute the select statement for the selected database, that is DatabaseB.

5- You will get transport-level error after trying to execute the statement for the first time.

6- Try to execute the statement again and this time you will succeed. But the statement was executed on the initial database, that is DatabaseA not in DatabaseB (selected one ). This error may cause very serious problems if you were trying to modify data you would simply modify the data in wrong database.

The problem is actually with database change code inside PragmaSQL which is not really a bug but misusage of SqlConnection class's ChangeDatabase method. While I was coding the change database logic I did not realy realised that ChangeDatabase method does not modify the Initial Catalog property of the ConnectionString, actually there is no way to modify the ConnectionString property of the SqlConnection object once it is opened. SqlConnection object in the script editor is created and opened only after the user changes the selected server, database changes does not cause a new SqlConnection object to be created and opened, we simply change the database property of the existing SqlConnection object and that is it. I did not considered SqlConnection object's error recovery scnearios (transport-level error for example) at all. The fact is that SqlConnection class recovers from transport-level error very well but uses the ConnectionString property to reopen the connection, no matter what was the database before the error SqlConnection object always restores connection to Initial Catalog property specified in the ConnectionString.

Very ugly bug, but I am happy to resolve that one. Upcoming 1.0.0.34 version will include solution for this issue.

What Wikipedia says about pragmatism.

The primacy of practice (from Wikipedia)

BlogEngine.NET version 1.3 has a syntax highlighting extension included but is in beta, so I looked around for another syntax highlighter, since this blog heavly uses code snippets. After looking for a while I found this syntax highlighter extension. This extension uses Wilco Bauwer's syntax highlighter library which is impressive. But the main problem with this extension is, it does not handle HTML tags and special HTML characters like &nbsp &lt and &gt very well. Tags and special characters are left as garbage after extension tries to highlight the code. You see something like this
More...

• Download Source Code - 3.17 MB
• Download Cuyahoga

Introduction

Cuyahoga provides module developers with a simple to use wrapper classes for full text indexing with Lucene.NET.
Although wrapper classes are easy to use these classes are not generic in nature. I mean
we, as module developers, have to convert our custom content (be it static or dynamic)
to a SearchContent object so that wrapper classes can index that content. Another similar limitation is when we perform search on the indexed content we can only get collection of SearchResult objects. I also want to mention that we, as module developers, have no control over which fields will be stored/unstored, which fields will be used as keywords or which fields will not be indexed while wrapper objects build the full text index.

In this article I will try to show you how we can make Cuyahoga.Core fulltext indexing capabilities more generic by providing a seperate extension assembly.
More...