Building a debug version of the client in Visual Studio 2005

I am starting work programming a new BOINC project, and I am having trouble getting a working **debug** build of the client, specifically of boinc.exe. I am working with
Visual Studio 2005, on Windows XP, and I think my problem relates to something new in VS2005, the attachment of some 'manifest' to the executables, with the end result
being they don't link up at run time.

I suspect that somebody who has tried to make (and run!) a debug build in VS2005 has run into something like this issue, I'm hoping somebody here knows how to fix it!

My immediate goal is to get a debug version of what BOINC installed working, so I can study how it works, and diagnose problems in my yet-to-exist server and otherwise.
The build isn't working, however. The gory details of what I have done...

I downloaded the (release) BOINC stuff, 5.10.20, installed it, tested it for a couple of weeks doing work for Seti@Home, it worked fine. So I have this as a reference version,
one that works just great.

I got Subversion, and got the BOINC source code and samples. I decided to try and match 5.10.20 as well as I could, so I got revision 13446 of the code, which matched 5.10.20
as well as I could tell. (I guess I should have got something from the tags, however.) It turns out that my builds are reporting the version as 5.11.0, not 5.10.20, but I don't
think this is related to my current problem. After discovering that this needs the wxWidget stuff to build, I got version 2.8.6 of that code.
(BOINC 5.10.20 seemed to use wxWidgets 2.8.3, I couldn't find that exact version.)

So, I have source code that should at least be really close to my reference distribution. On to building it... I was able to find the right solution files for VS2005 easily enough,
and soon had both debug and release builds of wxWidgets, boinc, and boinc_client, with no errors. So far so good!

I also built boinc_samples, and my uppercase project is working great, I even put our logo into it. No problems there...

On studying my reference version, I see that there is a boot startup shortcut to run boincmgr.exe /s, which then starts boinc.exe -redirectio -launched_by_manager.
To keep things under control, I deleted the startup shortcut, and created my own, so I can turn it off and on at will, it still does Seti work fine.

Ok, so I want to try mine. After turning off the reference BOINC... I've tried running my debug build two different ways, both have similar results.

A) In the boinc.sln, I set boincmgr as my startup project (if it wasn't already), and started it, in the directory where the build put it. It almost works...
I can trace boincmgr as it starts up, and see where it tries to CreateProcess() to start boinc.exe. The command line looks to be ok, and CreateProcess() returns success...
but no sign of any boinc.exe process ever shows up. Boincmgr then tries some winsock calls to talk to boinc.exe, but is never able to connect to anything. It tries again,
but it never works. I never see boinc.exe in the Task Manager list. I have added a DebugBreak() at the start of the initialization of boinc.exe, it never hits.
I think that the system is trying to load boinc.exe, but it has an error when loading, and the process dies right away.

I can open the UI in boincmgr, and other than the fact that it has no data (no projects, etc.), it seems to work.

B) I've tried making a copy of the working reference distribution, and replacing the executables with my debug builds, and making a shortcut to start it. When I run the shortcut,
the BOINC icon appears in the taskbar as boincmgr starts, but it never connects to anything, and starts giving messages. Meanwhile, no sign of boinc.exe in the process list,
or of it hitting its breakpoint at the top of main(). Basically the same behavior as case A.

So somehow, starting boinc.exe is failing. Ok, so now I try making boinc my startup project, and try and run that under the debugger. To help me notice if it ever does load,
I added a DebugBreak() right at the top of main, so I should be notified of the break if it ever happens. When I run the debug boinc.exe, it crashes immediately,
"This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem." That DLL is part of the C runtime library,
and notice that it is a RELEASE version. (The debug one is named MSVCR80D.dll.) So I put a copy of this dll in the directory with boinc.exe, and try to run it again.
It again crashes immediately, this time with a different error dialog, that says:
"Runtime Error! ... R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information."
In neither of these cases did I ever hit my breakpoint.

