Two MultiDimentionalArrayAsParameter tests failed on NET35 on some machine setup.

[jeremymeng]

Two tests failed in NET35 build one some machine setup (including AppVeyor default). For example: https://ci.appveyor.com/project/jeremymeng/core/build/3.3.4.1

• Castle.DynamicProxy.Tests.BasicInterfaceProxyTestCase.ProxyTypeWithMultiDimentionalArrayAsParameter
• CastleTests.BasicClassProxyTestCase.ProxyTypeWithMultiDimentionalArrayAsParameters

[jonorossi]

It looks like AppVeyor has all different versions of the Windows SDK installed. Do you know which peverify the unit tests are picking up on AppVeyor?

From the hardcoded list in the unit test source code our build server has a single version of the SDK installed and is picking up peverify from C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools. The Castle build server doesn't have Visual Studio installed, only the .NET Framework and Windows SDK.

The Castle build server didn't have the optional .NET 4.5.2 update installed, which I've now installed just for completeness even though it shouldn't touch the .NET 2.0 runtime, unit tests all still pass.

There is/was a defect in .NET 2.0-3.5 with multidimensional arrays and reflection emit that we had worked around quite a while back, but reading #47 it sounds like MSFT did end up backporting the fix to .NET 3.5. AppVeyor states they've got the older .NET runtimes, however maybe not all updates have been applied. Since the only two failing unit tests are with multidimensional arrays I highly suspect that'll be the problem.

[jeremymeng]

@jonorossi Yes it's definitely related.

On AppVeyor: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\peverify.exe
On my machine: C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\peverify.exe

I just tried the steps in https://support.microsoft.com/en-us/kb/960240 and the issue reproduces on my machine: the emitted assembly and the compiled assembly have different representations for the multi-dimensional arrays. My HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5 shows a version of 3.5.30729.4926 which should be .NET 3.5 SP1. What's the version on the Castle build machine? Is any other patch/hotfixes installed on that machine? It seems like the build machine has the fix.

[jonorossi]

My development VM: 3.5.30729.4926 (Windows 8.1)
Castle CI: 3.5.30729.4926 (Windows Server 2012, not R2)

I can't find any info on the MSConnect that we reported, the links just result in 404s, but this is what I dug up from our old issue tracker, there doesn't appear to have been an update released, and I know I didn't apply any hotfixes or QFE to that CI server:

• https://github.com/castleproject/castle-youtrack-export/blob/master/DYNPROXY/DYNPROXY-101.xml
• https://ayende.com/blog/2112/emitting-multi-dimentional-arrays

Under the assumption that there wasn't an update as it was only fixed in .NET 4.0 I investigated to see if the tests were actually being run under 3.5, and I've discovered they are not.

On our CI server I see the output in the build log for the 3.5 build:

[NUnitTeamCity] C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher.exe "@@" D:\temp\buildTmp\tmpEE31.tmp
[NUnitTeamCity] Start TeamCity NUnit Test Runner
[NUnitTeamCity] Running NUnit-2.5.5 tests under .NET Framework v4.0 x86

TeamCity is plugging in (configured in the build scripts) and taking over the running of unit tests and picks that runtime because we've got "MSBuild version: Microsoft .NET Framework 4.0" and "MSBuild ToolsVersion: 4.0" set in the build configuration properties because the build scripts needs MSBuild 4 to run the build scripts.

ReSharper wasn't running them on the CLR 2.0 because I had the "Default .NET Framework version: Automatic based on test project's target framework" ReSharper unit test runner setting set which picks CLR 4.0 because the project is configured "Target framework: .NET Framework 4.5".

Working on a fix to the build scripts at the moment.