Managing Larger Visual Studio Projects
-
We have probably all developed those Visual Studio applications which rely on additional DLLs and static libraries containing our favorite snippets of code. My question is how best to manage this kind of project which is not all neatly contained in the project folder. If we add our library paths (elsewhere on the disk) to the project then we can be sure that we are linking with the latest versions of the libraries but archiving this arrangement is a nightmare. Another alternative might be to copy all the libs to a 'lib' folder within the application that we are developing. This would provide a self-contained project which could easily be archived but we may not be using the latest version of our libs. I would be very interested to hear what other developers do. Is there a better way! :confused: Thanks Tony
-
We have probably all developed those Visual Studio applications which rely on additional DLLs and static libraries containing our favorite snippets of code. My question is how best to manage this kind of project which is not all neatly contained in the project folder. If we add our library paths (elsewhere on the disk) to the project then we can be sure that we are linking with the latest versions of the libraries but archiving this arrangement is a nightmare. Another alternative might be to copy all the libs to a 'lib' folder within the application that we are developing. This would provide a self-contained project which could easily be archived but we may not be using the latest version of our libs. I would be very interested to hear what other developers do. Is there a better way! :confused: Thanks Tony
If you really have that much 3rd party (external) libraries you may consider creating self-hosted NuGet packages... http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds[^]
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
We have probably all developed those Visual Studio applications which rely on additional DLLs and static libraries containing our favorite snippets of code. My question is how best to manage this kind of project which is not all neatly contained in the project folder. If we add our library paths (elsewhere on the disk) to the project then we can be sure that we are linking with the latest versions of the libraries but archiving this arrangement is a nightmare. Another alternative might be to copy all the libs to a 'lib' folder within the application that we are developing. This would provide a self-contained project which could easily be archived but we may not be using the latest version of our libs. I would be very interested to hear what other developers do. Is there a better way! :confused: Thanks Tony
softwaremonkey wrote:
but we may not be using the latest version of our libs.
However you will in fact be using the same one in development, QA and production. And be more likely to label it in source control so you can keep track of it. Thus if a problem occurs in QA or production then you are more likely to be able to reproduce it. And when you do update to new versions as part of a development and business decision then development and QA can more fully verity that it continues to work as expected.
-
softwaremonkey wrote:
but we may not be using the latest version of our libs.
However you will in fact be using the same one in development, QA and production. And be more likely to label it in source control so you can keep track of it. Thus if a problem occurs in QA or production then you are more likely to be able to reproduce it. And when you do update to new versions as part of a development and business decision then development and QA can more fully verity that it continues to work as expected.
Thanks, that is a very good point and a compelling reason to 'ring fence' every file needed to build a particular version of an application including the libraries. :thumbsup::thumbsup:
-
Thanks, that is a very good point and a compelling reason to 'ring fence' every file needed to build a particular version of an application including the libraries. :thumbsup::thumbsup:
