0

I build a test project (CxxTest) with Visual Studio and immediately execute it via post-build event. This works and did so for a long time already. Now I have different behaviour in the execution in post-build event compared to manually execute from command line shell. The following code behaves different in post build event compared to starting the exe manually or with Visual Studio debugger:

// getValueFromStruct returns empty string when executed 
// as post build event, but returns correct value when executed manually
std::string expectedValue1("Val_1");
TS_ASSERT_EQUALS(expectedValue1, getValueFromStruct(res1));

This is the helper function called:

   std::string getValueFromStruct(tResult pResult)
   {
      std::string result = "";
      if (pResult.pCharDetails != NULL)
      {
         for (int i=0; i < pResult.iNumResults; i++)
         {
            result.append(1, static_cast<char>(pResult.pCharDetails[i].wChar1));
         }
      }

      // also the cout of the result is empty when executed from
      // build event, but is filled with data when in shell
      std::cout << ++callCount << " : " << result<< std::endl;
      return result;
   }

It seems the issue arises only when getValueFromStruct(tResult) is called for more than one instance of tResult in the same method.

Are there differences between environment, runtime library or something else between the two ways? Is Visual Studio manipulating the command line environment for a build event?

The issue arises in Release and x64 mode only. And it arises on my machine only, not on the build server. But it also arises when built on my machine via build script like the server does.

I found 3 ways to by-pass the problem:

  • by using a temporary variable rather than pass the result of a function directly as argument.
  • Disable Optimization for the test.exe
  • Set "Inline Function Expansion" to "Disabled /Ob0" for the test.exe.

But it does not explain why it is behaving differently in build event and regular command line.

this.myself
  • 2,101
  • 2
  • 22
  • 36
  • If you can catch the relevant process instance (`vstest.exe` ?) in Process Explorer, you can view it's command line and environment. Also, any chance that VS is running your tests in multiple threads? (just guessing, no clue if that's your problem, but something that could be looked at). – Chris O Mar 21 '16 at 13:28
  • @ChrisO There are some env. variables more when called from build event: caexcludepath, INCLUDE, LIB, LIBPATH, MsBuildLoadMicrosoftTargetrsReadonly, PkgDefApplicationConfigFile, VisualStudioDir, -Edition, -Version. When I look at their content, I don't think they have anything to do with the different behaviour, except maybe LIB or LIBPATH. But when I look the content, I think they are more for building and linking. In the there is nothing run multi threaded. – this.myself Mar 21 '16 at 14:21

0 Answers0