Compilation errors (Visual Studio 2010): pstsdknet does not compile.

Oct 29, 2012 at 11:52 AM

Hi all,


I'm new to software development and am trying get to working for me so I can use it in a project. I've downloaded boost_1_42_0, pstsdk, pstsdknet and fairport and my directory structure is as follows:






I think I've got all the needed files and that my directory structure is correct, but when I try to compile the pstsdknet solution file in Visual Studio 2010 I get a list of compilation errors. The errors given are as follows:


Could not load referenced assembly "C:\ReadpstOS\pstsdknet\trunk\\bin\Debug\pstsdk.dll". 

Metadata file 'C:\ReadpstOS\pstsdknet\trunk\\bin\Debug\pstsdk.dll' could not be found 

The project file "..\..\pstsdk.mcpp\pstsdk.mcpp.vcproj" is in the ".vcproj" file format, which MSBuild no longer supports. Please convert the project by opening it in the Visual Studio IDE or running the conversion tool, or use MSBuild 3.5 or earlier to build it.    ps

The type or namespace name 'mcpp' does not exist in the namespace 'pstsdk' (are you missing an assembly reference?)


I've tried using Visual Studio Express 2008 with SP1 installed instead to compile pstsdknet, but that also does not work and lists its own set of problems. I've been messing around for a while now, trying to follow the errors and fix them myself but I've gotten nowhere so far. I would greatly appreciate it if someone would help me out.

Thanks and sincerely,

Oct 29, 2012 at 5:26 PM


I've used VS2008, VS2010, and most recently, VS2012 to compile the project.  I know they work, but they do require a bit of configuration changes (for VS2012, it's not immediately obvious).  Based on your error message, I'm guessing that you might not be using the solution file located in pstsdknet\trunk\, or maybe you chose not to convert files, I'm not sure.

Between VS2008 and VS2010, the format for C++ projects changed, and so did the extension, from .vcproj to .vcxproj.  Based on the error message, something like this must have happened.

I suppose you also might be trying to compile it for .NET 3.5 and not .NET 4.0?  This isn't directly supported by VS2010's platform toolset.  If you want to compile a .NET 3.5 C++ dll in VS2010, I think you need to install the Windows SDK for .NET 3.5 and set the platform tool set in the general tab of the Configuration Properties for the project.

Let me know if any of the above information helps.  If not, it would be helpful to get the most amount of information possible with how you're trying to compile it, like:

  1. What is the target framework version?
  2. Are you using the solution file directly or adding the project manually to another project?
  3. Do you have SP1 installed for VS2010?
  4. What is the platform toolset assigned to for the pstsdk.mcpp project?
  5. Is there the same issue in both Debug and Release?
  6. Anything else you can think of.

I know that I need to eventually setup some nuget packages for this project, it's a fairly large inconvenience for many to compile this library themselves.  However, that requires time I don't have at the moment, since preparation is needed in setting it up and writing some other documentation.




Oct 30, 2012 at 8:46 AM
Edited Oct 30, 2012 at 8:47 AM


I'm opening the file in the /trunk directory with VS2010 and doing the conversion. In the /pstsdk.mcpp folder I have a pstsdk.mcpp.vcproj file and upon opening (just opening, not debugging or building) the file with VS2010 (and having VS2010 convert files) another pstsdk.mcpp.vcproj file as well as 2 pstsdk.mcpp.vcxproj files are generated.


Now, to answer your questions:

1. For the pstsdk project in the solution the Target Framework is 3.5

For the pstsdk.definition project the Target Framework is 2.0

For pstsdk.mcpp the Target Framework is 4.0

2. I open the file directly with VS2010

3. I have SP1 installed for VS2010.

4. The platform toolset set for pstsdk.mcpp is v100.

5. Building under release or debug both lists the same errors. Only the path of the .dll file the compiler complains about is different (but that's just the compiler saying it is trying to build the .dll, but can't do so?):


Could not load referenced assembly "C:\ReadpstOS\pstsdknet\trunk\\bin\Release\pstsdk.dll".  Caught a FileNotFoundException saying "Kan bestand of assembly C:\ReadpstOS\pstsdknet\trunk\\bin\Release\pstsdk.dll

Metadata file 'C:\ReadpstOS\pstsdknet\trunk\\bin\Release\pstsdk.dll'


With the 2 other errors also present in both cases and exactly the same.


Also, thanks for the speedy reply and assistance!

Oct 30, 2012 at 2:12 PM

I think I got it. I've finally managed to construct the pstsdk.definition.dll, pstsdk.mcpp.dll and pstsdk.dll files by building the solution in VS2010. I've added those libraries to my project and I've succesfully read in a .pst file and got its name using the pstsdk libraries as a test. I can also see pstsdk and its properties and methods in the object browser, so I should have access to the full functionality of pstsdknet now.


For future reference (in case someone else encounters this problem and finds this post) here's what I did:


Some of the project files were not targeting 4.0 .Net Framework, so I set the Target Framework to 4.0 for all the project files.

I removed a 'test' folder which was present in the Solution Explorer. There was something going wrong in there and, since I figured a 'test' folder probably isn't important anyway, removed it.


Looks like it works now. Thanks again for your time and the assist!

Oct 30, 2012 at 4:38 PM

That's what I was about to say when I saw that the mcpp project was targeting the v100 toolset.  Each version of the C++/CLI compiler can only target one framework version.  v100 targets 4.0 only, and since the others were targeting 3.5, they couldn't find the pstsdk.mcpp.dll file.  To target the 3.5 framework, the C++/CLI compiler needs to use the Windows SDK 6.1 toolset instead, which would be the same compiler that VS2008 uses.

In regards to the test folder, they are unit tests and should be important, however, they've never been good unit tests and I would honestly scrap them and start over.  I can't even recall if they still run.  There might be other sample projects that fail to build, or at least need to be upgraded to 4.0 as well, if you'd like to use them.

Glad it all worked out.