SSIS configuration file warning

While trying to run one of our SSIS packages after migrating from development to string testing I got an interesting warning message.

Warning: 2008-01-31 16:02:38.88
Code: 0x80012014
Source: Package_Name
Description: The configuration file "X:\\Package_Name.dtsConfig" cannot be found. Check the directory and file name.
End Warning
Warning: 2008-01-31 16:02:38.88
Code: 0x80012059
Source: Package_Name
Description: Failed to load at least one of the configuration entries for the package. Check configurations entries and previous warnings to see descriptions of which configuration failed.
End Warning

I was trying to run the package using the dtexec utility with the /conf option. At design time the package was bound to the dev config file. After the migration to the string environment I wanted to run the same package but pointing to the string config file. And that raised the above mentioned error.

This happens because the package configuration file name and location are embedded into the package.

<:Property DTS:Name="ConfigurationString">X:\\Package_Name.dtsConfig</DTS:Property>

And at run time the package first looks for the file bound at design time rather than the one you specified in the dtexec command. But this is only a warning. The package runs properly after this warning message.

So I understand that the SSIS package first looks for the design time configuration file and then goes for the file specified in /conf option.

One more thing I noticed while deploying a package to a file system is you are not allowed to type the path. The control is disabled!!

I had to install the SSIS package in a LAN share whose path I know very well. As I was not able to key in the path, I had to search hard for the share in the "Entire Network" node in the folder browser dialog. This is a tedious way of doing it as the company I work for has N number of systems and servers out there in the network. It would be much better if you were allowed to key in the path.

Asynchronous logging using Logging Application Block

A quick search in the web for asynchronous logging using Logging Application Block revealed that there is only one way of doing it, using MSMQ and DistributorService.

I don’t have the option of using MSMQ for my application. So I put together a small solution for this problem using Jon Skeet’s asynchronous helper class called ThreadUtil [Thanks Jon]. The helper class has a method "FireAndForget" through which we can make an asynchronous calls without worrying about leaking handles. The helper class takes care of calling the EndInvoke and closing the waitHandle.

My solution is to use the helper class and make asynchronous calls to the Logging application block.

The sample can be downloaded from:

http://cid-0476ca5e9f26e63c.skydrive.live.com/self.aspx/Public/Documents/AsynchLogging.zip

Update:
In the asynchronous helper class the call to EndInvoke should be wrapped with in a try catch block. If not & if there is an exception while running the asynchronous method, it will be raised by the runtime when we call EndInvoke. If the exception is not handled at this point it would crash the whole application!

The new updated sample can be downloaded from:
http://cid-0476ca5e9f26e63c.skydrive.live.com/self.aspx/Public/Documents/AsynchLogging_Updated.zip

Enterprise library logging & exception handling application blocks

I am creating a tool which automates the build process of our application. I was using the logging & exception handling application blocks from enterprise library. I encountered an interesting problem.

The “Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging” assembly that is used by the exception handling block to log the exception through the “Logging Handler” is not copied over to the main project output directory.

This issue is also discussed in the following URL : http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=18926

My visual studio solution had a GUI project [windows forms], which references a custom helper class library for logging. The custom library has references to the “Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging” assembly with CopyLocal property set to true. When I build the solution the assembly is copied to the output directory of the class library but not to the main GUI project. So when my application tries to log an exception it fails.

As a workaround I added a using statement to one of the classes in the class library.

using Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging;

I also added a dummy statement in the code.
LoggingExceptionHandler exceptionHandler = null;

Now the assembly is copied to the main GUI project output directory . If I comment out the above code the assembly is not copied to the output directory.

I guess Visual Studio copies the assemblies to the output directory of main project only if they are referred in the code. Another work around is to use the post build event to copy the dll to the output directory.

Sample:

http://cid-0476ca5e9f26e63c.skydrive.live.com/self.aspx/Public/Documents/WindowsApplication3.zip