If I build a Win32 Application in vs 2005 or 2008 it has no dependencies correct?
-
Hey Guys, I have always used MFC, but now that I have upgraded to visual studio 2005 and 2008 I am forced to use MSI installers due to the depencies on the new merge modules. I really don't like the msi installer I think it's horrible and I would rather use inno setup or the old wise installer. I just want to be sure.... If I was to start writing all my code in a pure Win32 Application from vs 2005 or 2008 I would no longer require the vcredist files in order to run my applications correct? Thanks, Greg
-
Hey Guys, I have always used MFC, but now that I have upgraded to visual studio 2005 and 2008 I am forced to use MSI installers due to the depencies on the new merge modules. I really don't like the msi installer I think it's horrible and I would rather use inno setup or the old wise installer. I just want to be sure.... If I was to start writing all my code in a pure Win32 Application from vs 2005 or 2008 I would no longer require the vcredist files in order to run my applications correct? Thanks, Greg
Your application will still depend on CRT DLL's. You don't necessarily have to use MSI or other installers. You can always deploy you application using private assemblies. Read this article http://www.codeproject.com/KB/cpp/vcredists_x86.aspx[^], for more details. There is a section on "Install a private assembly". -Saurabh
-
Your application will still depend on CRT DLL's. You don't necessarily have to use MSI or other installers. You can always deploy you application using private assemblies. Read this article http://www.codeproject.com/KB/cpp/vcredists_x86.aspx[^], for more details. There is a section on "Install a private assembly". -Saurabh
Thank you very much! :)
-
Thank you very much! :)
You are welcome. -Saurabh
-
Your application will still depend on CRT DLL's. You don't necessarily have to use MSI or other installers. You can always deploy you application using private assemblies. Read this article http://www.codeproject.com/KB/cpp/vcredists_x86.aspx[^], for more details. There is a section on "Install a private assembly". -Saurabh
You may also link with static
CRTlibrary. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
You may also link with static
CRTlibrary. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]I generally don't advise doing that since in long run it might create very obscure bugs. If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources. -Saurabh
-
I generally don't advise doing that since in long run it might create very obscure bugs. If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources. -Saurabh
Saurabh.Garg wrote:
If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources.
Well, the above is not, IMHO, an obscure bug. Statically linking the
CRTramain a valid option, IMHO. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Saurabh.Garg wrote:
If you link application with static CRT and later on use a library which was linked dynamically with CRT then it might create all sorts of problems from multiple defined symbols during linking to incorrect handling of resources.
Well, the above is not, IMHO, an obscure bug. Statically linking the
CRTramain a valid option, IMHO. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Linking with static CRT is definitely a valid option. I call such bugs obscure because sometimes a 3rd party library can be added long after choosing to link with static CRT and suddenly a working application might start crashing. -Saurabh
