managing solutions/references

I would like to create utils class library (eg, logging, etc).

I want to use the utils solut开发者_如何学Pythonion in several indepandent applications.

I'm using source control of course...

• does that mean I should manage utils solution (holding the utils class library) and also seperate solution for each application ?

• what do I have to do to use the utils class library from ApplicationA solution

• can ApplicationA solution also include the utils solution (eg, go to definition works ?)

• if that is possible, does that mean that any change proggrammerA apply to utils library via ApplicatioA solution, also affects ApplicationB solution using the same utils class libray

• what do we to do when we fix a bug in utils solution ? how does the fix bubbles to ApplicationA and B .

It sounds like you have the possible approaches identified already:

• Develop and manage your utility library independent of any specific application.

  • Advantages: no need to manage multiple versions, updates done in one solution don't impact/break other solutions
  • Disadvantages: the Utilities assembly is essentially a closed box, a component your applications are consuming, the same as any third-party or .NET framework assembly.

• Put your Utilities library project into source control, and have the solution to each of your applications include it as a project reference (this is possible, to answer your question above).

  • Advantages: Utilities library is kept up to date in all projects, and can be stepped into during debugging, etc.
  • Disadvantages: Changes made to Utilities as part of development in one project may break it for another. Also, this may add issues with versioning, you may need to roll back changes for patch builds, etc.
• Create a new copy of the Utilities library for each project
  • Advantages: no issues with build, debug, deployment or versioning
  • Disadvantages: changes made to the Utilities in one project are not reflected in others, and must be manually copied over if needed.

At the end of the day, there is no one correct answer; it depends on the stability of your utility methods, how often they need to be changed, and how often you will want/need to debug into them.

In most cases, I find that it is more convenient to just create a new copy of the Utilities class library for each project. They end up being somewhat different eventually, but the ease of maintenance makes up for the lack of consistency across all projects. If you had a very complex set of utility classes that encapsulated some portion of your business, you would probably want to go the other way and maintain it independently.

I think you need to read up on how to distribute APIs for consumption. You should keep this as a separate project. Version it how you would something you release to the public. If you make a change in the utils and you need it in AppA, thats fine, just know that until you test with AppB you will either need to use a branch or the old version of the util class.