No announcement yet.

Debug information broken in the generated assembly

  • Filter
  • Time
  • Show
Clear All
new posts

    Debug information broken in the generated assembly


    It appears that the "BridgeCompilerTask" breaks the debug information (or breaks the link to the .PDB) of the end-user assembly produced by the compilation of a Bridge project.

    Do you know what could be the cause and how we could patch the "BridgeCompilerTask" to prevent it from breaking the debug information of the end-user DLL?


    We are making a WPF application that takes a DLL compiled with Bridge and loads it via Assembly.LoadFrom() in order to make it run in the context of the WPF application (even though it is a Bridge-compiled DLL). To make this work, we are redirecting all the calls to the Corlib from Bridge.dll to Mscorlib.dll via [TypeForwardedTo] attributes. This works great and we are able to successfully load and run the assembly, but we are unable to make the Visual Studio step-by-step debugger work. In fact, when attached, the debugger says that "Binary was not built with debug information" (this can be seen from the "Modules" window of Visual Studio). The issue disappears if we comment out the "BridgeCompilerTask" located in the bridge "targets" file, which suggests that the "BridgeCompilerTask" may be making a change to the DLL that results in the inability to debug the assembly. Of course commenting out the "BridgeCompilerTask" is not an option for us because we need to keep the Bridge functionality (generation of JavaScript).


    1. Create two projects: a Bridge project ("BridgeProject.dll") and a WPF Application project ("WpfProject.exe")
    2. Build the Bridge project
    3. In the WPF Application project, change the constructor of the MainWindow in order to load the assembly "BridgeProject.dll". To do so, use the code:
    Assembly.LoadFrom(@"c:\replace with the path to the bridge project\bin\Debug\BridgeProject.dll");
    4. Launch the WPF Application. You should see no error messages and the "BridgeProject.dll" should be loaded properly.
    5. While the application is running, go to "Debug" => "Windows" => "Modules" to display all the assemblies loaded by the debugger, and look at the line that corresponds to "Bridge.dll".


    In the column "Symbols Status" there should be written either "Symbols loaded." or "Skipped loading symbols.".


    In the column "Symbols Status" it is written "Binary was not built with debug information."

    Note: I don't think the issue is related to the fact that the assembly uses a custom Corlib, because otherwise it wouldn't be fixed when simply commenting out the "BridgeCompilerTask" in "Bridge.Min.targets".

    Do you know what could be the cause and how we could patch the BridgeCompilerTask to prevent it from breaking the debug information of the end-user DLL, while retaining the functionality of the Bridge compiler?

    Thank you very much.
    Best regards,

    Hello Userware, and welcome to Bridge forums!

    Bridge is compiled and linked against bridge's version of mscorlib, that's expected not to resolve against the proper mscorlib when you try to force it in. The symbols should just not resolve, although you are getting a "not built with debug information".

    BridgeCompilerTask is just a call to bridge's translator which will parse the built DLL, which has instructions on how the JavaScript should be output, and translate the binary into JavaScript code. It is like a two-step compilation. First it builds the DLL, from Bridge's own implementation of mscorlib, which is a subset of mscorlib, currently, plus some instructions via attributes about their output as JavaScript. Then it does the actual translation by inspecting the assembly and then producing the JavaScript code.

    While the BridgeCompilerTask may extract embedded resources from DLL files (like js files from linked libraries), it does not perform write operations as like removing debugging symbols or anything else during this phase.

    It would be perfect if we could use native mscorlib to build Bridge, but this was one of the challenges faced whilst developing the framework. So much that we must explicitly declare we don't want to import mscorlib via the <NoStdLib/> setting in the C# project (.csproj) file or included project settings block.

    That said, it is expected not to be able to build or run Bridge applications built with native mscorlib, and linking with mscorlib is not supported.

    The way that should work interop between bridge and native projects is, having the same source code files between the two projects, with some exclusions that could be done, for example, using partial classes when bridge files required specific attributes (thus not including the partial classes attributes for Bridge in the native project, and vice-versa). This can be explored fairly well using the project file linking feature of msbuild.

    I hope this helps you better understand the concept and aid in assessing how to better handle the multi-target code for your application!