Debugging code from dynamically loaded assembly in .net core 2.0

前端 未结 5 643
一向
一向 2021-02-05 07:27

I have a .net core 2.0 console app that does the following (simplified):

var a = Assembly.Load(Assembly.GetEntryAssembly()
                              .GetRefe         


        
相关标签:
5条回答
  • 2021-02-05 07:34

    You code will not compile if you use Assembly.LoadFile way.

    I'have created a sample project in Visual studio 2017 community and I was able to step into a function from dynamic assembly by using both Assembly.LoadFile and Assembly.Loadways. I did not go with you code since it was not compiling, but i will provide a solution which i think you will solve your problem.

    Here is the solution: Full working solution is here https://github.com/beyazc/.netcore-dynamic-assembly-debug

    Basicly I was able yo debug with following code. You should press f11 on invoke method

    var assemlies = Assembly.GetEntryAssembly().GetReferencedAssemblies();
            var assemblyName = "";
            foreach (var item in assemlies)
            {
                if (item.Name == "RefProj")
                    assemblyName = item.Name;
    
            }
            var path = new FileInfo(Assembly.GetExecutingAssembly().Location);
            var a = Assembly.LoadFile(Path.Combine($@"{path}\..\..\..\..\..\RefProj\bin\Debug\netstandard2.0", "RefProj.dll"));
            var t = a.GetType("RefProj.Class1");
    
            var i = Activator.CreateInstance(t);
            MethodInfo mi = t.GetMethod("get1");
            mi.Invoke(i, null);
    
    0 讨论(0)
  • 2021-02-05 07:37

    This may be caused by the application not being able to locate PDB file associated with MyAssembly assembly, as mentioned in one of the comments. However, it seems that the PDB file is not required in the same folder as the assembly to make debugging work.

    In order to check if symbols are loaded, please put a breakpoint in the line just after calling Assembly.LoadFile() and open Modules window (it can be found in Debug\Windows menu in Visual Studio). In this window, find the MyAssembly assembly and verify value in Symbol Status column. If missing PDB is the cause, the value will be "Cannot find or open the PDB file.". You can also use that window to see where debugger tried to find the symbols file.

    Debugger looks for the PDB files in several locations, as described here: Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger.

    According to the article, the default locations for a PDB file are:

    1. Location specified inside the assembly itself (placed there by a linker when the assembly is compiled)
    2. Folder where the dynamically loaded assembly resides
    3. Local symbol cache folders
    4. Internet, network or local symbol servers

    I suppose that in Your case, the first or the second location mentioned should be considered.

    Another important thing to notice is that the PDB must exactly match the assembly, so after recompiling the assembly the PDB file should also be updated to match the new version.

    If the PDB file matches the assembly and resides in one of the mentioned locations, You should be able to debug the code.

    There may be other causes and this is not directly associated with the fact that .NET Core is used, but I suppose that correct PDB loading may be worth verifying.

    0 讨论(0)
  • 2021-02-05 07:43

    There is an 'Assembly.Load' override that takes PDB data as a parameter. You need to explicitly load the debug symbols.

    Check this SO post: Debug dynamically loaded assembly

    Also check out this on MSDN: https://msdn.microsoft.com/en-us/library/twt16z2x(v=vs.110).aspx

    Hope this helps

    0 讨论(0)
  • 2021-02-05 07:44

    Did you check option just my code?

    Enable Just My Code

    ("My Code") only, ignoring system code and other code that is optimized or that does not have debugging symbols.The debugger displays and steps into user code

    Maybe it should be unchecked?

    0 讨论(0)
  • 2021-02-05 07:44

    I agree with the answers of Lukasz and Alexan. If you've checked those and it does not work then the reason why your code examples differ could be that they do not load the same assembly.

    The executing assembly and entry assembly are not always the same assembly, so the paths can be different. It might also be that another version of the assembly is loaded, for instance from the GAC. Using the modules window in Visual Studio you can see which dll is loaded. If the correct PDB is present and Just My Code is turned off you should be able to step into it.

    0 讨论(0)
提交回复
热议问题