| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* [runtime] Fix mkbundle compilation on OSX
* [runtime] Add aot arguments to mkbundle
* [runtime] Enable compiling aot with mkbundle
* [runtime] Add new dedup interface to mkbundle
* [runtime] Fix path resolving for mkbundle
* [runtime] Use mkbundle in BCL tests
* [runtime] Skip building System.Security, System.IdentityModel tests on testing_aot_full
* [runtime] Fix in-tree building for mkbundle
* [runtime] Move testing dll into profile
* [runtime] Add target to mkbundle all tests before CI
* [runtime] Build stripper and use with mkbundle
Preliminary linker support ran into dependency-finding bug
with the monolinker.exe binary. Fix postponed until later.
* [runtime] Skip not supported tests with mkbundle
* [runtime] Don't re-aot when running BCL tests
* [runtime] Provide config to mkbundle
* [runtime] Fix mkbundle internationalization test results, build all
* [runtime] Clean up temp mkbundle aot directory
* [runtime] Add mkbundle support for dedup
* [runtime] Fix tracking of dedup module in mkbundle
* [runtime] Document mkbundle AOT options in man pages
* [runtime] Fix CADMessage generic method argument marshalling
|
|
This reverts commit 9a287c04126d095e7371afee32632febd0dafd93, reversing
changes made to 4a79280b3bef8d5f15da9ddd2a2af3a03e194b03.
It breaks tons of tests.
|
|
|
|
|
|
the AssemblyKeyFile attribute for consistency and to make it easier to do path name manipulation on the file name. (#5316)
|
|
|
|
|
|
|
|
|
|
|
|
Because nunit-lite runs everything in the same AppDomain, we can't use dll.config files for settings anymore.
Since a few test suites rely on being able to read those settings we need to patch them into the main
nunit-lite-console.exe.config file instead before the test.
Remove all _test.dll.config files and replace with nunit-lite patcher equivalent
|
|
Note: DISABLE_CAS_USE was removed in ed989a8e9e5c170b6d19edc60bb80e8a4e6d5cc0
|
|
Identity metadata is the exact, unmodified ItemSpec.
|
|
|
|
to appease MS msbuild
|
|
cyclic assemblies
|
|
|
|
* Adds support for a handful of new command line arguments that we now use in the build.
* Always attempts to match to a project name, to get the proper project dependency.
* Update to support .exe and .dll in the generation.
* Remove warnings and some dead code
* Update the resulting csproj files based on running:
make update-csproj
make package-inputs
mono genproj.exe
|
|
Process.Exited event can get invoked before the process has really
exited. So, accessing process.ExitCode before the real exit can throw:
Error executing task Exec: System.InvalidOperationException: Process must exit before requested information can be determined.
at System.Diagnostics.Process.EnsureState (System.Diagnostics.Process+State state) [0x000b9] in /Users/ankit/dev/mono/mcs/class/referencesource/System/services/monitoring/system/diagnosticts/Process.cs:1439
at System.Diagnostics.Process.get_ExitCode () [0x00000] in /Users/ankit/dev/mono/mcs/class/referencesource/System/services/monitoring/system/diagnosticts/Process.cs:219
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process:get_ExitCode ()
at Microsoft.Build.Utilities.ToolTask.ExecuteTool (System.String pathToTool, System.String responseFileCommands, System.String commandLineCommands) [0x00101] in /Users/ankit/dev/mono/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolTask.cs:185
at Microsoft.Build.Tasks.Exec.ExecuteTool (System.String pathToTool, System.String responseFileCommands, System.String commandLineCommands) [0x00026] in /Users/ankit/dev/mono/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/Exec.cs:83
at Microsoft.Build.Utilities.ToolTask.Execute () [0x0001c] in /Users/ankit/dev/mono/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolTask.cs:128
at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] in /Users/ankit/dev/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/TaskEngine.cs:134
at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x0008f] in /Users/ankit/dev/mono/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/BuildTask.cs:101
ProcessWrapper.WaitForOutput depends on the
`endEventExit`(ManualResetEvent) to be set, which is done in the event
handler for Process.Exited . So, effectively, WaitForOutput can return
before the process has really exited and ToolTask ends up throwing an
exception when it accesses the ExitCode.
Fix: Add a WaitForExit in WaitForOutput, to be sure!
|
|
We don't have .NEt 4.6 installed on all of our build machines, to
running mcs.exe on Windows fails, as it was built with .NET 4.6.
Instead, we will run mcs.exe via Mono on Windows (which is what happens
on OSX, although there the low-level Process class handles it).
To accomplish this, we run mcs.bat instead of mcs.exe.
|
|
|
|
use full path.
One of csc prerequisites because csc uses -lib as path which is considered after
RuntimeEnvironment.GetRuntimeDirectory which makes -lib useless
|
|
- make task resources available to TaskLoggingHelper
- verify TaskLoggingHelper method args
- tests
|
|
ProcessWrapper.OutputStreamChanged and ProcessWrapper.ErrorStreamChanged
The previous implementation of ProcessWrapper OutputStreamChanged and ErrorStreamChanged would manually launch a background thread to read on the process StandardOutput and StandardError, then simply passing the output to the OutputStreamChanged and ErrorStreamChanged events. This mean that even the newline characters would be passed to these events, leaving these events callbacks deal with splitting the output line by line.
On the other hand, Process.OutputDataReceived and Process.ErrorDataReceived already split the data line by line, and discard the newline character. That implies that, to keep the old ProcessWrapper behaviour, we need to add these newlines character before calling OutputStreamChanged and ErrorStreamChanged events callbacks.
|
|
We observe the following error when building XS:
"Threadpool worker" tid=0x0x7f011bfff700 this=0x0x7f01394bfb30 thread handle 0x432 state : not waiting owns ()
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Threading.WaitHandle.WaitAll_internal (System.Threading.WaitHandle[],int,bool) <0x0005d>
at System.Threading.WaitHandle.WaitAll (System.Threading.WaitHandle[]) <0x00026>
at Microsoft.Build.Utilities.ProcessWrapper.<Start>m__0 (object,System.EventArgs) <0x0008f>
at System.Diagnostics.Process.OnExited () <0x000ed>
at System.Diagnostics.Process.RaiseOnExited () <0x0009f>
at System.Diagnostics.Process.CompletionCallback (object,bool) <0x00017>
at System.Threading.RegisteredWaitHandle.DoCallBack (object) <0x00088>
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (object) <0x00058>
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) <0x001c6>
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) <0x00020>
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0x0004c>
at System.Threading.ThreadPoolWorkQueue.Dispatch () <0x001d6>
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0x00008>
at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) <0x0005a>
And the process output would contains a bunch of "_wapi_handle_ref: Attempting to ref unused handle 0x1234" and "_wapi_handle_unref_full: Attempting to unref unused handle 0x1234".
The expected behaviour is for WaitHandle.(WaitAll|WaitAny|WaitOne|SignalAndWait) and EventWaitHandle.Set to throw an ObjectDisposedException in case the WaitHandle (or one of them if calling WaitAll, WaitAny or SignalAndWait) have been disposed.
This error would be due to a race between ProcessWrapper.Dispose, which closes endEventOut and endEventErr, and the above Process.Wrapper.<Start>m__0 (the base.Exited) callback, which waits on endEventOut and endEventErr.
|
|
Microsoft.Build.Execution.BuildManagerTest.BasicManualParallelBuilds
The previous implementation of ProcessWrapper would launch its own threads to read on the process stdout and stderr. We can more simply use OutputDataReceived and ErrorDataReceived which will do the same under the hood. We use as well the Exited event to track the end of the Process.
|
|
They weren't updated in the last 6 years and aren't helpful anymore (e.g. by causing unrelated matches during git grep searches).
|
|
We only use the net_4_x profile now so those csproj's don't make sense anymore.
|
|
Commented the entries in ToolLocationHelper, they could be misunderstood since the 4.0/4.5/4.6 entries are all the same.
|
|
|
|
|
|
This reverts commit 51297ed7ab06480df84520c758639b6cef0790d9.
It caused a regression for escaped quotes (%22) in msbuild properties. See https://github.com/mono/mono/commit/51297ed7ab06480df84520c758639b6cef0790d9#commitcomment-11827605.
Disable test that now fails again after the revert. Add new test that verifies the behavior originally broken by the change.
|
|
NET_4_0 is always defined now, so the ifdefs are redundant.
I verified the libs are exactly the same after this change, so this is effectively a no-op.
|
|
|
|
|
|
|
|
The properties were introduced with MSBuild 4.0 (e.g. https://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.logstandarderroraserror(v=vs.100).aspx) and shouldn't be inside a XBUILD_12 ifdef.
|
|
variable which lists the assemblies a given assembly depends on to build.
|
|
|
|
|
|
|
|
|
|
|
|
insensitive dictionary. It shouldn't case insensitive on non-windows but that'd break msbuild compatibility
|
|
|
|
|
|
unifdef -t -DNET_2_0 -o <filename> <filename>.
|
|
|
|
It's a stub and is currently not used by xbuild.
|
