Wrap Methods With Same Frame Functionality

Sometimes one have to write several methods in one class having the same “frame” functionality, e.g. a try/catch block with logging inside the catch.

Instead of copying this try/catch block all the times, one can create a wrapper for these methods. The goal is to have the try/catch block only written once.

The only thing needed in addition is to declare a delegate. This is how it works:

Declaring the delegates:

/// <summary>
/// Delegate for a processing step with no return value.
/// </summary>
private delegate void ProcesstingStep();

 

/// <summary>
/// Delegate for a processing step with a boolean return value.
/// </summary>
private delegate bool ProcesstingBooleanStep();

Declaring the wrapper:

/// <summary>
/// Do a process step on a method without return value.
/// </summary>
/// <param name=”processingStep”>The step to process.</param>
/// <returns><c>true</c> if no exception occurred, otherwise <c>false</c>.</returns>
private bool ProcessStep
  (
  ProcesstingStep processingStep
  )
{
  try
  {
    processingStep();
  }
  catch (Exception e)
  {
    MessageBoxHelper.ShowError(MessageboxOwner, e.ToString());
    return (false);
  }

  return (true);
}

 

/// <summary>
/// Do a process step on a method with a boolean return value.
/// </summary>
/// <param name=”processingStep”>The step to process.</param>
/// <returns><c>true</c> if the method succeeded and no exception occurred, otherwise <c>false</c>.</returns>
private bool ProcessStep
  (
  ProcesstingBooleanStep processingStep
  )
{
  try
  {
    return (processingStep());
  }
  catch (Exception e)
  {
    MessageBoxHelper.ShowError(MessageboxOwner, e.ToString());
    return (false);
  }
}

Calling the methods:

 

if (!ProcessStep(new ProcesstingBooleanStep(ValidateInput))
  || !ProcessStep(new ProcesstingStep(LoadProjectDocument))
  || !ProcessStep(new ProcesstingBooleanStep(GetBasePath))
  || !ProcessStep(new ProcesstingBooleanStep(LoadContentTemplate))
  || !ProcessStep(new ProcesstingStep(LoadMenuItems))
  || !ProcessStep(new ProcesstingStep(LoadCssClasses)))
  {
    return;
  }

Since .NET has evolved, maybe you want to use Action<> or Func<> now instead of self-defined delegates ;-).

Extract Files From .msi

Usually it is possible to use your favorite compression utility to treat a Microsoft Installer Package (MSI) like it is a normal archive. Though, sometimes this does not work. In this case one can use the Windows Installer Tool (msiexec.exe) to extract the files from the MSI package. The tool can open a MSI package in “Administrator” installation mode, where it can extract the files without performing the install.
This command runs the setup giving the ablility to extract the files without actually installing the application:
Msiexec /a mypackage.msi
This command extracts the files to the specified location without user interaction:
msiexec /a mypackage.msi /qb TARGETDIR="C:\MyFolder"
Please note this can also be useful in case an MSI package has been configured to block install, which is used on certain versions of Microsoft Windows.
More Info MS KB Q227091
Found on: http://smallvoid.com/article/windows-extract-msi.html

Limit Code Analysis Warnings

Visual Studio Code Analysis hat ein Limit von 200 für die Anzahl der Code-Analysis-Warnungen. Dies ist gut, um trotz der vielen Warnungen ein Projekt kompilieren zu können, kann aber auch ein Problem verursachen, wenn Tools eingebunden werden, welche selbst massive Anzahlen von Warnungen generieren und auf die Warnung von VS, dass dieses Limit überschritten sein, mit einem Abbruch reagieren. In meinem konkreten Fall ging es um DocProject, welches sinniger Weise mit einer “OutOfMemoryException” abbricht, wenn die Anzahl der undokumentierten Funktionen 200 übersteigt (sollte ja nicht vorkommen aber…). Wer also wissen möchte, wie viele CA-Warnungen er wirklich hat, sollte den Wert in der Registry erhöhen (die Änderung ist sofort wirksam).

Beschreibung von Microsoft: When first running Visual Studio Code Analysis over a large project, you may encounter the following error: CA0503: Additional warnings cannot be displayed. By default, a maximum of 200 warnings are displayed in the Error List. You can increase this amount by modifying the following registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\EDev\CodeAnalysisErrorListViolationLimit Simply set this to a value that suits your needs.

SSIS Logging SP Name Has Changed

In SSIS SQL 2005, the stored procedure to write SSIS logging informwation was sp_dts_addlogentry. In case this sp does not exist in the logging database, it was created automatically.

When I ported a BI solution from SQL 2005 to SQL 2008, I was wondering why the logging was not working any more. Tracing the database activities with SQL Server Profile, the reason was crystal clear: they changed the name of the logging sp to sp_ssis_addlogentry. And also, SSIS does not create it any more in case it does not exist.