| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- and save only at the end.
|
|
- the recent msbuild update changed the toolsVersion from `15.0` to
`Current`.
- we add a second toolset `Current` to the app.config for the remote
builder.
- VSMac still tries to pick `15.0`
- with older mono, msbuild will use the 15.0 toolset
- with newer mono, vsmac asks for 15.0 but msbuild picks
`current` instead.
- VSMac needs to pick `Current` for newer mono, which will be fixed in a
follow up PR.
|
|
* [Ide] Remove LastBuildResult.
It's just caching the value, and it's not used anywhere, so remove it
* [Core] Dispose release refs to various items to help diagnose leaks
Keeping onto the AsyncOperation means that we will keep some data
alive, in this case, quite a few megabytes, due to log writing
Fixes VSTS #773051 - Possible leak of large data via AsyncOperation
* [Core] Use a static handler to avoid retention
* [Ide] Avoid possible race in currentBuildOperation handling
* Simplify code
|
|
|
|
On Windows make sure the right VS paths are set in the MSBuild Toolset such that building projects works.
Also fixes the Windows aspect of https://github.com/mono/monodevelop/issues/4386.
|
|
MSBuild has replaced the NuGet SDK resolver with an .xml manifest file which points to the location where to find the NuGet SDK resolver on disk. See this change for details:
https://github.com/Microsoft/msbuild/pull/3246
|
|
|
|
xbuild is deprecated and msbuild support is solid, there's
no reason to support xbuild any longer.
Getting rid of this baggage allows us to depend on things that
only work in MSBuild.
|
|
|
|
Dispose all project builders when shutting down the engine. This should fix
hangs caused by projects that have not been disposed.
|
|
* Get rid of some exceptions that occur during project open
* Revert removal of exception due to Process.GetProcessById call as the fix was a little bit slower.
|
|
|
|
|
|
|
|
MSBuild on the command line defines the MSBuildSDKsPath globally in
its MSBuild.dll.config file. The MSBuild engine host that is used
when building in the IDE now defines also the MSBuildSDKsPath property.
This fixes a build error when using Xamarin.Forms 2.4.0 in an sdk style
project that targets .NET Standard. Xamarin.Forms 2.4.0 uses default
item imports which are not included since they are conditionally
imported:
<Import Project="$(MSBuildThisFileDirectory)Xamarin.Forms.DefaultItems.props" Condition="'$(MSBuildSDKsPath)'!=''" />
If the sdk style project has a .xaml file and a .xaml.cs file then
the xaml.g.cs file will not be generated when the project has no files
defined in the project since the default items are not imported. This
then causes a build error about the InitializeComponent method not
being defined.
|
|
Before shutting down a remote builder make sure that all remote calls have
been completed. It avoids unnecessary exceptions that might happen if
the builder is shut down too early.
|
|
Also added unit test
|
|
Instead of setting the solution configuration mapping every time a project
is built, do it when the build session starts.
|
|
This commit introduces some changes in the msbuild support classes to allow
building several projects in a single MSBuild session. By doing this, build
times on big solution are significantly reduced since MSBuild can resuse
cached project information. Here is a summary of changes:
All remote builder handles has been removed from MSBuildProjectService and
moved to a new RemoteBuildEngineManager class. This new class takes care
of starting and disposing builders, and it also manages build sessions.
SolutionExtension has new virtual OnBeginBuildOperation and
OnEndBuildOperation methods that are called when a build session starts
and ends. Build sessions are implicit for now. For example, when
a project with dependencies is built, which implies building several
projects, OnBeginBuildOperation is called before the first project is built,
and OnEndBuildOperation after the last project is built.
MSBuildSolutionExtension is a new solution extension that is in charge
of starting and finishing build sessions. Build sessions are specific
to MSBuild, so this is handled in an MSBuild specific extension.
RemoteProjectBuilder has been simplified. ResolveAssemblyReferences()
and ResolvePackageDependencies() have been moved to the DotNetProject
class, and are now implemented using which the standard RunTarget method.
Also the class is now used through a IRemoteProjectBuilder interface,
which is disposable, so clients can just request a builder and
dispose it when done.
A new ClearCachedData() has been added to SolutionItem, and it can
be called at any time to dispose cached data related to the project.
DotNetProject now caches assembly and package references, so it
overrides OnClearCachedData() to clear them when there are changes
in the project.
Builder handling inside the Project class has been simplified.
The project doesn't hold a reference to a project builder anymore,
it gets the builder when it needs it to run a target, and releases
it when done. There is also an explicit distinction between
long operations (such as Build), and short operations (such as
resolving references). This is used by the builder manager to
optimize the use of remote builders.
Build log handling had to change a bit since when using build sessions
MSBuild only allows specifying loggers at session level, not at
project level, while MD handles log at project level. The solution
is to have a single build session logger in the builder, and
redirect the log to a specific project logger every time a new
project build starts.
|
