Thursday, 30 August 2012

Installing .NET 4.5 (or VS.NET 2012) causes MSB3270

After installing .NET 4.5 (or VS.NET2012 which installs the former), it is possible that previous projects build in VS.NET2010 start warning:

MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference

This is a legitimate warning. It warns about platform mismatches; for example in my case a project that targets "AnyCPU", but has an x86 dependency within it. As I said, this is a legitimate warning, but it is a bit to naggy in our circumstances: although the project is built with an x86 dependency, at runtime a x64-bit version is loaded on x64 machines. You could argue this is not the right way to do it and in fact entirely separate x64 and x86 builds should exist, but this is the way it is.

Fortunately there is a workaround as described in the .NET 4.5 readme:


3 .Net Framework Product Issues

1.3.1 General Issues

1.3.1.1 After the .NET Framework 4.5 is installed, the MSB3270 warning occurs in builds in Visual Studio 2010
Some project types in Visual Studio 2010 - for example, C++ projects - set the Platform property but don't set the PlatformTarget property. When PlatformTarget isn't set, MSBuild can't determine the project architeture - for example, x86. Instead, it assumes that the project target is Any CPU and throws architecture-mismatch warning MSB3270 even if the project and references are targeting the same architecture.
To resolve this issue:
  • In the project file, set the PlatformTarget property to the appropriate value - for example:
    <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>
    </PropertyGroup>
-or-
  • Ignore the warning.
-or-
  • In the project file, suppress the warning:
    <PropertyGroup>
    <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
    </PropertyGroup>

Friday, 3 August 2012

SSIS Merge Join fails with indeterminate results

With an SSIS Merge join, the ordering of the columns on which the join takes place is critical. Get them wrong - by defining the IsSorted property to true on the data source and setting the wrong SortKey properties - and you get interderminate results. These are the worst kind - there are no errors and your join fails occassionally (depending upon the data being operated upon).

The safest thing to do is to manually sort the columns within the SSIS package using the Sort task. Sure, it may consume some additional CPU cycles, but it'll save you a world of pain when some data is (or isn't) being returned from the merge output when you least expected it.