- Open the LabelLibrary solution and rename a class name. This is a sure fire way of making dependent applications break
- Don’t forget to check out the Release folder since it was checked in last.
- Rebuild both Release and Debug and Check in.
- The Build server will automatically rebuild the application on the server and label your build of the shared library.
The build server is only verifying the code compiles, tests (not shown) are run and the result is copied to the folder specified in the build definition. Remember that the dependent projects are branched from your build in the project, not the build server’s build.
- Queue a build for the App1 solution to see if it still works. The build server didn’t rebuild this one since we didn’t check it out.
- It still works!
Let’s update the App1 project with the new version of the shared library.
- Select each folder that was branched earlier and select merge from the context menu.
- Notice that the target branch is already populated with the path for the earlier branch!
- Click Next and select Label.
- Click the elipses to find the last build of the shared library.
- Click close and finish.
- Check in the changes.
- The build server will automatically detect the changes and build the application.
- Obviously it failed because we renamed the class!
Lets’ Fix It
- Open the App1 solution and fix the references to the new class name.
- Check in! We should build it locally to verify that our changes work.
- The build server automatically notices changes and attempts rebuilding it.
Now we can improve, enhance, refactor, and eliminate shared libraries independently of other dependent applications/