I think as you know if you are linking against this library and you are not using dynamically linked runtime you might see weird behaviors or even crash (have no idea what's going on since it's not a coding issue). Recently I saw that if you are using MFC (for GUI) and you are using statiscally linked MFC DLL you will also see weird behavior.
What's a workaround for us to be able to integrate without issue with code that uses statically linked runtime (or MFC DLL)? If I create a DLL that uses Casablanca (thus using dynamic linking with runtime lib) and I load this DLL and use GetProcAddress of the API I want to call will this still cause any issue?
Issues:
1) licensing issues - can we distribute Microsoft runtime library freely and there are alot version of windows - that just increases testing.
2) this increases download size thus increase cost to host apps online.
3) this limit where you can use this library and how it can be used. You are effectively forcing a process to be dynamically linking the runtime libs in order to use this SDK. So for company that wants to integrate this SDK it would add an additional process in the system which is bad and then you need to use some sort of IPC so it can communicate with other processes. I mean for really simple projects you might be fine with one process doing everything but for more complex projects this is a deal breaker.
This has to be fixed as a critical bug and asap. This is a deal breaker in many instances. When will next VisualStudio be release?. I don't know if many people can wait until next year for this to support statically linked runtime library (unless there is a usable workaround).
Comments: Thanks re: _NO_PPLXIMP. As to the Blog - I had followed those instructions and still got a large number of LNK2019 errors (resolved by adding httpapi.lib to the 3 projects as I described above) but at least it pointed me in the right direction. For building the Samples, I didn't like hard-coding the path to the Binaries for Libraries Directories (ie. C:\PathToCppRESTSDK\Binaries\Win32\$(Configuration)) when using $(OutDir) works as Visual Studio already knows where it put the static library to be included, as I also indicated above. Using $(OutDir) also handles the x64 platform. Of course, once the static libraries are built and copied to the main installation (in my case the appropriate x86 or x64 & Debug and Release sub-directories of: C:\Program Files (x86)\Microsoft SDKs\Cpp REST SDK for Visual Studio 2013\SDK\lib\), then the Blog is correct for pointing a new project to the Debug and Release versions of these libraries. Lastly, I don't like its recommendation to rename the Debug DLL in order to include it. In my other projects, it is quite easy to use the Debug version (cpprest120d_2_0.lib - with a 'd') for Debug builds of a project and the Release one (cpprest120_2_0.lib - without a 'd') for the Release builds in the associate project configurations. David
What's a workaround for us to be able to integrate without issue with code that uses statically linked runtime (or MFC DLL)? If I create a DLL that uses Casablanca (thus using dynamic linking with runtime lib) and I load this DLL and use GetProcAddress of the API I want to call will this still cause any issue?
Issues:
1) licensing issues - can we distribute Microsoft runtime library freely and there are alot version of windows - that just increases testing.
2) this increases download size thus increase cost to host apps online.
3) this limit where you can use this library and how it can be used. You are effectively forcing a process to be dynamically linking the runtime libs in order to use this SDK. So for company that wants to integrate this SDK it would add an additional process in the system which is bad and then you need to use some sort of IPC so it can communicate with other processes. I mean for really simple projects you might be fine with one process doing everything but for more complex projects this is a deal breaker.
This has to be fixed as a critical bug and asap. This is a deal breaker in many instances. When will next VisualStudio be release?. I don't know if many people can wait until next year for this to support statically linked runtime library (unless there is a usable workaround).
Comments: Thanks re: _NO_PPLXIMP. As to the Blog - I had followed those instructions and still got a large number of LNK2019 errors (resolved by adding httpapi.lib to the 3 projects as I described above) but at least it pointed me in the right direction. For building the Samples, I didn't like hard-coding the path to the Binaries for Libraries Directories (ie. C:\PathToCppRESTSDK\Binaries\Win32\$(Configuration)) when using $(OutDir) works as Visual Studio already knows where it put the static library to be included, as I also indicated above. Using $(OutDir) also handles the x64 platform. Of course, once the static libraries are built and copied to the main installation (in my case the appropriate x86 or x64 & Debug and Release sub-directories of: C:\Program Files (x86)\Microsoft SDKs\Cpp REST SDK for Visual Studio 2013\SDK\lib\), then the Blog is correct for pointing a new project to the Debug and Release versions of these libraries. Lastly, I don't like its recommendation to rename the Debug DLL in order to include it. In my other projects, it is quite easy to use the Debug version (cpprest120d_2_0.lib - with a 'd') for Debug builds of a project and the Release one (cpprest120_2_0.lib - without a 'd') for the Release builds in the associate project configurations. David
