As SY01 problems go

[DimPrawn]

Are the .pdb files present?

[Spacecadet]

So I should ask the vendor for access to their code repository and fix it myself?

You should do what is required to accomplish the task the client has asked you to complete if that means debugging without breakpoints then that is what you have to do.

[suityou01]

Are the .pdb files present?

No. It stops generating them.

Specifically what I have tracked down by decompiling the vendors product is that it uses CodeDomProvider to launch a remote debugging session. It could specify the target but it doesn't. Appalling code.

So what happens is that, when it stops working it tries to launch the 64bit csc.exe in a 32bit shell. And boom. But silent boom.

Took quite a bit of digging to find that little nugget.

[suityou01]

You should do what is required to accomplish the task the client has asked you to complete if that means debugging without breakpoints then that is what you have to do.

Yep, aware of that.

a) It makes the task infinately harder, because of where the code is excuted from within the tool.
b) It will take longer so all deadlines will now be missed by some chalk.

You're not helping BTW. #justsayin

[DimPrawn]

You can't (remote) debug a 64 bit .NET assembly using a 32 bit dev machine either. Both need to be 64 bit OS.

HTH BIDI

[aussielong]

Not with this tool I'm afraid. Dumping out to text file is about the best I can achieve. Bluddy annoying.

Generally, break your code down to bits you can unit test in isolation outside of the vendor container. Follow that and you shouldn't need to do breakpoint debugging in the container.

[suityou01]

Generally, break your code down to bits you can unit test in isolation outside of the vendor container. Follow that and you shouldn't need to do breakpoint debugging in the container.

Not going to work in this instance.

For instance, the screen uses a grid component written by the vendor. My code populates a dataset, which the grid retrieves by inversion of control. So the only way to catch it "il flagranti" and see what the grid component is up to is with the debugger.

I'm probably not explaining it very well, but trust me not having the debugger is a serious handicap.

[DimPrawn]

Document each problem with possible solutions and timescales.

Let the client manager decide how they want to handle this.

[suityou01]

You can't (remote) debug a 64 bit .NET assembly using a 32 bit dev machine either. Both need to be 64 bit OS.

HTH BIDI

It's a 32 bit assembly. That's the point prawn, try to keep up old son.

When it works, it (windows) provides the correct version of CSC.exe to the tool, and it compiles the injected classes and generates the pdbs.

When it stops working, windows for some reason says "Ah ok you need a debugger, better have the default one then, here it is all 64 bits of it".

If in their code, when calling the remote debugger they actually stiplulated x86 I would not be having this problem.

The question would be, how do I make the 32 bit version of the framework the default? Or put another way, when a 32 bit app calls the remote debugger, wtf does it pass back a 64 bit instance?

[sasguru]

Thoughts?

Yes. But not very helpful ones for you.