views:

208

answers:

2

Situation

I have about 400 csproj files using project references. About 3 of those a separate team wants to fork and incorporate into a standalone app.

I branched the 3 projects of interest, and because the separate team uses a diff SVN repo I used svn externals to pull in these projects into the folder of the standalone app. Obviously since this team uses a different folder structure the project references no longer resolve.

Attempted Solution

I figured setting the msbuild properties ReferencePath and AdditionalLibPaths to point to a directory with all the precompiled dependencies would allow the project references a fallback point and resolve correctly. However that doesn't appear to be the case.

Question

  • Does anybody know a way to have a failed projectreference look up resolve to the precompiled dll?
  • Perhaps point me to an automated tool to convert projectreferences to dll references?
  • Or is there a better way to solve this problem?

Thanks

A: 

Project Files (csproj) are XML Files,you can write your own tool if you require to make any manipulations:

abmv
A: 

Project references are resolved by the target - ResolveProjectReferences. It basically calls GetTargetPath on the referenced project and uses that as the resolved project assembly path. IIUC, your project file path is not correct in the new setup, so GetTargetPath would fail.

You could solve this in many ways like have a target [1] which maps the old project file paths to the resolved assembly paths, and adds it to FooItem [2]. Or you could just add all the files from the directory with "all precompiled deps" to @(ReferencePath). ReferencePath is populated after the resolution, so it has all the final paths. Adding a search path to it won't help.

  1. And add this target to the ResolveReferencesDependsOn property

  2. The GetTargetPath call should be adding the returned paths to some item name, replace FooItem by that item name.

Ankit