Yes, I'm the primary author of LDView.
The DLL viewer that Michael is using is in the LDVLib project. If you look at LDVLib.h, you will see that it is a pure C API to LDView viewer functionality. Michael uses this API from C# using DllImport (aka Platform Invoke). It's possible that once you get LDVLib compiled as 32-bit, that simply switching to the x64 platform would allow you to do a 64-bit build, but since I haven't provided him one yet already, it's very possible that the Linker Inputs will have to be fixed for the x64 platform settings.
Adding support for snapshots would involve adding one or three new functions: one to take a snapshot to a specified path, and another to take an in-memory snapshot (with an associated memory cleanup function). The LDSnapshotTaker class (in the LDLib project) has functionality to do both things, but creating the functions with a C API in LDVLib is required in order for that functionality to be available in the DLL.
LDSnapshotTaker:
aveImage() is for file-based snapshots, and LDSnapshotTaker::grabImage() returns an array of bytes that contains the image data in raw RGB form. I'm not sure what the best thing would be to do with the raw image data. Probably load it up into an HBITMAP out parameter. Note that most likely you would then need a separate function that frees up the memory used by whatever data format you choose to return to .Net. I would suggest implementing the file-base snapshot first, because it would be quite easy to then test from .Net, using .Net itself to load the file after it's created. That's not efficient, but once it's working, switching to purely in-memory should be relatively straightforward on the .Net side, while doing the actual in-memory snapshot implementation on the LDVLib side probably won't be trivial.
Send me an email to the LDView email address, and I'll try to give you instructions on getting LDView to compile in the first place. Note that I've never tried to compile it in VS 2012, but I don't see any particular reason why it wouldn't work fine. IIRC, I've compiled using the free VC++ 2010.
The DLL viewer that Michael is using is in the LDVLib project. If you look at LDVLib.h, you will see that it is a pure C API to LDView viewer functionality. Michael uses this API from C# using DllImport (aka Platform Invoke). It's possible that once you get LDVLib compiled as 32-bit, that simply switching to the x64 platform would allow you to do a 64-bit build, but since I haven't provided him one yet already, it's very possible that the Linker Inputs will have to be fixed for the x64 platform settings.
Adding support for snapshots would involve adding one or three new functions: one to take a snapshot to a specified path, and another to take an in-memory snapshot (with an associated memory cleanup function). The LDSnapshotTaker class (in the LDLib project) has functionality to do both things, but creating the functions with a C API in LDVLib is required in order for that functionality to be available in the DLL.
LDSnapshotTaker:
aveImage() is for file-based snapshots, and LDSnapshotTaker::grabImage() returns an array of bytes that contains the image data in raw RGB form. I'm not sure what the best thing would be to do with the raw image data. Probably load it up into an HBITMAP out parameter. Note that most likely you would then need a separate function that frees up the memory used by whatever data format you choose to return to .Net. I would suggest implementing the file-base snapshot first, because it would be quite easy to then test from .Net, using .Net itself to load the file after it's created. That's not efficient, but once it's working, switching to purely in-memory should be relatively straightforward on the .Net side, while doing the actual in-memory snapshot implementation on the LDVLib side probably won't be trivial.Send me an email to the LDView email address, and I'll try to give you instructions on getting LDView to compile in the first place. Note that I've never tried to compile it in VS 2012, but I don't see any particular reason why it wouldn't work fine. IIRC, I've compiled using the free VC++ 2010.