| Age | Commit message (Collapse) | Author |
|---|
|
With a multi-run configuration defined for the solution, if a
project is reloaded, the multi-run config would not have the
latest project run configuration. This would result in changes to
the project run configuration in project options, such as adding
or removing startup arguments, not being used when the multi-run
configuration was used to run the solution.
On reloading the new project run configuration is resolved and
updated in the multi-run configuration. Previously only the
SolutionItem was updated.
Fixes VSTS #653269 - Multi startup project run configuration -
arguments not passed after reload
|
|
Analyzer items were not being resolved so no analyzers were being
passed to the type system for SDK style projects. Non-SDK style
PackageReference projects were resolving Analyzer items. Projects
that use a packages.config have to explicitly use Analzyer items
in the project file.
To fix this the CoreCompileDependsOn targets is changed to include
the ResolveLockFileAnalyzers which resolves the Analyzer items.
This was already working for non-SDK style PackageReference projects
since the NuGet addin was adding the ResolveNuGetPackageAssets
target to the CoreCompileDependsOn targets and that resolves the
Analyzer items.
Fixes VSTS #1047893 - Analyzers not used by SDK style projects
|
|
[C#] Support CodeAnalysisRuleSet file
|
|
Remove various references to NRefactory that are not used
|
|
* [Mac] Set Marshal*Exception modes
This should prevent hard crashing when working with exception handling in xammac
* Remove these
* Modify tests
|
|
|
|
Adding a new project to an existing solution would trigger a null
reference exception in the CSharpCompilerParameters when the type
system service tried to use the project's configuration. This was then
breaking code completion for the NUnit library project when it was
added to an existing solution.
This was due to a change 18cf33d1855592cbdb2f54e7e0a4870f99a11485 where
the OutputType was only being set if the project file was read from disk
which is not the case when adding a new project from a template to an
existing solution.
Fixes VSTS #1048443 - No intellisense for NUnit types when adding a new
NUnit project to an existing solution
|
|
Editing an SDK project that targeted a single target framework so it
targets multiple target frameworks would result in the intellisense
not being updated from that point when the project changed, such as
when a new file was added.
The problem was that the Project.Modified event handler was removed
for the project when the old project was removed since the Roslyn
project id to project mapping had already been updated during the
reload to point to the new project. To avoid this a check is made to
ensure that no other project ids exist in the mapping before the
event handler is removed.
Fixes VSTS #1035311 - Wrong version of multi target project referenced
in .net framework project
|
|
NoWarn settings for suppressing warnings was not overridding the
configuration defined in the ruleset. This was incorrect based on the
Visual Studio on Windows behaviour.
|
|
If the CodeAnalysisRuleSet MSBuild property points to a file then
the ruleset information is applied to the project configuration's
compilater options.
Fixes VSTS #1040606 - StyleCop rules are ignored
Fixes VSTS #577079 - [Diagnostics] Implement RuleSet file support
|
|
An MSBuild expression such as the following will fail since the path
is not converted to a native path when not on Windows.
$(SrcRelativeProjectDirectory.IndexOf('/'))
Arguments passed were converted but the original string was not. To
match MSBuild's behaviour the conversion of the slash characters is
only done if the directory exists.
Fixes VSTS #1028961 - MSBuild Properties are not fully evaluated causing
build to fail
|
|
mono/ide-fix-msbuild-designtime-target-feedback-loop
[Ide] Type system updates file information less often
|
|
With a project that uses the DevExpress.Blazor NuGet package the IDE
would get stuck running MSBuild design time builds repeatedly. Every
MSBuild target that was run would trigger the DevExpress UpdateStatic
MSBuild target to run. This UpdateStatic target would delete and create
javascript files in the project. This then triggered the 'Files'
project modified event to fire. The type system then re-ran the design
time builds again since it uses this event as a trigger. This then
resulted in the design time builds being run repeatedly. The status
bar would repeatedly show messages, usually Saving, but sometimes some
version control messages.
To avoid this repeated calling of the MSBuild design time targets the
project now has a new CoreCompileFiles modified event which only fires
for a small subset of build actions - Compile, AdditionalFiles,
Analyzer and EditorConfigFiles. These build actions are the only ones
the type system is interested in so there is no need to re-run a design
time build to get the list of source files if files with different
build actions are added. This prevents the problem with the dev express
build targets since it adds/removes javascript files which are not
needed by the type system.
Fixes VSTS #1030001 - Stuck in constant loop of Saving -> Checkout of
files after building a solution.
|
|
The change make the call to RemoteBuildEngine.UnloadProject meant
that the engine in the RemoteProjectBuilder was being set to null
and the RemoteBuildEngineManager.ReleaseProjectBuilder was being
called with this null engine. Reworked the code so that if the
builder is being disposed then the call to ReleaseProjectBuilder
is done after the UnloadProject.
Also modified a builder test so it waits a while for the engine
count to be reduced since that is now done asynchronously.
|
|
Fix 1023494: Unsaved new documents have `/` added to begining of file name
|
|
Includes also test
|
|
Fix 1023500: When saving new document, tab title doesn't update
|
|
Instead of using custom ISerializable to serialize private fields, just expose it via ReadOnlyCollection
|
|
Main problem was that `IsNewDocument = false;` is called after `FilePath` is updated(which calls SetTitleEvent) which means logic for assigning untitled name was executed instead setting to `controller.DocumentTitle`, by moving code to `DocumentManager` we achieve following things:
1) Move logic specific to FileDocumentController out of SdiWorkspaceWindow.cs
2) Simplify logic in SdiWorkspaceWindow.cs(removal of `myUntitledTitle`)
3) And by moving logic of creating unique file name closer to start of document creation reduce change of bugs and code complexity that has to deal with file name change in middle of creation
Also added unit test for new code in DocumentManager
|
|
[Core] Support generating a binlog for any MSBuild target
|
|
|
|
|
|
|
|
|
|
|
|
Previously a binlog file would only be generated if a Build was run.
Now it is possible to have a binlog generated for any MSBuild target.
The filename for the bin log can be specified when running an MSBuild
target by setting the TargetEvaluationContext's BinLogFilePath.
Note that setting the BinLogFilePath if a build session is in progress
will not have any affect, the build session's binlog overrides this
setting.
|
|
[Windows] Fix build due to Xamarin.Mac reference
|
|
|
|
If a multi-target project used .NET Standard 2.1, or .NET Core 3.0, and
an older framework such as .NET Standard 2.0, or .NET Core 2.1, then
the Solution window would not show the correct folders under the
Dependencies folder. If the first target framework was .NET Standard
2.0 then an SDK folder would be displayed for all frameworks. If the
first target framework was .NET Standard 2.1 then a Frameworks folder
would be displayed for all frameworks.
The problem was that there was no multi-target support for
FrameworkReferences. Each framework that supports FrameworkReferences
needs to have the ResolveFrameworkReferences MSBuild target called
separately. Also all project target frameworks are checked individually
when building the Solution window tree nodes. Previously the first
target framework was being considered when building the Frameworks
folder.
Fixes VSTS #1001442 - [Multitargeting] Incorrect Framework version
|
|
Defining a property that used an MSBuild instrinsic function would
not evaluate if the case did not match. For example:
<PropertyGroup>
<IsMac>$([MSBuild]::IsOsPlatform('OSX'))</IsMac>
</PropertyGroup>
This would not evaluate to true since the instrinsic function's
case is IsOSPlatform. However MSBuild on the command line would
evaluate this correctly.
Fixed this by making the method cache lookup case insensitive so it
matches MSBuild's behaviour.
Fixes VSTS #1008396 - DefineConstants not working right if they are
set in imported projects
|
|
mono/project-modified-references-fired-when-references-not-modified
[Core] Fix project modified fired for refs when they have not changed
|
|
|
|
|
|
and close operations to finish
Fixes VSTS #1006925 - Leak test random failure due to flakey test
|
|
[NuGet] Update multiple packages together in a batch
|
|
Remove RefactoringEssentials
|
|
Updating a package for multiple projects in one step results in the
NuGet package restore that is done at the end being a no-op. This
means that the project is not re-evaluated which can mean that the
AvailableItemNames are not updated. Updating a single NuGet package
does not have the same problem.
Also fixed a problem where a PackageReference project (non-sdk) was
not re-evaluated on restoring. This could also result in the
AvailableItemNames not being available to the project if the project
was missing its obj/project.assets.json file on being opened in the
IDE.
|
|
Updating two NuGet package references that have a strict dependency
on a single version of another NuGet package not explicitly added
to the project would fail in the Manage NuGet Packages dialog. This
was because the update would be done one package at a time. Doing
the update of the two NuGet packages together allows NuGet to
update both so they then use the new strict dependency.
Note that updating all packages in the project from the Solution
window does not have this problem since there the packages are
updated together in a batch.
Fixes VSTS #986960 - Solution nuget updater fails to update a set of
packages that all have a related dependency update
|
|
Originally the Project.Modified event was fired with a Hint set to
References when a ProjectReference was added to or removed from the
project. This was changed in commit 90d690e56f2e100d8dea11bf3ad690f9eefaeb4f
and now the event is fired for any ProjectItem being added/removed.
This can cause the type system to try to update its type information
when it should not. One example is updating a NuGet PackageReference
which would trigger this event before the updated reference information
will be available for the type system.
Fixes VSTS #992017 - Modified event fires for References when non
reference added/removed from project
|
|
Many of these fixes are redundant with Roslyn or broken in C# 8.
Removing them increases consistency with Windows.
We can always restore any especially popular ones with an extension.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/893943
|
|
DebuggerCompletionProvider.GetExpressionCompletionDataAsync
Test that we return null if the stack frame location is past the end of the file (when the file is changed to be smaller since building/running)
|
|
|
|
If an editorconfig file was changed externally, or edited in the text
editor, the changes would not affect the open solution until it was
closed and re-opened again. To support this the Roslyn workspace
needs to know when the editor config file has changed externally
by calling OnAnalyzerConfigDocumentTextChanged. When the editorconfig
file is open in the text editor the Roslyn workspace needs to be
told the file has opened via OnAnalyzerConfigDocumentOpened and
when it has closed via OnAnalyzerConfigDocumentClosed. Then all changes
made in the editor are handled by Roslyn and the analyzers are re-run.
Fixes VSTS #706520 - Analyzers not retriggered on editorconfig change
|
|
Use MSBuild to find AdditionalFiles and EditorConfigFiles and pass
these to Roslyn when creating the documents for the Roslyn project.
Fixes VSTS #963753 - Migrate editorconfig support to use new
workspace-based approach
|
|
Handle other MSBuild targets failing when calling the MSBuild target
ResolveFrameworkReferences by setting ContinueOnError to
ErrorAndContinue. Previously if there was any other failure the
design time build would stop even though the main msbuild target
may work and return some references.
|
|
Set ContinueOnError=ErrorAndContinue when running the MSBuild target
ResolvePackageDependenciesDesignTime. This allows the target to
run even if one of other MSBuild targets fails. For example, an
unknown PackageReference may cause this to fail unless continue on
error is set.
|
|
If a PackageReference could not be resolved then no assembly
references would be given to the type system from the DotNetProject's
GetReferencedAssemblies. Whilst the NuGet restore may fail the
project.assets.json file is created and reference information is
available. The ResolvePackageAssets target was failing which then
stopped the ResolveAssemblyReferencesDesignTime target from being run.
Visual Studio on Windows avoids this problem by setting the
ContinueOnError property to ErrorAndContinue. This allows all the
targets to run even if some of them fail. It also allows references
to be returned and provided to the type system service for the
PackageReferences that can be determined.
Fixes VSTS #998324 - NuGet Package Restore causes BCLs to not be
defined/imported
|
|
Fixes redundant string copying in msbuild evaluation
|
|
[Ide] Rework GetWorkspaceAsync to cancel requests on any solution dispose
|
|
Address PR comments for new doc model post-merge
|
