Can I debug a .lpt template opened by the LLBLGen VS extension directly in Visual Studio or is debugging required to done in the LLBLGen Designer?

Yes you can. Please take a look at this documentation link and look for the 'Debugging' sub-section.

What LLBLGen version are you using btw?

It's in the general docs: https://www.llblgen.com/Documentation/5.5/Designer/How%20To/TemplatesDebug.htm

Please consult the designer documentation https://www.llblgen.com/Documentation/5.5/Designer/How%20Toworkwithtemplates.htm

Hmmm,

Help me understand.

I've already seen those docs, and the newest one say's that you need to attach Visual Studio to the LLBLGen Designer.

So, when I load the project into the LLBLGen Designer. and I attach a "visual Studio instance to the designer and F7 with debugging, IT WORKS.

However,

1. When I load the project into Visual Studio and F7 "WITHOUT" attaching the to LLBLGen Designer IT DOES NOT WORK.

Alternatively,

1. 1. When I load the project into Visual Studio and F7 "DO" attach the to LLBLGen Designer IT STILL DOES NOT WORK.

So, for me when the project is loaded into Visual Studio and F7 from there it's not working.

I'm I misunderstanding something?

Thank you

It's key you specify the Debugger.Break() statement in your template and it will be hit when you generate code. Attaching an empty VS instance to the designer and then generating code will hit the Debugger.Break() call which will break the debugger. If you don't have the Debugger.Break() you can't set a breakpoint so it won't break anywhere as the code to set the breakpoint on is generated at runtime and compiled in-memory, hence the necessity of Debugger.Break() (which is equal to setting a breakpoint on a line of code in an existing C# code file)

Important: Debugger.Break() has to be in template code, so between <% and %>. If you place it inside the code which is written to the output, it of course isn't executed.

Yes, I understand that about Debugger.Break(). I mentioned that I had that working fine (Just before #1).

My original question was "Can I debug a .lpt template opened by the LLBLGen VS extension directly in Visual Studio or is debugging required to done in the LLBLGen Designer?"

Daelmo said yes. So that's why I listed #1 & #2.

The project is loaded "into Visual Studio", not the designer. I'm F7ing from inside Visual Studio and checking the debug checkbox in the code generation dialog inside visual studio.

I think my question would be better clrified by saying "Can I "INITIATE" debugging a .lpt template directly in Visual Studio through the Generate Code dialog? (Enable template debugging checked)"

Thank you

KCarterSr wrote:

Yes, I understand that about Debugger.Break(). I mentioned that I had that working fine (Just before #1).

My original question was "Can I debug a .lpt template opened by the LLBLGen VS extension directly in Visual Studio or is debugging required to done in the LLBLGen Designer?"

Daelmo said yes. So that's why I listed #1 & #2.

Ah that's a misunderstanding, you have to debug in vs as you have to debug using the normal .NET debugger. The designer generates a piece of code which writes the output (so it converts the template into a piece of code), and debugging that requires a .net debugger and that's part of visual studio. The designer itself doesn't contain a .net debugger. (one isn't allowed to distribute that, even if we wanted to)

The project is loaded "into Visual Studio", not the designer. I'm F7ing from inside Visual Studio and checking the debug checkbox in the code generation dialog inside visual studio.

I think my question would be better clrified by saying "Can I "INITIATE" debugging a .lpt template directly in Visual Studio through the Generate Code dialog? (Enable template debugging checked)" Thank you

No, you can't do that, you have to attach the debugger yourself as it's not part of our system. The designer integrated inside VS is actually the same designer, wrapped in a VSIX.

It's best to attach a second vs instance to the designer, as the .NET based integration of elements inside VS is a bit cumbersome (they use a shared appdomain inside VS, as all add-ins inside Visual studio based on .NET share the same appdomain, artificially separated internally which doesn't always work. We ran into this limitation the hard way when we needed to do assembly discovery inside the designer and this didn't work that well due to the artificial separation of processes in the shared appdomain.)

So to avoid problems with vs being lame regarding add-ins written in C#, it's best if you debug templates using a separate vs instance you attach to the one running the designer as an add-in.