| Age | Commit message (Collapse) | Author |
|---|
|
Merge upstream dev branch
|
|
|
|
|
|
Removing dependency on NuGet.ProjectModel
|
|
|
|
Fixes: https://github.com/NuGet/Home/issues/6959
This PR improves the error experience for non project.json based projects. Primarily improves the error message for missing RID from -
`
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5):
error :
Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your
project.json and then re-run NuGet restore.
`
to -
`
C:\Program Files (x86)\Microsoft Visual Studio\2017Stable\Enterprise\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): error :
Your project csproj file doesn't list 'win' as a targeted runtime. You should add 'win' to the "RuntimeIdentifiers" property in your project csproj file and the n re-run NuGet restore. [E:\NuGet.BuildTasks\src\Microsoft.NuGet.Build.Tasks.Tests\Microsoft.NuGet.Build.Tasks.Tests.csproj]
`
Plus adding tests for non project.json based scenarios.
|
|
|
|
|
|
|
|
|
|
|
|
Bring repo up-to-date
|
|
Bring the repo up-to-date with changes to Microsoft.Nuget.targets
that were unforunately made in the main VS repo rather than here.
|
|
Merge upstream/dev
|
|
|
|
* Stop relying on ImportAfter extension point to be included in
MSBuild.
* MSBuild to explicitly load NuGet.targets in the common targets.
|
|
Provide DT support target to return ResolvedNugetPackages task items …
|
|
|
|
OOP node
|
|
Update Framework Injection check to support JavaScript UWP apps
|
|
Ignore case when comparing package names
|
|
This update adds a check of the target, because sometimes the properties used to determine the full source path are not set (e.g. in JavaScript UWP apps)
|
|
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/500532.
We may need to vary which packages (or versions of packages) to pull in depending on the target framework. In the assets/lock file this is supported by the projectFileDependencyGroups section. This contains an entry for each supported framework, and the entry lists the packages used when targeting that framework. In addition, there is a "universal" entry (denoted by an empty name) for packages that are used in all frameworks.
To determine which packages to list in Solution Explorer we match items in the relevant projectFileDependencyGroups item against the packages listed in the "libraries" section. However, we are currently doing this comparison in a case-sensitive manner, even though NuGet packages names are case-insensitive. This means that if the package name differs in case between the two, we won't find it and it won't show up in Solution Explorer. This is "just" a display issue, as the build and Intellisense are unaffected. Still, it is disconcerting for the user, as packages may suddenly "disappear" during package management operations.
|
|
A few of the .json asset files used in the unit tests were updated to refer to a newer version of Newtonsoft.Json, but there were a couple of problems with this.
1. The asset files specified to look for the binaries under the "Newtonsoft.Json\current" folder, rather than under the "Newtonsoft.Json\9.0.1" folder. This may be valid for real-world scenarios, but breaks our unit testing setup (which doesn't actually restore packages and basically fakes a file system). This is incidental to what the tests are trying to exercise, so this commit just replaces "current" with 9.0.1.
2. One of the tests verifies the path to a referenced assembly, but the expected path still had the old version number in it. This has now been fixed.
|
|
This allows us to build the project on systems that only have Dev15 installed.
|
|
Read DotNetNativeVersion and consume updated frameworks if it's set
|
|
|
|
Update to upstream `dev`
|
|
Update to track upstream and match VS 15.4
https://github.com/NuGet/NuGet.BuildTasks/pull/37#issuecomment-327855545
|
|
Port VS changes to dev branch
|
|
|
|
Port changes in dev15.1 back to dev
|
|
assets file following #35
|
|
|
|
|
|
.. filesystems.
NuGet now restores packages in lower case directory names, but the
build task `ResolveNuGetPackageAssets` constructs the path from package
name and version, like:
`Microsoft.NETCore.Portable.Compatibility/1.0.1`
.. instead of
`microsoft.netcore.portable.compatibility/1.0.1`
This breaks builds on msbuild/mono on case-sensitive filesystems, eg. on
Linux.
The actual on-disk path is available in the lock/assets.json file as:
```
"libraries": {
"Newtonsoft.Json/10.0.2": {
...
"path": "newtonsoft.json/10.0.2",
...
```
So, we use that to look for the package. But fallback to the old method if this
`"path"` is not available.
|
|
Merge branch dev into dev15.1
|
|
.. still use that, eg, for some PR builders.
|
|
src/Microsoft.NuGet.Build.Tasks/ImportBeforeAfter/Microsoft.NuGet.Solution.ImportAfter.targets
- this is not installed, so not updating the path. This was not
installed for xbuild earlier, so staying in sync
- This file gets installed by msbuild/mono for 15.0
|
|
Add a missing scenario for Framework injection
|
|
Don't show project references as package references in Solution Explorer
|
|
When a NuGet restore generates a project.assets.json file it includes information not only on which NuGet packages are used by a project, but which other projects are referenced as well. When reading the list of dependencies from project.assets.json we currently make no distinction between a _package_ dependency versus a _project_ dependency. The result is that projects get included with the list of packages we show in the Solution Explorer under the References node--and since the language service already shows project references there, we end up with two nodes representing the same thing.
The fix here is to filter out the project dependency in the build task. For every dependency, we check it against the items in the "library" section of the project.assets.json file. This specifies whether a particular "library" comes from a project or a package. If it does not explicitly state that it is a project, we assume it is a package.
A unit test has been added to cover this scenario.
|
|
|
|
Whenever a UWP app contains managed code we need to be sure to inject the .NET Core Framework assemblies. This is obviously the case when the app itself is written in C# or VB. However, we also need to handle the case where the app is written in C++ but references a WinRT component written in managed code.
We detect the latter case by looking for the use of the union Windows.winmd assembly. We assume the assembly is in a path that ends with "UnionMetadata\Windows.winmd", but this isn't always the case. Sometimes the path will include the Windows SDK version number, like "UnionMetadata\10.0.15000.0\Windows.winmd"; in this case we won't realize that the framework is needed, and .NET Native compilation will fail.
The fix here is to check for these other locations by making use of the WindowsSDK_UnionMetadataPath property.
|
|
|
|
|
|
props/targets
https://github.com/dotnet/sdk/pull/870
https://github.com/dotnet/roslyn-project-system/issues/1474
https://github.com/dotnet/roslyn-project-system/issues/1508
|
|
|
|
|
|
scenarios.
|
