Search for IElements in all assemblies #104
Conversation
….Elements library
|
Seems like this is failing because number of tests related to structural framing are failing during deserialization of json. In the future I recommend doing This happens when you try to reflect on an assembly that can't be loaded for reflection. So our logic for loading is too broad. This is noted here. The assembly that it's trying to load is one that is used for testing. So this error would only happen during testing. |
|
What is the expectation with this work? Is the expectation that you'll be able to serialize a model containing your |
|
It makes sense that we would need access to the types if we are going to
Deserialize. Currently we are creating a "core" library that all of our
separate functions reference, and our personalized Elements will live in
there. This means get executing assembly wouldn't cover it. One thought
that might work would be to use the Fody wrapper Costura to pull all of the
dll into one... But I don't know if that would make .GetExecutingAssembly()
to work off the top of my head. If that was the answer, maybe that Costura
step could be built into the 'hypar publish' step?
When I run dotnet test locally on the elements library I don't get any
errors... I even confirmed I think that the dll in your error is indeed
being loaded. Microsoft.VisualStudio.TestPlatform.ObjectModel is among the
Assemblies inspected when I run the tests locally. And 97/98 tests
succeed. Elements.Tests.IfcTests.IFC is skipped for some reason.
Final thought. Would there be a way to make iteration over all Assemblies
protected against this error? Either simply try-catch, or maybe some
property that let's us check if it is safe to load types from an assembly.
I don't see the error right now, so it's hard to test these options.
…On Wed, Feb 20, 2019, 04:24 Ian Keough ***@***.***> wrote:
What is the expectation with this work? Is the expectation that you'll be
able to serialize a model containing your Element types to JSON and have
that be deserialized by another instance of Elements? If so, the
deserializing instance would have to have access to your type. How we allow
arbitrary elements to be serialized and deserialized into a Model
requires some design.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFmaOxnYw68T3GtP2oYux8tmOA5pD5Jxks5vPPhJgaJpZM4a-uv_>
.
|
|
Restating the problem: we need a way for those who write types which extend the Elements library to serialize and deserialize those types as part of a |
|
Tracking in #107. |
|
Looks cool to me! Nice solution that doesn't appear to need any
intervention from the user's end, while also not loading assemblies wildly.
close away.
…On Fri, Mar 8, 2019 at 2:05 AM Ian Keough ***@***.***> wrote:
@wynged <https://github.com/wynged> A slightly more robust fix is
proposed in #115 <#115>. Does
that work for you? If so, I'm going to close this and merge that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFmaOwxyXmuzfg2xNSJsG_5jqOi2nSmKks5vUf27gaJpZM4a-uv_>
.
|
|
so, because this is solved in the extensions pull request, I"m closing this one to tidy up. |
|
Thanks. I'll merge the PR. |
rather than the just the Hypar Elements library