PostSharp

[cjhanson]

Gael,

I am building an aspect similar to OnMethodInvocation, and indeed I have copied and am modifying the weaver implementation. The DelegateMapper (and DelegateMap in build 360) are internals to PostSharp.Loas.Weaver. For some reason I was able to "trick" .NET by copying the types into my project and replacing references. However the project was refactored, and all aspects moved to another project, and now I am receiving:

Error 1 Unhandled exception: System.InvalidCastException: Unable to cast object of type 'PostSharp.Laos.Weaver.DelegateMapper' to type 'sw.Common.Aspects.Weavers.DelegateMapper'.
at sw.Common.Aspects.Weavers.BusinessRuleWeaver.Initialize() in C:\VSS\dev\sw\Common\Aspects\Weavers\BusinessRuleWeaver.cs:line 143
at PostSharp.Laos.Weaver.LaosTask.Execute() in p:\branches\1.0\Laos\PostSharp.Laos.Weaver\LaosTask.cs:line 408
at PostSharp.Extensibility.Project.ExecutePhase(String phase) in p:\branches\1.0\Core\PostSharp.Core\Extensibility\Project.cs:line 1044
at PostSharp.Extensibility.Project.Execute() in p:\branches\1.0\Core\PostSharp.Core\Extensibility\Project.cs:line 1082
at PostSharp.Extensibility.PostSharpObject.ExecuteProjects() in p:\branches\1.0\Core\PostSharp.Core\Extensibility\PostSharpObject.cs:line 581
at PostSharp.Extensibility.PostSharpObject.InvokeProjects(ProjectInvocation[] projectInvocations) in p:\branches\1.0\Core\PostSharp.Core\Extensibility\PostSharpObject.cs:line 564
at PostSharp.MSBuild.PostSharpRemoteTask.Execute(PostSharpTaskParameters parameters, TaskLoggingHelper log) in p:\branches\1.0\Core\PostSharp.MSBuild\PostSharpRemoteTask.cs:line 107 Development.DataPersistence

I don't think my copy-out approach should have worked to begin with, and I am unsure as to why it did... (very troubling). My current workaround approach is to write an accessor for these types.

The weaver only differs from OnMethodInvocationAspectWeaver in that applying multiple aspects to the same method creates a method invocation chain so that multiple woven methods can be executed before reaching the original method body. I had intended to modify functionality further such that a parameter of the attribute which applies the aspect will allow the coder to select a course of action before entering the original method body, such as "throw exception", "return null", or "continue". If I can implement it generically, I will call it "OnMethodInvocationChainAspectWeaver" and submit it back to you for inclusion in Laos. For now the goal is to implement a BLL with as much decomposition as logically applicable.

I was wondering if you'd be open to changing the access modifiers for weaver implementations and their dependencies to public to allow one-off implementations?

Thank you!

[gfraiteur]

I will expose the DelegateMapper and the DelegateMap classes in the next build. These were actually the last utility classes that were not public.

The DelegateMapper will be accessible from the property LaosTask.DelegateMapper.

As for accepting multiple OnMethodInvocation aspects on a single method, it's of course a feature that is high on the to-do list. But this aspect is so complex and so fragile that I prefer not to put the feature in 1.0.

Good luck,

Gael

[gfraiteur]

You can monitor this issue:

http://www.postsharp.org/tracker/view.php?id=211

[cjhanson]

When is the next build slated for?

(Just curious if I should continue with my hack to meet my deadline or put that off and work on other functionality)

[gfraiteur]

I don't plan builds, but I could do some this evening if you wish.

Gael

[cjhanson]

That would be great!

Thank you!

[gfraiteur]

Done.

At http://download.postsharp.org/builds/1.0/.

Note that this build is badly tested.

Gael

[cjhanson]

The installer does not work:

This installation package is not supported by this processor type. Contact your product vendor

(I am x86.)

The MethodInvocation class works as expected, although I did have to comment the call to SetOwnTargetRedirection inside ImplementOnSiteWeaving because while it was chaining, the RuntimeInitialize on my Binding aspect was being passed a chain-link MethodBase (returning "~firstcall~~secondcall~") when I need the original MethodBase. My solution is to modify the call to CreateMethodDeclaration from ImplementOnSiteWeaving, as follows:

Code: Select all

this.CreateMethodDeclaration(
                originalMethod.DeclaringType,
                originalMethod, null, delegateAndMappings.CallerToWrapperGenericMap,
                delegateAndMappings.CallerToWrapperInverseGenericMap, "~" + ((Interfaces.IOnMethodInvocationChainAspect)this.Aspect).UniqueName + "~",
                true,
                false,
                true,
                false,
                out parameterOrdinalShift,
                out implementationMethod);


Code: Select all

    public interface IOnMethodInvocationChainAspect
    {
        string UniqueName
        {
            get;
        }
    }


Code: Select all

    public class BusinessRuleAspect : OnMethodInvocationAspect, Weavers.Interfaces.IOnMethodInvocationChainAspect
{
    ...
        #region - Construction -

            /// <summary>
            /// This attribute can not be constructed without the unique name!
            /// </summary>
            private BusinessRuleAspect()
            {
            }

            /// <summary>
            /// Constructor that provides a unique name for weaving
            /// </summary>
            /// <param name="boundBusinessRuleType"></param>
            public BusinessRuleAspect( Type boundBusinessRuleType )
            {
                _uniqueName = boundBusinessRuleType.Name;
                _appliedToTypeName = boundBusinessRuleType.AssemblyQualifiedName;
            }
   
        #endregion

        #region - IOnMethodInvocationChainAspect Implementation -

            /// <summary>
            /// Returns a unique name which is used in method wrapper naming to allow method chaining
            /// </summary>
            string Weavers.Interfaces.IOnMethodInvocationChainAspect.UniqueName
            {
                get { return _uniqueName; }
            }

        #endregion
    ...
}


Also, the DebuggerNonUserCode attribute is getting moved which is desired, however the CompilerGenerated attribute is not. (There are multiple CompilerGenerated attribues on the original method).

I am now receiving the desired functionality without any work-arounds, and indeed I am now ready to move on to the DAL now that the BLL is good to go. Hope my feedback helps!

And while I'm sure you get this over and over... Thanks Gael!
Your assistance has been invaluable.

[gfraiteur]

You're welcome.

Sorry with the problems with the installer. I did an untested build just for you .

Gael