Arogl Darthu's Blog

Truncating text while respecting word boundaries.

nospam@example.com (Twan Jacobs) — Fri, 06 Apr 2012 07:12:08 +0000

Every so once in a while the issue rises where you need to truncate a piece of text to a certain maximum length.
Now that in itself is not so hard to do. But the result can look quite strange when the truncation point happens in the middle of a word.
As always StackOverflow provides a good starting point.
I just thought using a Regular Expression would be more concise. So here is my solution:

private const string Ellipsis = "...";

// Match word boundaries at the end of a word.
private static Regex wordRegex = new Regex(@"(?<=\w)(?!\w)", RegexOptions.Compiled);

private static string Truncate(string source, int length)
{
int maxLength = length - Ellipsis.Length;
if (source != null && source.Length > length)
{
int afterLastWordIndex = 0;
foreach (Match m in wordRegex.Matches(source))
{
if (m.Index <= maxLength)
{
afterLastWordIndex = m.Index;
}
else
{
break;
}
}

return String.Concat(source.Substring(0, afterLastWordIndex), Ellipsis);
}

return source;
}

static void Main(string[] args)
{
string source = "The quick brown fox jumps over the lazy dog";
Console.WriteLine(" 1 2 3 4 5");
Console.WriteLine("12345678901234567890123456789012345678901234567890");
Console.WriteLine(source);
int[] truncingLengths = { 0, 1, 3, 4, 8, 9, 10, 15, 19, 20, 21, 22, 23, 28, 30, 33, 42, 43, 50 };

foreach (int truncAt in truncingLengths)
{
Console.WriteLine("{0}: \"{1}\"", truncAt, Truncate(source, truncAt));
}

Console.ReadLine();
}

MSBuild Exec task - IgnoreStandardErrorWarningFormat

nospam@example.com (Twan Jacobs) — Wed, 01 Jun 2011 12:27:00 +0000

If you are using MSBuild 4.0.30319 and try to set the property IgnoreStandardErrorWarningFormat on the Exec task you might run into the following message error:

error MSB4064: The "IgnoreStandardErrorWarningFormat" parameter is not supported by the "Exec" task.

The solution is very, very simple: be sure to add ToolsVersion="4.0" to the Project tag.

Upgrade test project from VS2005 to VS2010

nospam@example.com (Twan Jacobs) — Mon, 09 May 2011 13:06:49 +0000

The solution contains several projects, including test projects. All of which now target .Net Framework 2.0 (although some already reference .Net Framework 3.0 or 3.5 assemblies). We do not want to upgrade to .Net Framework 4.0 just yet. Goal of the upgrade is to have every project in the solution target .Net Framework 3.5.

After converting the solution to VS2010 most of the projects reference .Net Framework 2.0. Some of which do not build, because of references to assemblies targeted at a higher .Net Framework. Visual Studio 2010 does not allow cross-referencing to higher .Net Framework assemblies. Fixing this problem is quite simple: just re-target the project to .Net Framework 3.5.

All of the test projects have been set to .Net Framework 4.0. One could discuss if this is acceptable for test projects as these will not be released. But for now it was decided to keep every project targeted at .Net Framework 3.5. Fortunately most of the test projects were easily re-targeted to .Net Framework 3.5. Hint: if you run into problems here, make sure VS2010 SP1Rel is installed.

For one of the test projects the solution just would not load it if re-targeted at .Net Framework 3.5. Each time the project was re-targeted, the conversion wizard would just pop up and set it back to .Net Framework 4.0. Eventually we found a workaround by editing the project file by hand after the conversion.

Two manual fixes were needed:

Change reference of "Microsoft.QualityTools.UnitTestFramework" to
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
Remove contents of the tag <FileUpgradeFlags>0</FileUpgradeFlags>, which hints VS2010 to start the conversion wizard.

T-SQL: Import csv in temp table

nospam@example.com (Twan Jacobs) — Wed, 13 Apr 2011 09:55:34 +0000

Seems pretty simple to do... Just execute a query like this one:

SELECT * INTO #TESTCSV
FROM OPENROWSET (
        'Microsoft.Jet.OLEDB.4.0',
        'Text;Database=C:\;HDR=YES',
        'SELECT * FROM test.csv')
 

In my case I was getting the following error message, which got me baffled for quite some time:

Msg 492, Level 16, State 1, Line 1

Duplicate column names are not allowed in result sets obtained through OPENQUERY and OPENROWSET. The column name "test#csv.NoName" is a duplicate.

This really didn't make any sense to me. There were no duplicate column names in the csv file and surely there were no columns named 'NoName', nor did I forget to name a column...

Then it came to me: what if UNICODE isn't parsed correctly? Maybe that could cause empty columns headers? The file was exported by ReportViewer and I had not looked at the encoding of the resulting csv file. Guess what!? The encoding was UNICODE. So, after saving the file in ANSI encoding, the query executed like a charm.

Wcf Exception Shielding - Unexpected FaultContracts

nospam@example.com (Twan Jacobs) — Fri, 27 Mar 2009 15:21:54 +0000

So you've got Wcf Exception Shielding in place. All is well and the Enterprise Library Exception Handling Application Block takes care of those nasty exception details that you don't want your site visitors to know about... But have you ever had the urge to do more than just property mapping between exceptions and FaultContract? I know I have

There is a way to do this and it is actually quite simple to realize. You just have to create your own custom IExceptionHandler. But let's start with a bit of configuration. By default you would have an Exception Policy named "WCF Exception Shielding". Like so:

This policy handles specific Exception types and for each of those it will pass the exception through a chain of IExceptionHandlers. The last of these would normally be Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.FaultContractExceptionHandler. For instance:

Now what if your FaultContract would need additional data, that you can't just map from the Exception properties? For example:
- you might need the Message property of the InnerException;
- you need data that was logged to a database when the original exception got thrown.

To make this possible, just create your own IExceptionHandler that will be used instead of the provided FaultContractExceptionHandler. There are two things to keep in mind when you do this. First of all you should always set the postHandlingAction to ThrowNewException. Second, you should let your IExceptionHandler return a specific Exception type: FaultContractWrapperException.
Continue reading "Wcf Exception Shielding - Unexpected FaultContracts"