ActiveSharp Work Item Rss Feed

Commented Issue: Exception when running on .net 4.0 beta

oysteinkrog — Thu, 20 Aug 2009 16:46:24 GMT

System.NotSupportedException occurred
Message=Cannot execute code on a dynamic assembly without run access.
Source=mscorlib
StackTrace:
at System.Delegate.BindToMethodInfo(Object target, IRuntimeMethodInfo method, RuntimeType methodType, DelegateBindingFlags flags)
at System.Delegate.CreateDelegate(Type type, Object firstArgument, MethodInfo method, Boolean throwOnBindFailure)
at System.Delegate.CreateDelegate(Type type, Object firstArgument, MethodInfo method)
at ActiveSharp.PropertyMapping.OffsetUtil.OffsetInvoker`1..cctor() in H:\WORK\SVN\trunk\code\thirdparty\model\ActiveSharp\PropertyMapping\OffsetUtil.cs:line 59
InnerException:
Comments: ** Comment from web user: oysteinkrog **

No problem.
Let me know if you need any more information;P

Commented Issue: Exception when running on .net 4.0 beta

johnrusk — Tue, 18 Aug 2009 09:43:32 GMT

Thanks for logging this.

I don't have access to .NET 4.0 right now, but will make a note to look into this in the future.

Created Issue: Exception when running on .net 4.0 beta

oysteinkrog — Mon, 17 Aug 2009 21:51:44 GMT

Commented Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

mikestedman — Mon, 17 Nov 2008 09:33:20 GMT

In cases where there are multiple properties on an object which all reference the same underlying local variable by reference, then foundField will return an object which has already been added, so will throw an exception of type System.ArgumentException.

This is in FieldToPropertyMap.PopulateMap(Type targetType)
I've rebuilt the DLL and added an exception handler around the line : _map.Add(foundField.Name, property);
I believe this should be all that's needed to change, but I'm not 100% sure yet I haven't caused some unexpected side-effects.
Comments: ** Comment from web user: mikestedman **

John,

Thanks for the feedback.

You're probably right about the requirement for "two properties" - I'll turn my attention to solving the "right" problem. The second property was originally introduced to make binding easier.

Regards
Mike

Commented Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

johnrusk — Sat, 15 Nov 2008 21:57:57 GMT

Mike,

Would you be able to give me any example of when you find it useful to have "two properties referencing the same field"? As you can tell from my previous comments, I've assumed that it will be almost unheard of for two properties to pass the same field to SetValue. I'd be interested to understand your examples, in case I'm missing something.

As for the trick of falling back to the StackFrame, it's nice in theory but people have reported some issued with it in practice, to do with method inlining (which you might only see in Release builds). Here's a link:

http://www.lhotka.net/Article.aspx?area=4&id=0708c745-f009-4d09-9f91-6a349b5b0317 (Need to mark all methods, including the property itself and all the way thru to the one that gets the stack, with an attribute to prevent inlining)
I've only heard from one person who tried this. They tried it on all properties, didn't like it, and switched to ActiveSharp instead ;-)

John

Commented Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

mikestedman — Sat, 15 Nov 2008 08:50:32 GMT

Hi John,

Thanks for your speedy reply to Martin's (mcrimes) question. I work with Martin and stumbled across this issue with our use of ActiveSharp a couple of days ago.

We only use "two Properties referencing the same Field" occasionally so I'm loathe to give up ActiveSharp's advantages (and speed). But I'd also like to keep the SetValue in the client Property consistent to make it easier for our developers.

The approach I've taken so far is to modify ActiveSharp to detect the "two properties" situation and in those rare cases inspect the StackFrame to find the property name.

BTW I'm not asking you to change ActiveSharp or debug my code!

I'd just like your expert opinion on whether this is a worthwhile approach to pursue further. I accept that inspecting the StackFrame is much slower than your technique.

Regards

Mike

Commented Issue: Fix MSIL parsing for method calls on struct fields

johnrusk — Sat, 15 Nov 2008 05:08:56 GMT

The MSIL parsing finds "by ref" usage of fields by looking for the ldflda (load field address) instruction. However, that instruction is also used when the code needs to call a method on a field that is of a value (struct) type.

This means that if you have one property which uses the field in the normal ActiveSharp way; and another which calls a method on the struct that's in the field; then ActiveSharp will incorrectly say that two properties are using the same field 'by ref'.

As of today's release (release 1.1) I have fixed this for calls to methods on structs that take no parameters (e.g. int?.HasValue) but I have not fixed it for calls to methods on structs which take parameters (e.g. int?.Equals). In the latter case you will still get the exception.

The reason why the latter case is harder is that today's fix works by pairing up the ldflda with the call to the struct method. However, for methods that take parameters, there may be other calls in _between_ those two instructions (calls to prepare parameter values), and the parsing code is currently not smart enough to tell which call actually goes with the ldflda. The solution is possible, but regrettably I don't have time to implement it right now.

Let me know if its affecting you, since the more people it affects, the sooner I'll find some time to fix it ;-)
Comments: ** Comment from web user: johnrusk **

In the meantime, a workaround is to assign the struct field to a local variable, call the method on the local variable, then assign the local variable back to the struct. This workaround will avoid the problem.

Created Issue: Fix MSIL parsing for method calls on struct fields

johnrusk — Sat, 15 Nov 2008 05:05:02 GMT

Closed Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

johnrusk — Sat, 15 Nov 2008 04:55:40 GMT

Commented Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

johnrusk — Sat, 15 Nov 2008 04:53:41 GMT

Hi,

Except for one situation, which I'll describe below, I'm afraid this behaviour is actually "by design".

Yes, it should give a better exception message, and in fact, as of today's release it does, but I'm not sure that any truly comprehensive solution is possible.

In particular, if two properties were to pass the same field "by ref" to a "SetValue" method, then ActiveSharp would have no way to figure out which _one_ property maps to the field. (And it needs to do that, so that when the field value is changed it can send out the right property change notification).

So, it is impossible to pass the same field to SetValue from two different properties. ActiveSharp will never be able to solve that for you, I'm sorry,

However, if you are only passing it to SetValue (or whatever your method is called) in _one_ property, and you are doing something else with it 'by ref' in the other property, then you can probably use this work-around: in the other property, assign the field to a local variable, pass the local variable by ref, and then assign it back to the field after you have finished.

I mentioned a situation where this behaviour is not "by design". It is when a property makes a method call on a field of a value type, and the method takes parameters. You will see the same error in that case, and in that case it is a bug. I'll log a separate issue on this shortly.

Regards

John

Created Issue: ArgumentException from PopulateMap when multiple Props reference same local variable byref

mcrimes — Thu, 13 Nov 2008 19:51:35 GMT

Commented Issue: Avoid ambiguity in complex inheritance situations

johnrusk — Fri, 15 Aug 2008 08:04:43 GMT

Currently, fields are identified by name. May be troublesome with derived fields having names that match ancestor ones.

Also, private properties in ancestor classes may cause trouble (SetValue executes, knowing that "this" is of type Derived, but in response to setting of private property defined in Base. The FieldToPropertyMap for Derived will not have that field in it.)

To fix:

(a) populate field to property map by reflecting on declared members only and walking up the inheritance hiearchy explictly
(b) use FieldInfos rather than field names. (Beware issues with mismatched ReflectedType properties, preventing expected equality of FieldInfo objects. Will only be an issue if field is used at different point in heirarchcy from where it is defined (OffsetToFieldMap has one ReflectedType, FieldToPropertyMap has another??? Depends how the ReflectedType is set in the stuff we get back when setting up FieldToPropertyMap)
Comments: ** Comment from web user: johnrusk **

Thanks for your comment. I do intend to address this issue, but can't give a definite date right now (due to other commitments taking up my time).

Commented Issue: Avoid ambiguity in complex inheritance situations

HakanL — Wed, 13 Aug 2008 05:30:05 GMT

Hi,
I'm running into this issue where I have a base class with an Id property that has a private set method. I'm setting this inside this class, but it's called by an inherited class so the case above where the FieldToPropertyMap doesn't have the field happens. I stepped thru your code to see what happens and I see that all the properties are returned by GetProperties in the PropertyMap, but it doesn't identify the instructions to add it to the map. I can just change my class to not have this as private, but it would be "nice to have" this handled.

CREATED TASK: Optimize performance

johnrusk — Sat, 24 May 2008 21:46:21 GMT

Two things worth trying and profiling:

(a) Look up types by RuntimeTypeHandle rather than Type, since getting the former is faster. Just need to sort out how LazyDictionaryOfTypes will work, since need to change it to be indexed by RuntimeTypeHandles - - see Type.GetTypeFromHandle because it will still need to get the type, to get the assembly, when initializing it's list of "keys"

(b) Make it so that it doesn't have to do multi-step Dictionary lookups. Want this: once we have the data for the type concerned, just use the offset value to index directly into an array of PropertyInfos. (Array will have "gaps" if we just offset values directly, since most are 4 bytes apart from each other, except bools etc).

CLOSED ISSUE: Doesn't work for private fields in abstract superclasses

johnrusk — Wed, 12 Mar 2008 07:16:18 GMT

Since it works by making instance of the classes, it cannot work for those that are abstract.

Need to re-organise the code so that it does not need to create instances of these classes, but can still get at their fields enough to get their offsets.
Comments: It now makes instance of derived (non-abstract) class

CREATED ISSUE: Doesn't work for private fields in abstract superclasses

johnrusk — Sun, 09 Mar 2008 04:27:46 GMT

CREATED ISSUE: Avoid ambiguity in complex inheritance situations

johnrusk — Sun, 10 Feb 2008 03:02:29 GMT

CREATED ISSUE: Missing unit tests for LazyDictionary

johnrusk — Sun, 10 Feb 2008 02:55:18 GMT

Tests are there, but not implemented. Implement them

CLOSED ISSUE: Error when derived classes use base's SetValueMethod

johnrusk — Sun, 10 Feb 2008 02:50:52 GMT

You should be able to define a protectect SetValue method in a base class, and use it from derived classes. Right now, that doesn;t work.
Comments: Fixed in changeset 7395

CREATED ISSUE: Error when derived classes use base's SetValueMethod

johnrusk — Sat, 09 Feb 2008 22:39:47 GMT

You should be able to define a protectect SetValue method in a base class, and use it from derived classes. Right now, that doesn;t work.