Skip to main content
edited tags; edited tags
Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625
added 3 characters in body
Source Link

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and to ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and to ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

added 3 characters in body
Source Link

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by another teamdifferent teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by another team.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

First actually I don't think Git is a specific involved tool here, it can be any other Source/Version Control tool (TFS, SVN, ...). The point here is how to deal with the scenario in which I have multiple projects, each project may reference other projects but managed by different teams.

If we can include all the referenced projects in a solution, it can be easy for debugging & getting up-to-date. However currently we just add references by dll. That means the referenced projects are not referenced directly but built into dll files first and added as references to the projects that need them. This way is not very good especially when we have to commit the dll files which will make the tracked file become larger and larger (e.g: the project code could be several MBs in size but may actually end up in more than several GBs in size). That's just one of disadvantages. It can be harder when debugging and ensure that the referenced projects are up-to-date (at least to some working & stable version).

My team has thought of creating a private nuget packages source where we can publish all the referenced project dlls and they can be installed (by a specific version) into any other projects that need them. It sounds promising but I'm not so sure about how easy it can be when debugging (so that it's just like referencing the source code directly).

Could you please share some thoughts or directions to deal with this scenario of managing multiple projects? Thanks!

Source Link
Loading