- Nice I love D3! gag.gl/eK0juj 6 hours ago
- RT @blackgirltech: If you're a Black woman & want to learn how to code but need some financial help, you should apply for the https://t.co/… 18 hours ago
- Louie is growing so fast! https://t.co/hfvOqScGp3 20 hours ago
- RT @vibronet: Open standards should be table stakes for everyone - but won’t be enough to save you from vendor lock-in https://t.co/TbMebtG… 1 day ago
- RT @eugenio_pace: Find out why @auth0’s @vibronet says open standards alone in identity !== vendor lock-in. via @auth0 https://t.co/sRg86Rx… 1 day ago
Web Deployment Projects & Team Build
April 25, 2008Posted by on
Over the course of the last week or so I have been working on migrating our source code over to TFS. In the process, I am reformulating our solutions, cleaning up garbage and creating automated build scripts.
Our application has five website projects and a hand full of supporting libraries. Using the Web Deployment Project addon, I was able to automate the build of these sites into a clean reproducible deployment.
My application is set up in source code in such a way that frameworks are separated from the actual application code. From the Main branch I have a Framework folder and an Application folder. The Framework folder contains the source code for the Enterprise Library Application Blocks, a vendor supplied library and a Lib folder for interop assemblies and various other compiled resources.
The Frameworks branch has its own build script. The idea is a developer opens up TFS finds the latest successful build of the framework and copies those assemblies to his local machine @ D:\Common. The goal being we are all using the same build of the framework libs and the developer doesn’t need to worry about the source for frameworks unless a bug is identified. All applications that use framework assemblies have references set to the common folder.
After successfully migrating our web application over to TFS and getting the build working successfully, I moved on to migrating the applications windows services. These services are in their own solution and I plan to locate them into the application folder in TFS.
While reviewing the windows services solution, I noticed several applications that use messaging libraries that live in the web application solution. I decided to pull these two libraries out into their own solution and add them to the Framework build.
This is where the problems started. I was able to pull the libraries out and add them to the Framework build, but now any website project that references these libraries fails to build on the build server. The solution builds fine locally as I have *.refresh files that point to the Common folder.
Trolling through the BuildLog.txt it is pretty obvious why my build is failing. Target _ResolveReferences which is defined in Microsoft.WebDeployment.targets installed by the Web Deployment Project addon is not able to locate my two messaging assemblies.
My master build script has an AdditionalReferencePath defined, but the Web Deployment project targets seem to ignore this. I have attempted to copy the assemblies to the proper location at various points in the process (AfterGet, BeforeBuild) and have not had success. The libraries are in the proper place but because they reference other assemblies that need to be resolved the build fails.
I need to modify my build script so that it copies the libraries to the correct location and then resolves all references prior to build. This is my task for the day.