Debugging decorated methods yields "Source Not Available" error.

[Nelladel]

Note: I'm still not a Patron, since I'm evaluating Fody. The issue below refers to a simple Test program used to check the suitability of using Fody + Weavers.

Note 2: A question has already been raised on Stack Overflow, with the fody and compile-time-weaving tags.

Note 3: A minimal repro repository can be found here (note that the repository code has been stripped of even further code than what was posted in the SO question, and still fails).

Note 4: An issue has also been raised on the main Fody repo in Github.

Using:

• Fody version 6.2.0
• Visual Studio 2019 Community Edition
• MethodDecorator weaver version 1.1.0
• MSBuild 16.6.22303
• .NET Framework 4.7.2

As per the Stack Overflow issue mentioned above:

I have the following scenario:

Where ProjectA is a simple class library, and ProjectB is a Console Application.

ProjectA.Class1.cs contains the following code:

using System;

namespace ProjectA
{
    public class Class1
    {
        public void A()
        {
            B();
        }

        [Weaver]
        public void B()
        {
            Console.WriteLine("I'm in B()");
        }
    }
}

ProjectA.Weaver.cs contains:

using MethodDecorator.Fody.Interfaces;
using System;
using System.Reflection;

namespace ProjectA
{
    class Weaver : Attribute, IMethodDecorator
    {
        public void Init(object instance, MethodBase method, object[] args)
        {
            Console.WriteLine("Initialising");
        }

        public void OnEntry()
        {
            Console.WriteLine("Entry");
        }

        public void OnException(Exception exception)
        {
            Console.WriteLine("Exception");
        }

        public void OnExit()
        {
            Console.WriteLine("Exit");
        }
    }
}

And the Console Application's (ProjectB.Program.cs)entry point contains:

using ProjectA;

namespace ProjectB
{
    class Program
    {
        static void Main(string[] args)
        {
            var a = new Class1();

            a.A();
        }
    }
}

And ProjectA.FodyWeavers.xml contains:

<?xml version="1.0" encoding="utf-8"?>
<Weavers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FodyWeavers.xsd">
	<MethodDecorator></MethodDecorator>
</Weavers>

If I put a breakpoing inside Class1.A(), and attempt to Step-into (F11), the following Source Not Available window pops up:

Is there a way to:

• Prevent the debugger from attempting to step into the weaver
• Tell the debugger where the source code for the weaver is

I've tried:

• Enabling Just My Code
• Adding Attributes to the Weaver.cs methods ([DebbugerNonUserCode], [DebbugerStepThrough], [DebbugerHidden]...)
• Adding the Fody references to the ProjectB
• Setting the project's Build Debugging Information to Full

Expected behaviour:

Either enter into the weaver code, or at least skip it and go further into the call stack.

[SimonCropp]

While this is possible, the effort involved is significant. Unfortunately the ROI for this feature is not worth the effort.

@Nelladel if you want to go to the effort of submitting a pull request that adds this feature I am happy to consider it

[Nelladel]

Hi @SimonCropp :

Thank you for the quick response! I spent a whole lot of time attempting to find a solution, and came out empty-handed. I was wondering if I was doing something really dumb and couldn't get it to work, or the feature was just impossible (or way too hard) to implement.

So, that means that if I'm in the debugging stage of the project, I should just remove ALL weaver attributes from the methods, and then apply them once I'm done?

I'd love to submit a pull-request, but this is completely out of my pay-grade, as I have no idea about what's going on or where to begin. Sorry :(

[SimonCropp]

for each instruction injected you need to mark it as hidden https://github.com/Fody/Janitor/blob/master/Janitor.Fody/CecilExtensions.cs#L215

[tom-englert]

I'm not sure if this HideLineFromDebugger still works, I once had some troubles with this.
I usually just do not touch the instruction that a sequence point is referencing, so #254 may fix this issue.