[Mono-list] EF crashing in AssemblyName.ReferenceMatchesDefinition with is not implemented exception

[Dave Curylo]

I agree that having this fixed privately will not help anyone and
eventually harm yourself in terms of maintenance challenges.

The right thing to do in this case is that if you have a potential solution
to the missing mono framework code, submit a pull request with it and if
you have some concerns about pitfalls in your implementation, start a
discussion in github with that pull request.  Mono developers will
likely review it, participate in the discussion, and before you know it the
code will make its way to master.

On Tuesday, August 27, 2013, Mark Lintner wrote:

>  Hi Abe,
>
>
>
> That is probably not going to help anyone. This issue will be hit over and
> over again in the distribution and really  needs to be addressed.  What
> happens when you change code like this and keep a private build is that you
> are either stuck at that version forever or you have to merge in your
> private changes every time you update.  The size of that effort will grow
> in time if you go down that route. Eventually it becomes impossible to
> update and you lose the value of fixes that are added to the trunk. So I
> was looking for people who were impacted by this, had a good grasp of the
> issues such as determining if the assemblies are the same. If someone had
> already fixed it, I would not have to otherwise I have to fix it and submit
> it to the list for approval or suggestions.  I appreciate your suggestion.
> It is easy to get it up and running, on the surface but is unmanageable
> over any period of time. This is  a bug and we need to fix it.
>
>
>
> Thanks,
>  ------------------------------
> *From:* Abe Gillespie [abe.gillespie at gmail.com <javascript:_e({}, 'cvml',
> 'abe.gillespie at gmail.com');>]
> *Sent:* Tuesday, August 27, 2013 7:25 AM
> *To:* Mark Lintner
> *Cc:* mono-list at lists.ximian.com <javascript:_e({}, 'cvml',
> 'mono-list at lists.ximian.com');>
> *Subject:* Re: [Mono-list] EF crashing in
> AssemblyName.ReferenceMatchesDefinition with is not implemented exception
>
>  I know this isn't a particularly great option, but if this is a big
> roadblock for you, you can always change the EF source and work-around the
> issue with your own private version of EF. It should be pretty easy to
> locate the offending code.
>
>  http://entityframework.codeplex.com/
>
> On Monday, August 26, 2013, mlgo wrote:
>
> Has anyone figured this out yet?. Either this is going to have to be
> implemented or the Entity Framwork needs to avoid calling it. There is a
> stacktrace at the bottom of this message.
>
> System.Reflection.AssemblyName.ReferenceMatchesDefinition is not
> implemented. I guess developers have been working around this by comparing
> the assembly fullnames. Since it is called directly by EntityFramework it
> has to be implemented now. Unless EF should be changed to avoid this call.
> This is something I have not researched either. If anyone would think that
> EntityFramework should be changed to avoid making this call please add some
> feedback.
>
> Has anyone done this implementation or are they working on it currently?. I
> don't see any posts or bugs relating to it but I did find one reference to
> the problem in the context of another product using mono.
> Does the mono team plan to or want to implement it?
>
>
> I have done some research on this method in dotnet. The implementation for
> windows as documented by MSDN in this simple way "The comparison depends
> only on the simple assembly name. It ignores version, culture, and public
> key token. ".
>
> At a more fundamentally level the purpose of this method is to determine if
> the 2 names resolve to the same assembly. I believe that the documentation
> in dotnet used to read that way and referred to the loader. I suspect that
> dotnet is still doing that as part of the implementation of this function.
> If that approach were taken I'm not yet sure if it requires making windows
> OS calls to do it or if it could be done with managed code. The point is if
> it does need to be done and it needs to call os api's then the
> implementation would need to be different for Linux. If it is called often.
> If it involves loading an assembly using both of the names and then
> determining whether it is the same assembly that seems slow and
> inefficient.
> I have not done any performance profiling on this call to find out often it
> gets called.
> I think I would want to cache the assemblies. Also memoize the assembly
> names and their results. This would speed things up considerably.
>
>
>
> I'm concerned this will need to be implemented differently on Linux?? Hence
> it will have multiple implementations.
>
> Now that EF6 is in and people are using this becomes an immediate problem
> as
> it binds directly to the unimplemented function
> AssemblyName.ReferenceMatchesDefinition. Here is the stack:
>
>
>
> System.NotImplementedException: The requested feature is not implemented.
>
>   at System.Reflection.AssemblyName.ReferenceMatchesDefinition
> (System.Reflection.AssemblyName reference, System.Reflection.AssemblyName
> definition) [0x0003a] in
>
> C:\cygwin\sources\mono\mcs\class\corlib\System.Reflection\AssemblyName.cs:328
>
>   at
>
> System.Data.Entity.Core.Metadata.Edm.DefaultAssemblyResolver.ResolveAssembly
> (System.Reflection.AssemblyName referenceName) [0x00019] in
>
> C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\DefaultAssemblyResolver.cs:30
>
>   at
>
> System.Data.Entity.Core.Metadata.Edm.DefaultAssemblyResolver.TryResolveAssemblyReference
> (System.Reflection.AssemblyName refernceName, System.Reflection.Assembly&
> assembly) [0x00000] in
>
> C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\DefaultAssemblyResolver.cs:14
>
>   at
>
> System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.ResolveAssemblyName
> (System.String assemblyName,
> System.Data.Entity.Core.Metadata.Edm.MetadataArtifactAssemblyResolver
> resolver) [0x00007] in
>
> C:\cygwin\sources\mono\external\entityframework\src\EntityFramework\Core\Metadata\Edm\MetadataArtifactLoaderCompositeResource.cs:272
>
>   at
>
> System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader
> (System.String path, ExtensionCheck extensionCheck, System.String
> validExtension, ICollection`1 uriRegistry,
> System.Data.Entity.Core.Metadata.Edm.MetadataArtifactAssemblyResolver
> resolver) [0x0004d] in
> C:\cygwin\sources\mono\external\e
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130830/6ecc0eb8/attachment-0001.html>