| Age | Commit message (Collapse) | Author |
|---|
|
[NuGet] Fix restore menu incorrectly disabled.
|
|
[NuGet] Update to NuGet 5.1
|
|
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.
|
|
Remove more unnecessary or problematic uses of Runtime.RunInMainThread,
again due to Roslyn blocking the main thread, and then calling services
like this from async tasks it also blocks on.
Interesting note: the async call in GetInstalledVersions is actually
entirely synchronous, but we cannot change all the methods involved
because they are implementing interfaces from NuGet. So running it on
the threadpool is totally unnecessary, but protects us in case things
change in the future.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/900631
|
|
Update to NuGet 5.1.0.6013
Fixes VSTS #899305 - Bump to NuGet 5.1
|
|
[NuGet] Fix format exception in Add Packages dialog
|
|
After updating to NuGet 5 it was not possible to add, remove or update
package sources in Preferences if a package source had a username and
password associated with it. The problem was that the package source
url was being used when saving the username and password information
in the packageSourceCredentials section in the NuGet.Config file. This
resulted in an invalid xml element name so the save would fail. In
NuGet 4.8 the PackageSourceCredential.Source was not used when saving
the NuGet.Config file. With NuGet 4.9 and later it is being used.
However it is not the source url but the source name.
Fixes VSTS #857001 - Unable to update NuGet package sources
|
|
Adding a new non-sdk style project to md-addins would cause a NuGet
restore to run multiple times. The problem was that the Xamarin.Mac
SDK style projects change their target framework on re-evaluation from
.NET to Xamarin.Mac. This was causing the .NET Core project extension
to run a restore for all sdk style projects in the solution, multiple
times. To avoid this the target framework changes during re-evaluation
are ignored. We are only interested in changes due to the user making
changes to the target framework.
Also note that this NuGet restore loop does not happen with the
splitting out of the sdk style project support into its own project
extension. However fixing the underlying problem will prevent it
causing other problems in the future.
Fixes VSTS #893871 - Adding a non-sdk style project to a solution can
trigger a NuGet restore
|
|
When the target framework changed in a .NET Core project all .NET
Core projects in the soluton were restored. Now only the project and
any of its transitive project references are restored.
Fixes VSTS #895149 - Target Framework change in one project restores
all .NET Core projects
|
|
[DotNetCore] Improve SDK not supported message
|
|
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
|
|
|
|
Exceptions from the NSUrlSessionHandler contain curly braces in the
error messages, such as:
[nuget.org] The Internet connection appears to be offline.
Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={NSUnderlyingError=0x7fce42892a80 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, NSErrorFailingURLStringKey=https://api-v2v3search-1.nuget.org/query?q=&skip=0&take=26&prerelease=false&supportedFramework=Xamarin.iOS,Version=v1.0&semVerLevel=2.0.0, NSErrorFailingURLKey=https://api-v2v3search-1.nuget.org/query?q=&skip=0&take=26&prerelease=false&supportedFramework=Xamarin.iOS,Version=v1.0&semVerLevel=2.0.0, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, NSLocalizedDescription=The Internet connection appears to be offline.}
This text was then being passed to string.Format in the Add Packages
dialog and would cause a FormatException. The error would then not be
displayed in the Add Packages dialog. The text now has the curly braces
escaped to prevent the FormatException.
Fixes VSTS #889359 - NuGet Add Packages - FormatException when offline
|
|
A NuGet package being installed into a multi-target framework project
may not support all frameworks. When this happens the PackageReference
will now be added with a condition so the NuGet package is not used
for frameworks that are not supported.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net472;netstandard1.2</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition="'$(TargetFramework)' == 'net472'">
<PackageReference Include="EntityFramework" Version="6.2.0" />
</ItemGroup>
</Project>
Note that NuGet does not support updating a NuGet package with a
condition. Visual Studio on Windows also shows an error about the NuGet
package being incompatible on updating it if it only supports certain
frameworks.
Fixes VSTS #572317 - Make adding PackageReferences to multi-framework
projects robust
|
|
|
|
|
|
DotNetCliToolReferences are available in the dependency graph but are
treated as separate projects in this graph. Since these did not map
to an existing project they were not added to the full dependency
graph which resulted in these tools not being restored. Note that
these are only restored when the entire solution is restored.
Restoring a single project only restores the project itself not
the dotnet cli tool project in the dependency graph. MSBuild
supports restoring DotNetCliToolReferences in any project type that
uses PackageReferences so we also support this.
Fixes VSTS #567594 - DotNetCliToolReference is not restored
|
|
[NuGet] Update to NuGet 5.0.2
|
|
xamarin/nuget-package-reference-development-dependency
[NuGet] Add PackageReference metadata for development dependencies
|
|
Fixes problem with package sources indicating that packages are signed
and Mono not supporting checking the package is signed resulting in
a failure to install or restore NuGet packages in projects that use
PackageReferences where the package is not in the local cache.
Fixes errors similar to:
Package 'Microsoft.AspNetCore.Authentication.Abstractions 2.1.0' from
source 'https://api.nuget.org/v3/index.json': This repository indicated
that all its packages are repository signed; however, this package is
unsigned.
Fixes VSTS #855951 - Package restores and builds failing with
"This repository indicated that all its packages are repository signed;
however, this package is unsigned."
|
|
|
|
|
|
New logging API methods were not implemented.
|
|
Implement the package extraction context which was causing some tests
to fail.
|
|
Fixed assembly conflict errors on building for System.Net.Http and
System.IO.Compression. NuGet 5 is using these assemblies from .NET
Framework 4.7.2 so we need to exclude the assets from the equivalent
NuGet packages since the NuGet package versions are too old.
Fixed the test build errors. Some tests are still failing since the
package extraction context has not been implemented.
|
|
|
|
|
|
Installing a NuGet package that is a development dependency, such as
GitInfo, would not add the PrivateAssets nor the IncludeAssets
metadata to the PackageReference. Now this is supported and mirrors the
behaviour of 'dotnet add package' and Visual Studio on Windows.
Fixes VSTS #634988 - PackageReference metadata not added for development
dependencies
|
|
|
|
When a NuGet restore is being run a task is set for the restore in
progress. The type system service now checks this task to see if it
can make any calls into the project model that use MSBuild. This limits
the overlap between the type system getting MSBuild information and
the NuGet packages being restored. Note that this is not perfect -
since the type system load can start before the NuGet restore has
started - so a check is made after each msbuild call to see if the
NuGet restore is started which will then pause the project load.
Fixes VSTS #844560 - Avoid loading TypeSystem when restoring NuGet
packages
|
|
|
|
|
|
Those methods are invoked when content is shown or hidden in the shell.
Added corresponding infrastructure to DocumentView and derived classes.
|
|
|
|
|
|
Update to NuGet 4.8.2-rtm.5835
|
|
merge-integration-9
|
|
The NuGet addin API has a PackageReferenceAdded event and a
PackageReferenceRemoved. These were being raised if a project had
a packages.config file but not if the project used PackageReferences.
Fixes VSTS #807927 - Get the events working for an Android project
that uses PackageReferences
|
|
The NuGet addin API has a PackageReferenceAdded event and a
PackageReferenceRemoved. These were being raised if a project had
a packages.config file but not if the project used PackageReferences.
Fixes VSTS #807927 - Get the events working for an Android project
that uses PackageReferences
|
|
|
|
Installing a NuGet package into a project that used PackageReferences
would not re-evaluate the project. This resulted in any custom
AvailableItemNames not being available to be used as a build action
in the Solution pad. Also needed to clear the cached build actions
on re-reading the project to ensure the latest items are available
after an re-evaluation.
Fixes VSTS #672198 - Users are unable to set the Build Action
"GoogleServicesJson" when adding a package that references Google
Play Services Basement and deploying an application
|
|
Installing a NuGet package into a project that used PackageReferences
would not re-evaluate the project. This resulted in any custom
AvailableItemNames not being available to be used as a build action
in the Solution pad. Also needed to clear the cached build actions
on re-reading the project to ensure the latest items are available
after an re-evaluation.
Fixes VSTS #672198 - Users are unable to set the Build Action
"GoogleServicesJson" when adding a package that references Google
Play Services Basement and deploying an application
|
|
|
|
|
|
public-8.0-merge
|
|
Check the exception is not an OperationCanceledException when logging
failures on NuGet restore and check for updates.
Fixes VSTS #797961 - Task canceled error logged when checking for
updates
|
|
|
|
Handle a project being disposed when checking to see if it supports
NuGet. A disposed project will have a null MSBuildProject property.
Fixes VSTS #797960 - Null reference in DotNetCoreNuGetProject
|
|
|
