Chunkify a String with Extension Method

Here's a dandy little string extension to help split strings into smaller chunks.

public static string[] Chunkify(this string source, int chunksize)
    List set = new List();
    int chunklength = chunksize;
    int stringlength = source.Length;
    for (int i = 0; i < stringlength; i += chunksize)
        if (i + chunksize > stringlength)
            chunksize = stringlength - i; // factor in the last chunk

        string tmp = source.Substring(i, chunksize);

    return set.ToArray();

Use it like this...

string mystring = "This is a sample string";
string[] chunkified = mystring.Chunkify(4);
Console.WriteLine(chunkified[1]);    // output is  "This"



Interesting IDE for building iOS apps using C#

Interesting IDE for building iOS apps using C#...




Run 32-bit SSIS package on 64-bit

I have been working on creating SSIS packages using Sql Server Data Tools in Visual Studio 2012.

I was running into a problem where I could run a package in Visual Studio, but it would not run when deployed to Integration Services on the same machine.  What's the difference?

My package is using an ODBC connection using a Data Source setup on my machine using a 32-bit driver.

Behind the scenes SSIS runs DTExec.exe to execute the packages.  The trick is that on 62-bit installations there are two different locations for DTExec.exe; one for 32-bit version and another for 62-bit version.

So to summarize... I've got an SSIS package that uses a 32-bit ODBC data source.  When I run in Visual Studio all is fine because Visual Studio uses 32-bit.  When I run in SSIS, I get errors because SSIS is calling a 64-bit version of DTExec which is then looking for my ODBC connection in the 64-bit Data Sources setup on the machine, which does not exist.

SO... I need to tell Sql Server SSIS to use the 32-bit DTExec even when running under 64-bit.

Don't worry, I am confusing myself at this point!  But let's just get to the solution...

The Fix

The fix for me was to edit the Registry settings for Sql Server and point the DTS path to the location of the 32-bit version of DTExec.

The registry setting for Sql Server 2012 is located in...

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\110\SSIS\Setup\DTSPath

Note: Edit registry at your own risk!

The default value is...

C:\Program Files\Microsoft SQL Server\110\DTS\

I changed it to...

C:\Program Files (x86)\Microsoft SQL Server\110\DTS\


There can be platform conflicts between data sources and the environment they eventually are called in.  This little trick helped me get my SSIS packages running again.  I hope it helps you, too.




Mouting ISO images in Windows

Found this nice little tool for mounting ISO images without having to burn DVD's...



Web Deployment Projects fix for Visual Studio 2012

Visual Studio 2012 has some great features for building new apps, but you may run into some issues with pre-existing applications.  In my particular case, I found that the "Web Site" project type will no longer support Web Deployment projects.

So, when I load up my solution in Visual Studio, I get an error about the Web Deployment project not being recognized.

"Web Application" projects are the ideal approach, and yes, I want to upgrade someday.  But that day is not today.  Today I need to get my project built using the same Web Deployment project file.

I know the Web Deployment project type is not available for VS 2012, but if I could at least build the project using the ".wdproj" file as a build script, I would be happy.

Here is how I created a work around...


First, Web Deployment projects are nothing more than an MSBuild project file with some custom build "targets".  In VS 2010, when you right-click on the Web Deploy project file and choose "build project", it would run MSBuild.

So... if we enable the build targets and still run MSBuild with the project file, we should be able to build our project.

Install Web Deployment Projects 2010

The Web Deployment project installer is still available from Microsoft.  When you install, it will add the build targets to this directory...

C:\Program Files (x86)\MSBuild\Microsoft\WebDeployment\v10.0

For clarity, I copied this directory to a new directory and called it "v11.0"

In this copied directory, open the file Microsoft.WebDeployment.targets in a text editor, and replace all instances of "VisualStudio\v10.0" with "VisualStudio\v11.0"

That should be enough to get the build targets working.

Update Web Deployment Project File

Now locate your Web Deployment project in Windows Explorer.  Open the .wdproj file in a text editor.

Near the bottom, there is a line that looks like this...

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\WebDeployment\v11.0\Microsoft.WebDeployment.targets" />


Change the "v10.0" to "v11.0" to point to your new targets file.

Run MSBuild

Run the Visual Studio command prompt and enter the following command (update paths for your project location)...

msbuild [path/to/your/site.wdproj] /property:Configuration=Release


I created a .bat file to save keystrokes, and I just copy the batch file to other projects and update the paths as needed.

Hope this helps someone else out there.



Month List


Martin is a .NET programmer in Western Pennsylvania.