| Age | Commit message (Collapse) | Author |
|---|
|
|
|
need to create a new concat iterator
This should optimize GC memory pressure more on this code path. In case the result returned recursively by ExpandWildcardFilePath is Enumerable.Empty, we can optimzie and not create a new Enumerator for the second one.
|
|
Instead of doing the recursive matching by manually recursively descending via a parameter, use the filesystem's APIs to check the nested directories to validate the data
|
|
|
|
[Core] Avoid allocating strings for keys when loading the MSBuild pro…
|
|
[Core] Remove redundant condition checks
|
|
Unroll LINQ in a loop code, use lambda instead of delegate notation
and remove an unused method
|
|
SafeParseAndEvaluate already does a check for the condition being empty. Remove the redundant checks and invert some conditions
|
|
|
|
Initial work towards optimizing FileService handlers
|
|
Use UserException when throwing an SDK not found error. This allows
a short error message and then a longer error details message to
be reported to the user with better formatting. Note that the
Solution pad will only show the short error message. On loading the
project into the IDE the short and longer error messages are
displayed.
|
|
If an SDK cannot be resolved using the MSBuild SDK resolvers then
an exception is now thrown so the error is reported in the IDE.
Previously the error would be logged in the IDE log and the error
displayed in the IDE would usually be a confusing 'Invalid
configuration mapping'. This also makes the behaviour more consistent
with Visual Studio on Windows.
Fixes VSTS #588773 - Add support for NuGet SDK resolver
|
|
|
|
Fixes VSTS #853896 - [Feedback] Visual Studio freezes when i run mono
Fixes VSTS #902435 - Investigate performance issue with FileSystemWatcher
|
|
Creating a blank F# Xamarin.Forms project and then installing a NuGet
package into the .NET Standard project would result in the file
nesting being broken in the Solution pad. The MainPage.xaml.fs file
would be nested underneath the App.xaml file.
The problem was that on saving the project the MSBuildItem that was
associated with the Update glob was being used as the SourceItem for the
.xaml.fs files. This resulted in the Update glob item that defined
the DependentUpon metadata value of '%(FileName)' being modified on
saving with the evaluated name of the .xaml file. Then when the
project was re-evaluated the file nesting was then broken since the
DependentUpon had App.xaml set for all files.
To fix this the MSBuildItem will look for a SourceItem that has the
same parent as itself. For the .fsproj this means the last MSBuild
item in the project for that file will be used instead of the MSBuild
item from any .targets imported afterwards, such as the
Xamarin.Forms.DefaultItems.targets file.
Fixes VSTS #636641 - Adding a nuget to an F# Xamarin Forms app breaks
the file nesting
|
|
* Misc perf improvements immediately after project load
* Use ImmutableDictionary<TargetFramework>, CWT won't work - the strings are collected
* Dump
* Use DefaultScheduler via Task.Run, Task.Factory is context dependent
* [AssemblyBrowser] Cleanups, mostly related to task usage
* [Debugger, VCS] Some Task.Factory fixes
Fixes VSTS #900427 - Review usage of Task.Factory.StartNew
* Use ordinal comparisons here
* [ASsemblyBrowser] Fix child nodes not appearing in the list
* [VCS] Fix improper usage of cancellation token source
* Remove unneeded string ordering
* [AsssemblyBrowser] Fix workspace leak and delay project loading.
It's not common to get to a project item from the IDE, so we can delay loading that while we get everything else setup
* [MSBuild] Switch this to Task.Run, so we don't accidentally parse on the UI thread
* Add doc comment
* [AssemblyBrowser] Massively improve time it takes to open and a couple of fixes
Reuse the typesystem created for decompilation. No need to create a new one just to load
the treeview.
Prefer using AddChildren everywhere rather than Add. This helps not sort the tree every time
we're adding an element.
Don't bother gathering all the types in an assembly. Most likely we will only need to gather
types from just one assembly, so defer that to the namespace node builder.
Fix multiple iteration of a type's members when trying to load a project metadata view.
And fix nested types to appear in the tree.
* Optimize this a bit more
* Minor refactors to avoid extra Funcs
* Reuse typesystem for loader, add new feature transform to prevent language breaking
|
|
Saving an SDK style project that set ToolsVersion="Current" would
fail as an attempt was made to parse the version using System.Version.
System.ArgumentException: Version string portion was too short or too
long.
Parameter name: input
at System.Version.ParseVersion
Fixes VSTS #897947 - SDK Projects with ToolsVersion="Current"
|
|
|
|
Move SDK style project specific code out of the .NET Core addin into
MonoDevelop.Core. NuGet specific code has been moved into the NuGet
addin. The DotNetCoreProjectExtension was supporting all SDK style
projects now it supports .NET Core and .NET Standard projects that
use the .NET Core SDK.
Fixes VSTS #830544 - Split out SDK style project support from the
.NET Core addin
|
|
|
|
Set a flag on the UserException when encountering an unknown project at load
time to prevent it being shown to the user because the error is already shown
in the solution pad.
Fixes VSTS #851602
|
|
Support ItemDefinitionGroup
|
|
MSBuild 16 uses Current as its directory instead of a numberered
directory such as 15.0.
Use Current for the MSBuildToolsVersion to support MSBuild 16.0.
Look for the Current directory when finding the MSBuild bin path.
Fixes VSTS #831219 - 6.x Mono MSBuild support is broken
|
|
Project items in SDK style projects now have properties from item
definitions available. Changed the implementation so that instead
of trying to use the evaluated item definition properties from the
main MSBuildProject, which did not work for update items since
the MSBuildItem had a different parent MSBuildProject, now the
properties are copied across to the evaluated item if they do not
exist already.
|
|
Properties can be overridden by later item definitions for the same
item.
|
|
Metadata defined by items in an ItemDefinitionGroup are now available
on project items when the project is loaded.
Creating a new project item does not use this metadata currently.
Also multiple item definitions for the same item are not handled.
|
|
ItemDefinitionGroups are now loaded when the MSBuildProject is
loaded. Nothing is currently using this information.
|
|
- 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.
|
|
Building an ASP.NET Core project, that restores missing NPM modules
during the build, was causing the IDE to use a lot of CPU and the build
would seem to never end. The IDE was spending its time checking to
see if the created file should be automatically added to the project
and for an NPM restore this can involve thousands of files. The problem
is that the file system watcher in Mono, which is now used, fires file
creation events on thread pool threads. Previously the file watcher
would use a single thread. Many thread pool threads end up processing
these events concurrently, using resources, and the build would never
seem to end. Previously with the single thread processing the file
creation events the build would finish and the events would continue
to be process afterwards.
To avoid this problem the IDE now checks to see if the file is
excluded when looking to see if the file should be added to the
project. This avoids the slower check that is done when seeing if the
file should be included for a particular file glob. Before the exclude
check was done after it was determined the file was included in the
file glob. For ASP.NET Core projects the files in the node_modules
directory are excluded by imported file globs.
Fixes VSTS #835962 - Cannot stop SmartHotel360 solution build
|
|
|
|
Creating a new Xamarin.Forms solution would sometimes log an error
about project unloading failing due to a connection closed error.
On opening a solution the NuGet restore runs. If a project is a
.NET Standard project then the project will be re-evaluated after
the restore. The re-evaluation will shutdown the project builders.
This shutdown will call RemoteBuildEngineManager.UnloadSolution
which will shutdown project builders and shutdown the remote
builder process. Shutting down the project builder can result
in an unload project request being sent to the remote builder host.
Shutting down the remote builder process will result in a stop
process message sent to the remote builder host which will abort
any messages that have not been processed. Both the project builder
shutdown and the remote builder host shutdown run in parallel on
background threads, since they are run by using ContinueWith. This
can result in both these actions happening at the same time causing
the unload project request to be aborted and an error message
returned from the remote builder host. Now a check is made to see
if the remote builder host is alive and if it is not the error
is not logged.
Fixes VSTS #818682 - Project unloading failed - System.Exception:
Connection closed
|
|
|
|
* Remove some obsolete members
* Remove unused C# policy item
* Make toolbox item internal
* Remove obsolete ToggleCategoryMode method
* Remove obsolete XmlSchemaCompletionData constructor
* Remove obsolete CloseAllDocuments
* Remove RPC.Disconnect obsolete method
* Remove obsolete Fold API
* Remove obsolete IsCompileableFile
* [MSBuildFileFormat] Add IEquatable and IComparable interfaces
|
|
The SdkResultImpl was hiding the SdkResult's Version and
Path properties causing a Sdk Resolver test to fail.
|
|
Ensure sdk name with different case can be matched by the MonoDevelop
sdk resolver.
Ensure that the MSBuild version is passed to the sdk resolvers.
|
|
The DotNetMSBuildSdkResolver needs the MSBuildVersion to be set on
the SdkResolverContext. Without this if an sdk cannot be resolved
by the MonoDevelop sdk resolver or the NuGet sdk resolver then the
DotNetMSBuildSdkResolver will fail with an error:
System.ArgumentNullException: Value cannot be null.
Parameter name: v1
at System.Version.op_LessThan (System.Version v1, System.Version v2) [0x00003]
in mono-x64/mcs/class/referencesource/mscorlib/system/version.cs:452
at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.Resolve (Microsoft.Build.Framework.SdkReference sdkReference, Microsoft.Build.Framework.SdkResolverContext context, Microsoft.Build.Framework.SdkResultFactory factory) [0x000b7]
in cli/src/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs:71
at MonoDevelop.Projects.MSBuild.SdkResolution.GetSdkPath (Microsoft.Build.Framework.SdkReference sdk, MonoDevelop.Projects.MSBuild.ILoggingService logger, MonoDevelop.Projects.MSBuild.MSBuildContext buildEventContext, System.String projectFile, System.String solutionPath) [0x00055]
in main/src/core/MonoDevelop.Core/MonoDevelop.Projects.MSBuild/SdkResolution.cs:64
Fixes VSTS #706541 - ArgumentNullException in DotNetMSBuildSdkResolver
Resolve
|
|
|
|
* [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
|
|
|
|
|
|
|
|
Check the project builder could be referenced in the Task
continuation and if not remove it from the list of builders.
|
|
Reworked the logic to handle a project builder shutting down inside
the RemoteBuildEngine's GetRemoteProjectBuilder instead of having
the project builder remove itself from the list of builders when
ReleaseReference is called. The build engine checks the return value
of AddReference and if this false, which means the builder is shutting
down, it is removed from the list of builders and a new one is
created.
|
|
If the project is reloaded or disposed whilst an MSBuild target
is being run by the project builder this can result in the next
MSBuild target using the same project builder, but failing to
increase its reference count since it will be shutdown. Then
a null reference exception can be thrown if the build engine
is used since it will be set to null on disposing the builder.
Fixes VSTS #740214 - NuGet packages are not getting restored for
ASP.NET Core projects with error "System.NullReferenceException"
|
|
Added an MSBuildProcessService which can be used to directly run
msbuild.
|
|
This avoids some double evaluation of some values in cache of a cache miss
Fixes VSTS #719402 - Look for locked immutable collections and use ImmutableInterlocked
|
|
[IDE] Fix copy/paste of xaml files does not group them in Solution window
|
|
|
|
|
