Better handling of bad request errors in package actions.

The package actions throw uncessary amount of exceptions when getting a bad request from the repository.

Most likely this is because the bad request errors are return by the repo when the request has invalid package versions, and we have a lot of those when debugging.

We should not include packages with invalid version in the request to the repository, instead we should warn that these packages have invalid versions.

tap package download REST-API
Error communicating with repository at 'http://packages.opentap.io' : The remote server returned an error: (400) Bad Request..
Exception: Error communicating with repository at 'http://packages.opentap.io'.
  Inner exception: The remote server returned an error: (400) Bad Request.
Exception caught at:
Exception: One or more errors occurred.
  Inner exception: Error communicating with repository at 'http://packages.opentap.io'.
  Inner exception: The remote server returned an error: (400) Bad Request.
Exception caught at:
Error communicating with repository at 'http://packages.opentap.io' : The remote server returned an error: (400) Bad Request..
Exception: Error communicating with repository at 'http://packages.opentap.io'.
  Inner exception: The remote server returned an error: (400) Bad Request.
Exception caught at:
Exception: One or more errors occurred.
  Inner exception: Error communicating with repository at 'http://packages.opentap.io'.
  Inner exception: The remote server returned an error: (400) Bad Request.
Exception caught at:
2 required dependencies are currently not installed (use --dependencies to also get these).
Package 'REST-API' already exists in 'c:\git\opentap\bin\Debug'.

added Package Manager Usability labels

changed the description

If you are running out of the build directory, as may be guessed from:

Package 'REST-API' already exists in 'c:\git\opentap\bin\Debug'.

it's probably an instance of the problem described at the bottom of #386 (comment 432006776), starting from paragraph:

In commit 1326c0d1 ...

To confirm, try to remove Package.UnitTests/Packages/GitVersionDependency/package.xml, and see whether the issue disappears. The related MR !654 (merged), should solve the problem.

In the long run it would be better to remove all the XML package definition files needed by Package.UnitTests/PackageDefTests.cs

$ grep Packages/ Package.UnitTests/PackageDefTests.cs 
            string inputFilename = "Packages/test2/package.xml";
            string inputFilename = "Packages/Package/package.xml";
            string inputFilename = "Packages/GitVersionDependency/package.xml";
            string inputFilename = "Packages/Package/package.xml";
            File.Copy("Packages/Package_NoBinFiles/package.xml", "package_NoBinFiles.xml", true);
                    Directory.CreateDirectory("Packages/pkg1");
                    using (var f = File.OpenWrite("Packages/pkg1/package.xml")) def.SaveTo(f);
                    Directory.CreateDirectory("Packages/gui");
                    using (var f = File.OpenWrite("Packages/gui/package.xml")) def.SaveTo(f);
                    Directory.CreateDirectory("Packages/rv");
                    using (var f = File.OpenWrite("Packages/rv/package.xml")) def.SaveTo(f);
            string inputFilename = "Packages/Package/package.xml";  // this package contains the old XML Schema URL
            PackageDef pkg = PackageDefExt.FromInputXml("Packages/Package/package.xml", Directory.GetCurrentDirectory());
            PackageDef pkg1 = PackageDefExt.FromInputXml("Packages/test2/package.xml", Directory.GetCurrentDirectory());
            string inputFilename = "Packages/CheckDependencies_MissingDep/package.xml";
            var p = Process.Start("tap", "package create \"Packages/Package/package.xml\" -v");
            File.Copy("Packages/SetAsmInfoTest.dll", "SetAsmInfoTest.dll", true);

out of the Packages folder in the build directory from Package.UnitTests/Tap.Package.UnitTests.csproj.

mentioned in issue #304

This issue seems to be a duplicate of #304.

Closing this issue and continuing the discussion in #304

closed