/cc: @weshaggard , @ericstj Please take a look

@eerhardt This should hopefully unblock you tomorrow.

You are using a mix of package dependencies and project references. Why not just use one or the other?

I tried moving completely to ProjectReference but that hit issues with netcoreaot builds for S.R.TE (I will need to depend on S.P.R which won't sit well with S.P.R.E references in the netcoreaot). And when I used the packageUpdate only, S.R.E tests broke for even though they depended on .NetCore.Platforms 903 package, the System.Reflection.dll getting added to the test bin drop did not have the right TypeForwarders (forcing me to use ProjectReference there).

so the idea is to do this for one build then fix it tomorrow?

@dagood is there a way to create one-off exceptions to validation?

so the idea is to do this for one build then fix it tomorrow?

I am not sure why S.R.TE tests still need ProjectReference when I updated to the most recent package but I am trying to dig in further. Unless that uncovers another issue, I do intend to fix this in a proper way after tomorrow's build. Taking P2P references unless necessary makes things brittle.

@ericstj I know of two ways:

• Change the regex to exclude the package (doesn't seem like what is needed here based on a quick glance over but I can't quite tell). The (?<!TestData) syntax should work for that.
• Exclude some project.jsons from ProjectJsonFiles in dir.props

I didn't put a way to exclude into the task, so nothing more specific than that as far as I know.

The Ubuntu tests failed.

Disk has run out of space and cannot get latest changes..

@dotnet-bot test Innerloop Ubuntu Debug Build and Test please

Please let me know if there are any further comments, I would like to check this in before the build snaps for the day.

I'm ok with this so long as we undo it immediately following the successful build and package upgrade. We'll need to do a similar dance in the Rel branch.

We'll need to do a similar dance in the Rel branch.

To the CLI and other consumers, doing this in the Rel branch is the more important task. We can only reference rc2 packages, and right now the rc2 builds are broke. You can't build anything that references System.Reflection.

You can't build anything that references System.Reflection.

Can you help me understand this a little bit more? System.Reflection update happened only 2 days back so those changes should not be in the rc2 packages right?

System.Reflection update happened only 2 days back so those changes should not be in the rc2 packages right?

@weshaggard and @ellismg can correct me if I'm wrong, but I think master integrates to release/1.0.0-rc2 pretty regularly.

If I try to dotnet build the following app:

{
    "version": "1.0.0-*",
    "compilationOptions": {
        "emitEntryPoint": true
    },

    "dependencies": {
        "NETStandard.Library": "1.0.0-rc2-23903"
    },

    "frameworks": {
        "netstandardapp1.5": {
            "imports": [ "dnxcore50" ]
        }
    }
}

using System;
using System.Reflection;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(BindingFlags.Instance);
        }
    }
}

I get:

C:\DotNetTest\Program.cs(10,31): error CS0433: The type 'BindingFlags' exists in both 'System.Reflection.TypeExtensions, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Reflection, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Notice I'm using "NETStandard.Library": "1.0.0-rc2-23903"

Notice I'm using "NETStandard.Library": "1.0.0-rc2-23903"

903 is the most recent build. I am not sure how this is done. I will sync up with wes and eric offline and make sure we have story for rel branch as well. Thanks for pointing out.

System.Reflection update happened only 2 days back so those changes should not be in the rc2 packages right?

@weshaggard and @ellismg can correct me if I'm wrong, but I think master integrates to release/1.0.0-rc2 pretty regularly.

Baring unusual circumstances (e.g. the internal build being on the floor), ProjectK (RC3) FI's to ProjectKRel (Nightly). The 1.0.0-rc2-23903 payload is basically 1.0.0-rc3-23902 (the previous day's payload).

Note that we have a new build out today 1.0.0-rc2-23904, this would match what was in the 23903 builds of RC3. You can always look at the release branch on GitHub for either CoreFX or CoreCLR to see what the branch currently looks like.

BTW, if there's a commit you need fast traced into RC2, please let me know the hash or TFS changeset and I can ensure it's in the next build.

BTW, if there's a commit you need fast traced into RC2, please let me know the hash or TFS changeset and I can ensure it's in the next build.

Sweet. Thanks @ellismg. I will let you know in a couple of hours once I make sure all the bases are covered.

Thanks for the review. Once, we have an official build I will cleanup these changes and move the complete corefx to the new packages in this and rc2 branch.