So, what is up with those cryptic error messages? Some internet research on them lead me to the details of how the linking to the C Runtime Library (CRT) has changed in VS2005.
Apparently, Microsoft changed some important details about how executables link to the CRT. Some of the consequences, according to someone who claimed to be the lead manager
for the CRT, are as follows:
1) You cannot combine debug and release code. Each will want its own type of CRT dll, but not the same one, and thus there is a conflict, and the OS will not load the module.
2) A corollary to 1, if you have some third party static library, with only a release build, you cannot build a debug version of an app that links to it.
This second one basically means that release-only static libs are no longer supported, since if you can't make a debug build, you can't effectively develop software.

I ran the MS dependency checker tool, depends.exe, on my debug boinc.exe. It pops up an error dialog, and there are errors, due to a missing MSVCR80.DLL, which is referenced
by ZLIB1.DLL, SSLEAY32.DLL, LIBCURL.DLL, and LIBEAY32.DLL. When I check any of the other build targets, debug and release, including the release boinc.exe, they come out clean.
(Exception: All the checks did have some warning about DWMAPI.DLL, which seems to be some Windows thing. This doesn't generate an error dialog popup, unlike MSVCR80.dll.
I am not sure what to make of DWMAPI.dll, but I suspect it is not part of my problem.)

What I think is happening, is that the third party libs that boinc uses (zlib1, libcurl, sseay32, libeay32) are release builds only, and when I build a debug boinc.exe,
which links to those libs, I get a conflict, and now the OS won't load boinc.exe.

However, BOINC doesn't appear to come with debug versions of those libs. (At least, that I could find.) Are the debug versions what I need to get a build? Or is there another trick?

Anyways, sorry for the long post, but I wanted to show what I have tried.

Thanks,
Mark

OK, first off check your installations of the compiler, is it updated as it should be. When you were installing all the necessary software, did you follow CompileClient? If not, please do so.

You can set the version number before you compile BOINC by editing versions.h in the %BOINCSourceCode% directory. You need to edit all entries in there.

(I moved your thread to this forum, as it's in its place here)

---

OK, first off check your installations of the compiler, is it updated as it should be. When you were installing all the necessary software, did you follow CompileClient?

Yes to all. Thanks for putting this in the right board, I wasn't sure.

If you're making a BOINC app on your own project, you don't need to compile the client yourself. You would only need to debug the core client in VERY extreme cases, which would mean client bugs anyway. Just rely on the client doing its job and write your app, go back to debugging the client only if problems show up.

And you definitely don't need a debug version of the manager, so you can skip the whole getting-wxWidgets-to-work mess. You can use the official manager with your self-compiled client.

If you're making a BOINC app on your own project, you don't need to compile the client yourself. You would only need to debug the core client in VERY extreme cases, which would mean client bugs anyway. Just rely on the client doing its job and write your app, go back to debugging the client only if problems show up.

And you definitely don't need a debug version of the manager, so you can skip the whole getting-wxWidgets-to-work mess. You can use the official manager with your self-compiled client.

I realize that I won't be fixing things in the core client, but I figure that it will be very useful to be able to follow what it is doing. For instance, I am likely to send badly formed data from my server and my app, and watching how the core client deals with the bad data will help me figure out what is wrong with it.

So even if I don't end up tracing through the core client much, I do want to be able to do it if it seems important at the time.

The wxWidgets didn't seem to be much of a problem. Only about 2% of the trouble that boinc.exe has caused so far... And, btw, being able to debug the manager has provided a few clues as to why I can't run my boinc.exe, so it isn't a useless thing.

I realize that I won't be fixing things in the core client, but I figure that it will be very useful to be able to follow what it is doing. For instance, I am likely to send badly formed data from my server and my app, and watching how the core client deals with the bad data will help me figure out what is wrong with it.

I don't see how that is relevant unless you're writing your own BOINC server or the API for science apps to talk to the client. You would need to get deep in the server code to send malformed data.

I realize that I won't be fixing things in the core client, but I figure that it will be very useful to be able to follow what it is doing. For instance, I am likely to send badly formed data from my server and my app, and watching how the core client deals with the bad data will help me figure out what is wrong with it.

I don't see how that is relevant unless you're writing your own BOINC server or the API for science apps to talk to the client. You would need to get deep in the server code to send malformed data.

I guess I don't know exactly what I would be looking for, I am very new to BOINC, but it always seems useful to be able to follow what is going on.

If I *HAVE* to go without a build, I suppose that I can, but I don't want to give up on having a build without a good try.