3

I am using tlbexp.exe to generate a type library from a C# project. The project contains 2 files - let's call them F1 and F2 - with COM interface declarations. F1 and F2 contain identifiers that differ in case only (F1 has property "Foo", F2 has variable name "foo"). Because of this I am affected by the "MIDL changes the case of identifier in generated type library" problem (cf. this MSDN article, or also this SO question).

Now the interesting thing is that tlbexp.exe sometimes produces a type library that is correct, and sometimes it produces a type library that is incorrect:

  • If I compile the project on branch A on my dev machine, the type library is correct. This means that tlbexp.exe has seen the files in order F1, F2
  • If I compile the project on branch B, on the same machine, the type library is incorrect. tlbexp.exe has seen the files in order F2, F1.
  • If I compile the project on the build server, the type library is correct for both branches!
  • If I compile the project on a fellow developer's machine, I get the same results as on my own dev machine (i.e. OK for branch A, fail for branch B)
  • The projects on branch A and B are identical - I have checked this by recursive-comparing all files/folders.

Now my question is: What is causing this weird and non-determenistic behaviour of tlbexp.exe? Note that I am asking this question out of curiosity - I have already solved my type library problem by merging the two files F1 and F2 into one.

In case it's important: I have Visual Studio 2010 SP1, and my projects are set up to use .NET 4.

The answer to this SO question claims that it's the compilation order that is non-deterministic. I find this hard to believe - given the exactly same input and the exactly same build tools, non-deterministic behaviour would mean that the build tool makers must have equipped their build tools with a "random generator" that makes sure that compilation order is not the same every time. Isn't that pretty unlikely? Or am I overlooking something?

Having said all that, I have tried to verify the compilation order by increasing the MSBuild build output from "minimal" to "diagnostic". Looking at the build output, I see a line like this for a build that fails:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe [...] F1.cs F2.cs [...]

As you can see, the files appear in the correct order F1, F2. I compared this with a successful build, and the csc.exe command line is exactly the same. So it really seems as if compilation order is not the problem.

EDIT: I understand that tlbexp.exe may not be the root cause, so the title of this question may be somewhat inadequate.

Community
  • 1
  • 1
herzbube
  • 13,158
  • 9
  • 45
  • 87
  • I've run into this problem before and from my experience your best off renaming one of the identifiers. It sucks but it will save you a *lot* of pain here. – JaredPar Jan 07 '14 at 14:43
  • Compiler multi-threading could cause non-deterministic build behavior without anyone throwing in a "random generator." I cannot say whether that is the case here, but it is certainly possible. – Andrew Sep 01 '14 at 16:52

0 Answers0