Runtime: "Length cannot be less than zero. " thrown on nectoreapp2.0 when trying to invoke Action<dynamic> that accesses a property on the input class - works for anonymous types

Created on 29 Jun 2017  路  18Comments  路  Source: dotnet/runtime

_From @maumar on June 28, 2017 19:7_

repro:

        public class MyEntity
        {
            public int Id { get; set; }
            public string Name { get; set; }
        }

        [Fact]
        public virtual void Netcoreapp_bug()
        {
            Action<dynamic> workingElementAsserter = e => Console.WriteLine("works");
            Action<dynamic> failingElementAsserter = e => Console.WriteLine(e.Id);
            var dto = new MyEntity { Id = 1, Name = "Foo" };
            var anonymous = new { Id = 1, Name = "Foo" };

            workingElementAsserter(dto); //works
            failingElementAsserter(anonymous); //works

            failingElementAsserter.Invoke(dto); //fails
        }

exception:

 System.ArgumentOutOfRangeException : Length cannot be less than zero.
Parameter name: length
Stack Trace:
   at System.String.Substring(Int32 startIndex, Int32 length)
   at Microsoft.CSharp.RuntimeBinder.Syntax.NameTable.Add(String key, Int32 length)
   at Microsoft.CSharp.RuntimeBinder.Syntax.NameManager.Add(String key, Int32 length)
   at Microsoft.CSharp.RuntimeBinder.SymbolTable.GetName(Type type)
   at Microsoft.CSharp.RuntimeBinder.SymbolTable.LoadSymbolsFromType(Type originalType)
   at Microsoft.CSharp.RuntimeBinder.RuntimeBinder.GetArgumentType(ICSharpBinder p, CSharpArgumentInfo argInfo, Expression param, DynamicMetaObject arg, Int32 index)
   at Microsoft.CSharp.RuntimeBinder.RuntimeBinder.CreateArgumentArray(ICSharpBinder payload, Expression[] parameters, DynamicMetaObject[] args)
   at Microsoft.CSharp.RuntimeBinder.RuntimeBinder.BindCore(ICSharpBinder payload, Expression[] parameters, DynamicMetaObject[] args, DynamicMetaObject& deferredBinding)
   at Microsoft.CSharp.RuntimeBinder.RuntimeBinder.Bind(DynamicMetaObjectBinder payload, Expression[] parameters, DynamicMetaObject[] args, DynamicMetaObject& deferredBinding)
   at Microsoft.CSharp.RuntimeBinder.BinderHelper.Bind(DynamicMetaObjectBinder action, RuntimeBinder binder, DynamicMetaObject[] args, IEnumerable`1 arginfos, DynamicMetaObject onBindingError)
   at Microsoft.CSharp.RuntimeBinder.CSharpGetMemberBinder.FallbackGetMember(DynamicMetaObject target, DynamicMetaObject errorSuggestion)
   at System.Dynamic.DynamicMetaObject.BindGetMember(GetMemberBinder binder)
   at System.Dynamic.GetMemberBinder.Bind(DynamicMetaObject target, DynamicMetaObject[] args)
   at System.Dynamic.DynamicMetaObjectBinder.Bind(Object[] args, ReadOnlyCollection`1 parameters, LabelTarget returnLabel)
   at System.Runtime.CompilerServices.CallSiteBinder.BindCore[T](CallSite`1 site, Object[] args)
   at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
   at Microsoft.EntityFrameworkCore.Query.ComplexNavigationsQueryTestBase`2.<>c.<Netcoreapp_bug>b__247_1(Object e)
   at Microsoft.EntityFrameworkCore.Query.ComplexNavigationsQueryTestBase`2.Netcoreapp_bug()

I am unable to reproduce this in standalone app, this only happens in our test infrastructure (Entity Framework Core). Using xunit and we have generic and polymorphic test classes and tests are in multiple assemblies - maybe this has something to do with it, but so far we were unable to figure out the root cause. Let me know if you need any more info.

dotnet --version: 2.0.0-preview3-006607

_Copied from original issue: dotnet/coreclr#12529_

area-Microsoft.CSharp bug

Most helpful comment

This is closed but doesn't seem to actually be fixed in SDK 2.0.2. The PR makes it seem like it is actually in 2.0.3 which is as yet unreleased. Is this correct? Is there a release date for SDK 2.0.3?

Thanks!

All 18 comments

_From @maumar on June 28, 2017 19:22_

In order to actually reproduce the issue:

clone https://github.com/aspnet/EntityFramework/tree/netcoreapp_bug
run dotnet restore on the solution
navigate to \test\EFCore.InMemory.FunctionalTests
run dotnet test --framework netcoreapp2.0 --filter FullyQualifiedName~Netcoreapp_bug

at Microsoft.EntityFrameworkCore.Query.ComplexNavigationsQueryTestBase`2.Netcoreapp_bug()`

There's the rub. Because the entity class is nested in a generic class, it's a generic type, but because it doesn't have type parameters itself there's no tick in its name, but I'm afraid that changes I made to SymbolTable.GetName assume otherwise.

I'm running into this issue at the moment. What's the correct way to swap out the Microsoft.CSharp assembly? I've got

  • Dotnet core sdk: 2.1.0-preview1-007055
  • Target framework: netcoreapp2.0
  • <PackageReference Include="Microsoft.AspNetCore.All" Version="2.1.0-preview1-26666" />
  • <PackageReference Include="Microsoft.CSharp" Version="4.4.0" />

It keeps using the Microsoft.NETCore.App 2.0.0 reference library.

Looking at the merge the fix for this is in Microsoft.CSharp. So is there a patched version of it available somewhere, alternative nuget feed?

I'm trying to use this one here: https://dotnet.myget.org/feed/aspnetcore-dev/package/nuget/Microsoft.CSharp/4.4.0

Just don't know how to get this to be picked up by the module loading instead of the 2.0.0 reference library. It shows up in the NuGet project tree but at runtime the loaded modules view in visual studio shows the 2.0.0 assembly instead.

@weshaggard how should they force it to pick up the 2.1 assembly?

If all you are after is an updated Microsoft.CSharp library (not sure if that is all that is needed as I'm sure about this full issue), you can get it from our dotnet-core feed https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.CSharp/4.5.0-preview2-25621-02.

Thanks @weshaggard, while indeed that version of the nuget package, does contain the fix for other platforms (decompiled it to verify), it's a no-op for netcoreapp 2.0 :expressionless:

For .NET Core 2.0 it is included in the shared framework package as opposed to the individual library package. You will need to follow the dogfooding instructions https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md to consume a prerelease version of the shared framework with the fix. RuntimeFrameworkVersion is the key property that will need to be updated.

Thanks @weshaggard that looks like the missing piece of the puzzle. Thanks for that.

Reopening to track 2.0.x port.

Fixed for ~2.0.2~ 2.0.3 servicing in PR dotnet/corefx#23512

This is closed but doesn't seem to actually be fixed in SDK 2.0.2. The PR makes it seem like it is actually in 2.0.3 which is as yet unreleased. Is this correct? Is there a release date for SDK 2.0.3?

Thanks!

Yeah, I think it slipped into 2.0.3. @leecow do we have public ETAs on servicing releases? Namely 2.0.3?

On track to have it out in the next week or so.

2.0.3 shipped and fixes the issue for me!

Great work by the team 馃帀

CC: @jaredpar

Was this page helpful?
0 / 5 - 0 ratings