PowerShell/nuget.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="CI Builds (dotnet-core)" value="https://www.myget.org/F/dotnet-core/api/v3/index.json" />
    <add key="CI Builds (dotnet-cli)" value="https://dotnet.myget.org/F/dotnet-cli/api/v3/index.json" />
    <add key="CI Builds (aspnetvnext)" value="https://www.myget.org/F/aspnetvnext/api/v3/index.json" />
    <add key="CI Builds (aspnetcidev)" value="http://myget.org/F/aspnetcidev/api/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="local" value="./src/windows-build/nuget-feed" />
  </packageSources>
</configuration>
Build PowerShell using DNX 2015-11-13 05:42:35 +01:00			`<?xml version="1.0" encoding="utf-8"?>`
			`<configuration>`
			`<packageSources>`
Modernize our nuget.config Use the V3 api, and use the clear directive instead of `activePackageSources`. 2016-02-06 01:03:00 +01:00			`<clear />`
Fix xUnit tests for Linux The latest xUnit packages fix the "could not resolve coreclr path" problem we were having. To resolve all dependencies, the cli-deps feed was replaced with the aspnet feeds. However, the latest xUnit packages do not allow us to set the default AssemblyLoadContext. 2016-04-14 22:31:46 +02:00			`<add key="CI Builds (dotnet-core)" value="https://www.myget.org/F/dotnet-core/api/v3/index.json" />`
			`<add key="CI Builds (dotnet-cli)" value="https://dotnet.myget.org/F/dotnet-cli/api/v3/index.json" />`
			`<add key="CI Builds (aspnetvnext)" value="https://www.myget.org/F/aspnetvnext/api/v3/index.json" />`
			`<add key="CI Builds (aspnetcidev)" value="http://myget.org/F/aspnetcidev/api/v3/index.json" />`
Modernize our nuget.config Use the V3 api, and use the clear directive instead of `activePackageSources`. 2016-02-06 01:03:00 +01:00			`<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />`
Add missed files to Microsoft.PowerShell.Commands.Management Add almost all files to Microsoft.PowerShell.Commands.Management One of them is Computer.cs that was listed in known issues. We start to use a nuget packages generated for assemlbies that cannot be listed in framework assemlbies, but exist in a GAC on all windows machine and not a PowerShell assemblies The first one is Microsoft.WSMan.Management 2016-02-12 05:44:21 +01:00			`<add key="local" value="./src/windows-build/nuget-feed" />`
Build PowerShell using DNX 2015-11-13 05:42:35 +01:00			`</packageSources>`
			`</configuration>`