| 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
|
|
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
|
|
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
The DotNetProject's GetReferencedAssemblies method was not returning
all references used by a project. A project may define extra
assemblies by adding ReferencePath items. These were being
filtered out since only the output parameters defined by the targets
ResolveAssemblyReferencesDesignTime and ResolveProjectReferencesDesignTime
which missed some references.
Fixes VSTS #991961 - Project model reports wrong references for
WebTools projects
|
|
|
|
[Core] Prefer Compile items over None items
|
|
Project.GetSourceFilesAsync will add the Compile items it gets from
CoreCompileDependsOn to the HashSet before adding the evaluated items.
This prevents None items being used instead of Compile items where
an SDK project does not remove duplicate None items. A project that
does the equivalent of the following would result in code completion
not showing target frameworks in the text editor's navigation bar
for a multi-target project.
<Compile Remove="**\*.cs" />
<None Include="src\**\*.cs" />
<Compile Include="src\Class1.cs" />
The None item was added to the HashSet first. The Compile item added
afterwards would be ignored.
Fixes VSTS #974214 - Multi-targeting: No target framework selector
shown in editor
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/974214
|
|
Merge browser and target framework together in execution targets. So
if a project targets .NET Core 2.1 and 2.2 you will see execution
targets such as the following in the main toolbar:
Safari • netcoreapp2.1
Safari • netcoreapp2.2
Fixes VSTS #964069 - [Multi-targeting] Browser - framework execution
target selection
|
|
Tests that a multi-target project that targets .NET 4.7.2 and .NET Core 1.1
has two execution targets - one for each framework.
|
|
Now file nesting only works on specific project types, so the previous ones,
which were using a console application, were failing as no file nesting was
being applied.
|
|
No longer using the Microsoft.IdentityModel.Clients.ActiveDirectory
NuGet package but a custom package built just for the unit test.
|
|
The Edit References dialog uses the Project.CanReferenceProject method
to determine if a project can be referenced. This does not consider
multi-target framework projects. Now a DotNetProjectExtension has
been added to the NuGet addin that uses NuGet to determine the
compatibility of all target frameworks the projects use.
Report all target frameworks as incompatible in the Edit References
dialog instead of just the first target framework.
Fixes VSTS #959111 - Unable to add references with multi-target
framework project
|
|
|
|
|
|
|
|
|
|
The type system service was only checking the file extension not
the build action.
Fixes VSTS #843603 - Files with build action 'None' are still used by
Intellisense
|
|
Previously multi-target framework projects would show the framework
nodes under Dependencies - NuGet and Dependencies - SDK. Now the
framework nows appear directly under the Dependencies folder. Note
that currently the Assemblies and Projects folders do not support
multi-target frameworks and just show all assemblies and projects
referenced directly in the project ignoring any conditions.
|
|
When a project file is edited the project is reloaded. The type
system service was reloading the project info for each framweork
and calling the Roslyn workspace's OnProjectReloaded. If the
target framework has changed then this would fail since a new
project id was generated. New project ids are now added, instead
of being reloaded, and unused old project ids are removed.
|
|
Refactored the code so that the DotNetProject's TargetFrameworkMonikers
is used by the type system and project model instead of getting the
short names as an enumerable list of strings. The original short name
is copied to the TargetFrameworkMoniker so the full name of the
framework is available as well as the original short name.
|
|
Using the NearestTargetFramework metadata returned from MSBuild
the correct Roslyn project id can be found for a project reference
when building the Roslyn workspace. Previously the target framework
was not used so a new Roslyn project id was being used.
|
|
Switching to a different target framework in the text editor would
not update the preprocessor symbols available. The problem was that
the framework specific values were not being used when creating the
Roslyn project. Now a framework specific project configuration
is obtained from the project so the correct compiler options and
parse options are used by Roslyn.
|
|
Each target framework results in a Roslyn Project being created
with the references and source files specific to that target
framework.
The project info cache generates a separate cache file for each
target framework.
Running MSBuild targets now support the configuration having a
target framework. This was to avoid having to add a new framework
parameter to several project system methods. The implementation
involves a custom configuration selector - a possible improvement
here would be to have these framework aware configurations
available from the Project itself - the current custom selector
implementation seems a little clumsy.
Project references on the Roslyn Project are not currently
multi-target framework aware.
Fixes VSTS #572311 - Multi-framework support in Roslyn workspace
|
|
[Core] Attempt at fixing method overload resolving for MSBuild
|
|
This fixes issues when the wrong overload for a method is chosen.
Should fix a lot of evaluation issues, and also fixed up parsing
of flag enums.
Fixes VSTS #783960 - MSBuild property evaluation failed
|
|
|
|
[Ide] Fix missing xaml file breaking intellisense
|
|
Initial work towards optimizing FileService handlers
|
|
If a project referenced a .xaml file that did not exist then the
type system would throw a file not exception and not load any
type information for the solution. This then broke code completion,
go to declaration, etc. To avoid this error a check is made to
ensure the file exists before trying to generate projections for the
.xaml file.
Fixes VSTS #918867 - Missing xaml file breaks intellisense
|
|
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
|
|
|
|
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
|
|
The restore menu when right clicking a solution or the packages folder
is no longer disabled when an SDK style project targets .NET Framework
or when the project has RestoreProjectStyle set to PackageReference but
has no PackageReferences.
Fixes VSTS #764063 - NuGet extension ignores RestoreProjectStyle
Fixes VSTS #814579 - Restore NuGet packages menu disabled for sdk style
project targeting net47
|
|
Added tests for existing logic before changing it to fix some bugs
where the restore menu is not enabled when it should be.
|
|
[Core] Fix error saving project with ToolsVersion set to Current
|
|
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"
|
|
When running MSBuild targets the TargetFramework property was explicitly
set so that multi-target framework projects work for targets such as
ResolveAssemblyReferences. However setting this property prevents
MSBuild from building all frameworks for a project using the
cross-target MSBuild targets. To fix this when the Build or Clean
MSBuild targets are run the TargetFramework is not set. This allows
all frameworks to be built by MSBuild.
Fixes VSTS #572330 - Support building multi-targeted projects
|
|
If an SDK style project has an SDK that defines a custom MSBuild item
type via AvailableItemName, and uses a wildcard import to include
files into the project, the Solution pad was not displaying these
files.
<AvailableItemName Include="Font" />
<Font Include="**\*.ttf" />
The SdkProjectExtension was filtering out all non-standard build
actions which resulted in them not being added to the Project's Files
and would not be displayed in the Solution pad. To fix this the
SdkProjectExtension checks all build actions defined by the project.
This will include custom AvailableItemName items and any custom
build actions defined by a project extension.
Fixes VSTS #895775 - DefaultItem.props not honored for newly defined
BuildActions
|
