| Age | Commit message (Collapse) | Author |
|---|
|
|
|
.. 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.
|
|
1. Simplify the new unit test a little bit.
2. Include all items in the located projectFileDependencyGroup whether or not they have a version number. It's not entirely clear why we were dropping items without a version number; the most likely explanation is that we expected all valid items to have a version number and wanted to exclude the "invalid" ones. Whatever the reason, we should include all of them.
|
|
In order to show the set of referenced packages in the Solution Explorer the build task digs through the items in the "projectFileDependencyGroups" section of the project.lock.json/project.assets.json file. Currently, we assume all of the packages we care about will be in the subsection denoted by the empty string, "". It turns out that this is not true. This subsection may not exist at all, and when it does it only holds the set of packages common to all targets. Target-specific packages will be in target-specific subsections.
To fix this, we now try to look up the preferred target moniker and look up a subsection with that name. Then we add in the common packages.
|
|
Update Microsoft.NuGet.targets to support project.assets.json files in
addition to project.lock.json. If a project lock file has not been
explicitly specified and there are no MyProj.project.json or
project.json files next to the project, we'll look for
$(BaseIntermediateOutputPath)project.assets.json instead.
|
|
|
|
|
|
|
|
This will allow a Native library that references a managed component to copy the .Net framework
|
|
|
|
|
|
|
|
The task previously was constructing the path to the user's packages
location itself, which had various issues. It meant that if the restore
was done with a different path, we don't know that. It also meant we
didn't handle the paths specified in nuget.config. Now, if the paths
are present in the lock file, we'll use that. Otherwise, we'll construct
our old path as before. Any explicitly given path to the task is
still used no matter what.
|
|
|
|
|
|
This now requires Visual Studio 2015 Update 2 to build.
|
|
If they're present copy them like their .pdb counterparts.
|
|
This allows using the code on Unix filesystems that use forward slash.
|
|
If we pass a full path to ResolveAssemblyReferences.Assemblies, it will
remove the file and not pass it along to the compiler. This is bad
for project-to-project references, since the Visual Studio IDE still
needs to know about them to make sure everything is wired up correctly.
With this, we now pass project-to-project references to AssemblyFiles,
matching the behavior of the ResolveProjectReferences target.
There is a deeper question of whether or not we should pass all our
full paths along to AssemblyFiles, but that's something which requires
fairly extensive testing and might have back-compat problems that need
to be dealt with.
|
|
|
|
Fixes NuGet/Home#2009.
|
|
We were previously returning true when asked if any file under the
packages directory existed, even if it wouldn't actually exist if
the package was really restored. Now we won't lie.
|
|
|
|
If you have a target that mentions another target in BeforeTargets,
but your target won't run, MSBuild still gives a warning. The workaround
is to condition the computation of BeforeTargets as well. There's a
bigger question here about where to move the .NET Core injection to,
since it's ugly that it lives here; I ignore that question for now.
Fixes NuGet/Home#1814.
|
|
This isn't a scenario we expect to happen, but if it were to we should
probably not crash.
|
|
XProj projects being referenced from CSProj projects can be represented
by NuGet as just another reference to a package, but with a different
source location than the usual package cache. This adds the knowledge
to detect these "packages" and compute the correct path.
|
|
|
|
We need this so we can figure out where those projects are and
some metadata about them, notably where their outputs are going to.
|
|
|
|
NuGetIsFrameworkReference assigned and that all references are correctly tagged
|
|
NugetIsReferenceAssembly flag
|
|
|
|
|
|
Previously we would let the build task catch exceptions, and would let
the ResolvePackagesWithJsonFileContents re-throw a test exception if the
build task returned false. This caused us to round-trip the rich
exception information to a string, which is irritating. It's easier to
not do that.
|
|
This simplifies some unit tests I want to write.
|
|
The project.lock.json provides, for resource items, the culture which
was pulled out of the path in the NuGet package. We can use this to
construct target paths rather than re-figuring it out ourselves.
|
|
|
|
|
