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: Hi fruler, In the our next release, 2.4.0, and in the 'development' branch now, we are now statically linking with OpenSSL (the dlls you are mentioning). With this you shouldn't have to work about those. Steve
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: Hi fruler, In the our next release, 2.4.0, and in the 'development' branch now, we are now statically linking with OpenSSL (the dlls you are mentioning). With this you shouldn't have to work about those. Steve