I've just gotten myself through a hell of a problem, you know one of those things you don't see coming, but which utterly brings your project to a halt. My problem resulted in my rather large C++ application project creasing to compile...
I'll just take a moment to explain the problem, and solution, because I want to record it somewhere and as its past 1:10am and I've not got my notes near me, I'll just make a note here for the world and myself to read tomorrow. The problem was including boost asio.hpp after you've included windows.h results in the boost socket type header reporting a compile time error that the WinSock API has been defined, where as the boost asio systems want to use the WinSock2 types. The error is not very helpful, but the solution is simple, either go through all headers you've added before the one using asio and where ever you include windows.h you also ensure you have #define WIN32_LEAN_AND_MEAN.
Defining WIN32_LEAN_AND_MEAN results in the windows header file not automatically including Winsock.h, which in turn means later asio.hpp is able to include winsock2 without any conflicts of interest.
A neater solution, in any project using asio, is actually what I did.... Go into the compiler settings and define the WIN32_LEAN_AND_MEAN name in the preprocessor directives for the whole project you're building...
Your asio includes now work and compile, anything broken was using Winsock, or some other header excluded from Windows.h by the lean and mean setting, you can fix those yourself (*grin*).
This whole problem was very poorly understandable, certainly I consider myself very much a boost newbie, I'm not terrible with the libraries and I love them, but I find sometimes their requirements poorly documented... Indeed the boost asio library documents don't mention any conflicts with WinSock already having been included.. *sob*
The problem was also only compounded by the fact that the only thing I had added to the project was something which seemed to be wholly unrelated to asio, and utterly devoid of references to winsock. It just happened to be including windows without the LEAN and MEAN directive...
And this brings me to the problems root cause, it was not really an effect of including said new item, nor was it really a problem with how asio enforces the use of WinSock2... It was actually caused by "Working Alone Together".
The code which was brought into the project was not actually tested as part of the project beforehand, it was developed alone, with the intention of moving itself into my project locally later, and being developed alone it compiled fine, it passes its NUnit tests, it matches its design and specification... This resulted in a very dire situation my end.
If this were a few years ago (and not many) I'd have been roaring at the supplier of the new item, complaining and urging them that they'd made some fatal mistake. I'd have been ranting about how bad their work is, or how terrible they've got things working. And all of us whom work in Software know what we do when our code gets criticised, that's right we get utterly defensive, we object to being put down, and we respond by pointing to measured results - in this case I'm sure I'd have had the passed NUnit tests as an insurmountable obstacle to my getting any of my grievances addressed. Luckily I'm a little older and wiser, and I've been on the receiving end of such tirades.
Therefore I did the simple thing, I assumed I had something wrong and started to pick at the problem. Admittedly this took me two hours to unpick, but I know now what is wrong, I know what the problem is, and I can comment my co-worker that their effort has not been for naught but ask them to look at porting to WinSock2.
I can also submit to them a new specification, or rather an update to my specification, stating that WinSock2 is the minimum requirement for the system.
And because I've not ranted, and I've pointed out all the foils involved, I've documented the problem clearly enough for them, they will most likely not throw their rattle out their pram, instead they'll just look at what's wrong and take my advice as that and get on with the work.
However, if our communication, and integration points had been closer, rather than twining these two items together at the deadline hour, then... well then we'd have seen this problem earlier... And its been a harsh lesson in this internet enabled age that really we needed to have worked more closely, rather than sticking to our own ring-fenced areas of the specification alone. We spoke daily about the progress, we swapped notes on using new things as they came up, but this fundamental difference of libraries at the platform level has resulted in one almighty cock up.
A lesson learned, and a lesson to carry forward... "Don't Work Alone, when you should be working Together".
