Bug 19380 - "make check" fails on MonoTests.Microsoft.Build.BuildEngine.ImportTest.TestImportWildcard
Summary: "make check" fails on MonoTests.Microsoft.Build.BuildEngine.ImportTest.TestIm...
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: Ms.Build ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-04-29 12:49 UTC by Andrea Canciani
Modified: 2014-05-02 11:46 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Log of the failure (5.78 KB, application/octet-stream)
2014-04-29 12:49 UTC, Andrea Canciani
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Andrea Canciani 2014-04-29 12:49:46 UTC
Created attachment 6677 [details]
Log of the failure

If "make check" is executed without installing beforehand, it will fail when testing MonoTests.Microsoft.Build.BuildEngine.ImportTest.TestImportWildcard with the xbuild_12 profile.

The failure also occurs when checking that specific fixture in the net_4_5 profile ("cd mcs/class/Microsoft.Build.Engine/ && make check PROFILE=net_4_5 FIXTURE=Microsoft.Build.BuildEngine.ImportTest"), but it succeeds when the whole library is tested ("cd mcs/class/Microsoft.Build.Engine/ && make check PROFILE=net_4_5 FIXTURE=Microsoft.Build.BuildEngine"). This is probably caused by state (in the form of loaded assemblies) that is persisted between different tests.

The test succeeds for both xbuild_12 and net_4_5 if it is run after "make install", which presumably means that it tries to use assemblies from the GAC.

I have tried to track down the issue, but I got lost in the code which resolves the assemblies and loads them.
What is the best route towards understanding the issue?
Comment 1 Mikayla Hutchinson [MSFT] 2014-04-30 18:59:03 UTC
Not sure, the test runner defines MONO_PATH which AFAIK should allow the runtime to find the assemblies. Maybe Assembly.Load isn't respecting Mono_PATH for some reason?
Comment 2 Andrea Canciani 2014-05-01 06:17:52 UTC
I managed to collect some more information.
Apparently MONO_PATH is respected, but it mostly contains relative paths.
This conflicts with the changes of the working directory performed while building the project.

In particular, the assembly "./../../class/lib/net_4_5/Microsoft.Build.Utilities.v4.0.dll" is correctly loaded relative to "/Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine", then the path is changed here:

SetCurrentDirectory /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Test/resources
   at System.Environment.get_StackTrace() in /Users/ranma42/Code/sharp/mono/mcs/class/corlib/System/Environment.cs:line 261
   at System.IO.Directory.SetCurrentDirectory(System.String path) in /Users/ranma42/Code/sharp/mono/mcs/class/corlib/System.IO/Directory.cs:line 413
   at Microsoft.Build.BuildEngine.Project.Build(System.String[] targetNames, IDictionary targetOutputs, BuildSettings buildFlags) in /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs:line 296
   at Microsoft.Build.BuildEngine.Project.Build(System.String[] targetNames, IDictionary targetOutputs) in /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs:line 276
   at Microsoft.Build.BuildEngine.Project.Build(System.String[] targetNames) in /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs:line 269
   at Microsoft.Build.BuildEngine.Project.Build(System.String targetName) in /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs:line 263
   at MonoTests.Microsoft.Build.BuildEngine.ImportTest.TestImportWildcard() in /Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Test/Microsoft.Build.BuildEngine/ImportTest.cs:line 256
   at System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod , System.Object , System.Object[] , System.Exception ByRef )
   at System.Reflection.MonoMethod.Invoke(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) in /Users/ranma42/Code/sharp/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:line 230
   at System.Reflection.MethodBase.Invoke(System.Object obj, System.Object[] parameters) in /Users/ranma42/Code/sharp/mono/mcs/class/corlib/System.Reflection/MethodBase.cs:line 114
   at NUnit.Core.Reflect.InvokeMethod(System.Reflection.MethodInfo method, System.Object fixture, System.Object[] args) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/Reflect.cs:line 412
   at NUnit.Core.Reflect.InvokeMethod(System.Reflection.MethodInfo method, System.Object fixture) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/Reflect.cs:line 397
   at NUnit.Core.TestMethod.RunTestMethod(NUnit.Core.TestCaseResult testResult) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestMethod.cs:line 254
   at NUnit.Core.TestMethod.doTestCase(NUnit.Core.TestCaseResult testResult) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestMethod.cs:line 237
   at NUnit.Core.TestMethod.doRun(NUnit.Core.TestCaseResult testResult) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestMethod.cs:line 195
   at NUnit.Core.TestMethod.Run(NUnit.Core.TestCaseResult testResult) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestMethod.cs:line 164
   at NUnit.Core.NUnitTestMethod.Run(NUnit.Core.TestCaseResult testResult) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/NUnitTestMethod.cs:line 32
   at NUnit.Core.TestCase.Run(EventListener listener) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestCase.cs:line 58
   at NUnit.Core.TestCase.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestCase.cs:line 42
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.TestFixture.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestFixture.cs:line 35
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.TestSuite.RunAllTests(NUnit.Core.TestSuiteResult suiteResult, EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 288
   at NUnit.Core.TestSuite.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestSuite.cs:line 166
   at NUnit.Core.SimpleTestRunner.Run(EventListener listener, ITestFilter filter) in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/SimpleTestRunner.cs:line 145
   at NUnit.Core.TestRunnerThread.TestRunnerThreadProc() in /Users/ranma42/Code/sharp/mono/mcs/nunit24/NUnitCore/core/TestRunnerThread.cs:line 149
   at System.Threading.Thread.StartInternal() in /Users/ranma42/Code/sharp/mono/mcs/class/corlib/System.Threading/Thread.cs:line 691

After the SetCurrentDirectory, the current path becomes "/Users/ranma42/Code/sharp/mono/mcs/class/Microsoft.Build.Engine/Test/resources" and "./../../class/lib/net_4_5/Microsoft.Build.Tasks.v4.0.dll" is not found because the current path is now two levels deeper.

I'm still not sure where the fault lies:
 - should relative paths in MONO_PATH be resolved to absolute paths at launch time (so that they are not affected by changes in the working directory)?
 - should the Microsoft.Build system ensure that assemblies are loaded without any change in the path?
 - should Microsoft.Build completely avoid to change the path?
Comment 3 Andrea Canciani 2014-05-01 07:21:54 UTC
Based on the assumption that MONO_PATH is mainly used for debugging (see http://mono-project.com/Best_Practices#MONO_PATH ) and that in this perspective it is more convenient to use it to set the assembly paths at launch time than to provide a sequence of options of relative paths in which mono can search, I went for #1 (i.e. canonicalize the paths in MONO_PATHS) and implemented it: https://github.com/mono/mono/pull/1013
Comment 4 Mikayla Hutchinson [MSFT] 2014-05-01 14:55:40 UTC
Your fix looks like the best one IMO.

MSBuild expected behavior when building is that the working directory is the directory that contains the project.
Comment 5 Rodrigo Kumpera 2014-05-02 11:46:18 UTC
Merged the fix.