This project is read-only.

Changing the path used for locating assemby Info files

Oct 9, 2012 at 10:03 AM

Does the template property 'AssemblyInfo File Pattern' support the ability to change the path to use when locating the relevant files? At the moment it successfully finds all these files located at or below the solution file. However, we have some projects which are shared between solutions and the assembly info files in the those projects are not being updated by the build because they are at the same level as the solutions.

Is it possible to use a relative path instead of just, for example, "AssemblyInfo.*"

  • Solution A
    • Project 1 Assembly Info file - UPDATED OK
    • Project 2 Assembly Info file - UPDATED OK
  • Shared Project 3
    • Project 3 Assembly Info file - NOT UPDATED


Jan 23, 2013 at 2:53 PM

TfsVersioning searches the solution path intentionally because of the possibility that the workspace downloaded during the build could be much larger (either intentionally or by accident) and files could be modified and checked in (that really shouldn't be) and therefore non-target applications could be changed. 

Sharing project code across solutions is, in general (I obviously don't know all of your requirements) a less than ideal approach.  TFS doesn't support shared files/folders like its predecessor (VSS) because of the issues surrounding it.  Yes, you can point a solution file anywhere you want but I would argue that you shouldn't.  I am working with a client that is using this very approach.  Because of it they can't branch their code unless someone goes into the solution file and manually modifies the folder pointing to the "shared" project.  I also argued that if it is truly shared then it should be called a framework assembly and managed and versioned as its own entity.  It then just becomes a dependency of the main projects.  Developers are then restricted from being able to make code changes that help one solution and break another.

All this to say no, TfsVersioning does not support the use of relative paths for AssemblyInfo but also that I do believe that it really shouldn't.


Feb 1, 2013 at 4:11 PM
Edited Feb 1, 2013 at 4:14 PM

I have the same issue with the search path for assemblies (Im using V.2 under TFS 2012).

The solution files we use are isolated in a different folder than the source projects files.

I think it could be useful simply to 'permit' modification of a "MainAssembliesPath" or something like that.

Sometimes, companies have their TFS structures that have their reasons for not merging their Solution files with the Project sources.
For example, our Build server uses its own Solution files which are separated from the main "Sources" section.


...............Solutions (Build Server Solutions)

So the Build Server keeps them away from the "Sources" section that is heavily used and modified by the Dev Team.
Those (Build Server Solutions) solution files need to stay unmodified in order not to crash NightBuilds and other Admin Builds.

If I cannot change or get access to a search path, i will probably need to "temporarily" copy all my project's assemblies under the "Solutions" folder just before the versioning tool makes its stuff, then copy back those assemblies over my "Sources" section immediatly after the "VersionAssemblyInfoFiles" activity in the Xaml Template.

Feb 2, 2013 at 7:39 PM
Hey Serge,

Aside from the "belief issues" that I pontificated on in my previous reply, I've thought about starting down that path and I would likely have to overcome additional situations. In your case, you have a solutions folder as a peer to the Sources folder so it is relatively local and there's only one. However, a solution file can be configured to point every project at its own individual folder. So, the "MainAssembliesPath" approach may not be complete - it may need to allow for multiple paths. Then, getting a list of folders into a single string property in the build def may be awkward and error prone.

I only describe it this way because there may be more to solving the issue than simply adding another property and it would need to be thought through more.

In your case, a simple alternative to creating multiple folders for solutions would be to leave them in the Sources folder. Since you don't want them modifiable I would do the same thing as I do on projects with multiple devs where you want to make sure they don't modify the solution that you're working on. I create a separate TFS workspace solely for the purpose of locking files that I don't want people messing with. Being in a separate workspace means that the files will show as locked in my (and everyone else's) main workspace but it will never appear in pending changes or when I check in files so they never get inadvertently unlocked. I leave it locked until there's a reason to change and if a dev needs to add a project then he/she needs to clear it with me first before I allow it.

Locking in this manner would give you the security that you described so that no dev accidentally (or on purpose) changes the solution and breaks a build. Also, unless you added security on the Solutions folder, this approach is more secure than yours since the files can't be changed without unlocking them by the person who locked them. Your build definitions would be slightly simpler as you wouldn't have to list multiple folders to download for the build - unless you are pointing the build def at the parent folder in which case this approach would allow you to point at the Sources folder directly and your builds would be faster as less files would be downloaded for each build.

Things to think about,