ok i forgot about output pane. so what i see here...

ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL

On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote:
> ok i forgot about output pane. so what i see here...
>
> ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL

so the problem with debug server formats?
i wish it would work with visual studio 2013 soon, but at least x64 debug works so i can continue using it for now \0/

Sorry for the delay, I've been away for a couple of days.

On 07.11.2013 07:13, Alexander Bothe wrote:
> On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze wrote:
>>
>> Yeah, being able to get releases out more often, and having bug fixes
>> being tested in the field would be nice. But I think we should not
>> over-engineer things here.
>> Do you have a web-server that could do the compilation?
>>
> No - I just have got a normal dedicated web-server thingy for php&mysql ^_^
>
> But well, just a very small infrastructure that allows us to update
> software more often - a couple of hours ago I implemented this new
> eponymous template syntax..and now you had to release another VisualD to
> have it in there, right?

ATM, yes. Maybe we can create a small update installer for the DParser component that you could also build.

Another option might be to get a time slot on the auto tester build servers. I could try to prepare a script to do a Visual D build from the necessary branches. Brad, would that be possible?

On 10.11.2013 08:13, Nicholas Londey wrote:
> Have a look at this and see if that helps. I think I got it working in
> vs2013 because it was the announcement that it should be working that
> prompted me to find out why it wasn't.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11457

Unfortunately the beta test has been done with the 8.0 Widows SDK only, and Microsoft changed their library paths again with the 8.1 SDK.

On 12.11.2013 08:25, evilrat wrote:
> On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote:
>> ok i forgot about output pane. so what i see here...
>>
>> ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL
>
> so the problem with debug server formats?
> i wish it would work with visual studio 2013 soon, but at least x64
> debug works so i can continue using it for now \0/

This message is emitted by cv2pdb that is used to convert the debug information to a pdb file. Unfortunately cv2pdb is not yet updated for VS2013. I haven't tried it, but a workaround might be to copy the file vc\bin\mspdb120.dll to mspdb110.dll.

If you switch the debugger to "Mago", the conversion is no longer needed, so you can still build and debug Win32 executables.

On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:
> If you switch the debugger to "Mago", the conversion is no longer needed, so you can still build and debug Win32 executables.

mago gives "cannot launch debugger on %appname%. hr = 897...", so only x64 debugger left for usage

On 12.11.2013 10:19, evilrat wrote:
> On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:
>> If you switch the debugger to "Mago", the conversion is no longer
>> needed, so you can still build and debug Win32 executables.
>
> mago gives "cannot launch debugger on %appname%. hr = 897...", so only
> x64 debugger left for usage

Are you sure that you are not trying to debug a 64-bit executable with mago? Maybe the working directory is invalid, this can also cause problems.

If it still fails, please show the full error code, maybe I can guess what's going wrong.

I have the same issue with the same VS2013 Shell.
I am using W7 PROF 32bit
I have tried with mago and that works.
I am new to D. What is wrong with using mago, if anything ?

Thanks
DBJ

On Wednesday, 13 November 2013 at 06:48:44 UTC, Rainer Schuetze wrote:
>
>
> On 12.11.2013 10:19, evilrat wrote:
>> On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:
>>> If you switch the debugger to "Mago", the conversion is no longer
>>> needed, so you can still build and debug Win32 executables.
>>
>> mago gives "cannot launch debugger on %appname%. hr = 897...", so only
>> x64 debugger left for usage
>
> Are you sure that you are not trying to debug a 64-bit executable with mago? Maybe the working directory is invalid, this can also cause problems.
>
> If it still fails, please show the full error code, maybe I can guess what's going wrong.

Are there any news on that issue ?
I get the same error Messages as mentioned with these debuggers:
VS and VS (x86 Mixed Mode) OUTPUT: AppName.pdb: cannot load PDB helper DLL
Mago WIN ERROR MESSAGE: cannot launch debugger on AppNamel.exe hr = 89710016

AppName is a 32-Bit executable.

Its on a fresh installed Win 8 with VS2013, unfortunately no old VS2012 dlls available. Would it help to upgrade to Win 8.1 ?

On 04.02.2014 18:47, ParticlePeter wrote:
> On Wednesday, 13 November 2013 at 06:48:44 UTC, Rainer Schuetze wrote:
>>
>>
>> On 12.11.2013 10:19, evilrat wrote:
>>> On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:
>>>> If you switch the debugger to "Mago", the conversion is no longer
>>>> needed, so you can still build and debug Win32 executables.
>>>
>>> mago gives "cannot launch debugger on %appname%. hr = 897...", so only
>>> x64 debugger left for usage
>>
>> Are you sure that you are not trying to debug a 64-bit executable with
>> mago? Maybe the working directory is invalid, this can also cause
>> problems.
>>
>> If it still fails, please show the full error code, maybe I can guess
>> what's going wrong.
>
> Are there any news on that issue ?
> I get the same error Messages as mentioned with these debuggers:
> VS and VS (x86 Mixed Mode) OUTPUT: AppName.pdb: cannot load PDB helper DLL
> Mago WIN ERROR MESSAGE: cannot launch debugger on AppNamel.exe hr =
> 89710016
>
> AppName is a 32-Bit executable.
>
> Its on a fresh installed Win 8 with VS2013, unfortunately no old VS2012
> dlls available. Would it help to upgrade to Win 8.1 ?
>


Have you tried the latest beta version [1]? This had some improvements in cv2pdb to find the ms*pdb.dll and some fixes in mago aswell.

Launching a program with a non-existing working directory causes this problem, too. Maybe you have made a typo there?

[1] https://github.com/D-Programming-Language/visuald/releases