I've started an open source MVC4 project that is using some other open source project as a dependency. I've forked the other project and will be modifying it according to my needs. The problem I'm facing is how to keep these projects depending on each other, but maintained separately. Yet people who git pull my project, would get the dependency project as well?
How do you organise your code in this case?
Usually I use nuget for all my dependencies. When I fork a project I will deploy it on nuget and also on symbol source . In this way you can step inside the dependency source without problems.
For more information on symbol source and nuget see also: Creating and Publishing a Symbol Package . To enable symbol source debug see http://www.symbolsource.org/Public/Home/VisualStudio .
You must also remember to enable Nuget package restore .
With this solution you can't modify source code but at least you can debug it.
I use something similar in concept to CMake, but entirely within Visual Studio. There's the relatively unknown feature of property files, which can be included by solutions. This allows you to create a file containing only paths to dependencies, include the libraries you can and set relative paths, and then require people to set the appropriate paths for the other dependencies you can't/don't want to include.
With a little bit of work, it comes out fairly clean, and is super easy to automate through TeamCity and other similar tools (each build agent can set the variables to indicate where it keeps dependencies).
For small dependencies and ones that have been tweaked to work with my project, I keep an archive or the loose files in the repository, and use the properties file to reference those. Others have instructions on where to find them and how to edit the paths.
If you're interested in such an approach, I can go into some more detail. It took a bit of work to figure out, as property files aren't super well documented, but is working pretty neatly.
In case you are not creating circular dependencies , following is an idea:
add a new Class Library
project with a unique name, say ClassLibrary1
, to the solution
in the Build
page of its project settings, config Output path
to application output path
in the Build Events
page, add the following line to Post-build event command line
block:
del "$(TargetPath)"
repeat step 1 to 3 but giving another name, say ClassLibrary2
, and config Output path
to the source path of ClassLibrary1
set Project Dependancies
of ClassLibrary1
, check on ClassLibrary2
add all other project as project reference to ClassLibrary2
, leave Copy Local
with default value true
build ClassLibrary2
once, and all DLLs now are in the source path of ClassLibrary1
add them to references of ClassLibrary1
and leave Copy Local
with default value true
set Project Dependancies
of application and all other projects which are not cause circular dependencies , check on ClassLibrary1
add references of other projects, from the path the DLLs were put in ClassLibrary1
set Copy Local
of all these added DLLs in other projects to false
Thus, the project ClassLibrary1
be a central control of the external libraries of your solution. Each time you Rebuild Solution
(or just build the application), ClassLibrary1
copies the latest DLLs add to its references to the application output folder, and deletes the DLL it generated itself named ClassLibrary1.DLL
. The application and dependencies at either compile time or runtime would use the same version of DLLs, you don't need to do extra deploying or check each deployments.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.