- RT @gblock: Auth0 Extend offsite. Our team is busy cracking away on an MVP @SalesForceDev and @auth0_extend Integration. /cc:@WadeWegner ht… 13 hours ago
- Not sure how a first day could go any better. Met the founders; met my team face to face. @auth0 was the right move. This is going to be fun 1 day ago
- RT @tjanczuk: Just a coffee break during @auth0 offsite #cancun https://t.co/WCK49vHQCw 1 day ago
- The steady flow of awesome ideas for our platform keep coming. twitter.com/auth0_extend/s… 1 day ago
- Just checked into my room in Cancun. Get to meet my whole team at @auth0_extend tomorrow. https://t.co/Sr679VPXNL 2 days 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.