I am aware that Team Foundation Server Source Control does not support the shared file (link) concept of Visual Source Safe.
I currently have a scenario where we link an AssemblyVersion.cs file across multiple projects. This means that in our MSBuild script, we can update the version in one file and have it propagate throughout the projects.
How would I accomplish this with Team Foundation Server Source Control?
My first thought is to create the file in a central location and have each project include that specific file in that specific location (instead of copying it to the local source directory)...
I don't know if you can embed the AssemblyInfo.cs as a link file.
But look here, looks like it works:
In our Teambuild, we have a task which updates the AssemblyFileVersion and other attributes.
We use this Task
Edit:
Actually it works with a multi solution architecture with round about 29 projects and
on TFS 2005 and 2008.
I personally like the second solution cause you don't need to change all projects,
only need to implement in daily/nightly build.
Related
We currently use TFS 2010 for controlling some of our .NET projects.
I'd like to know whether it's possible to provide some kind of versioning within TFS for a specific folder on a network share for example.
The idea being is to control release packages (zips) for every release we do. As this bit is done by some other person (not technical and he doesn't use Visual Studio or any tech tool), it'd be great to streamline the process of versioning the zip files for every release.
Technically speaking:
We've setup this folder \servername\releasezips and every time I drop a file named release.zip, it would automatically commit (push) this file to the TFS server (no comments needed) and furthermore, once the file contents change (meaning that someone dropped another version of the file in there), the system would again push the file to TFS, but with a following version.
Is this possible somehow? I've seen somewhere that I could programatically have some extra control over TFS, using REST API.
Thanks in advance!
Thanks for your tips, Daniel and PatrickLu-MSFT.
As I said, I did want something straighforward, some kind of control similar to what box.com provides, where you associate a local folder on your machine with the cloud. So, once you drop files in the local folder, the small box client synchronizes it along with the cloud. If access the box.com, I can see the different versions of that specific file.
So what I did was, I've created a small .NET app to monitor the folder and any new files dropped in there would get checked in to our TFS server, by using the tf command line (of course ignoring work items or comments).
So, progamatically within the .NET app, it builds up the tf required commands for processing and versioning the recently dropped files and therefore, executes them.
By the way, I could have used the Team Foundation API in order to do the same job, but it would demand way more effort.
Cheers
According to your description, you want to commit/check in files during the build/release pipeline.
It's not a recommend way to check-in generated build files and modify source code during a build pipeline. If you really want to do this, you could edit the build workspace files and use tf commands in custom activity and call the powershell eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
For version the dropped files, you could take a look this similar question: TFS Build Copy to Versioned Folder
Basically, you have to customize build definition with custom activity and based on build.buildnumber variable to generate/create .zip file.
I have a small C# console program which uses the AddItem() method of Microsoft.Build.Evaluation.Project to add several language .resx files to all the Projects in several Solutions. This is working fine.
The issue is, those changes do not appear as pending changes in source control. I would like to see the .csproj files marked as pending change and the new .resx as pending adds. What APIs should be used to do this? I found the SccAdd() native API (https://learn.microsoft.com/en-us/visualstudio/extensibility/sccadd-function) but it looks like something that would need to be called by the IDE, not from my command line utility.
Environment: The c# console program is VS2015. The projects it is modifying are VS2008 Compact Framework 3.5. The current Source Control system is TFS 2015.
You could use TFS API to pend changes in a workspace then check in files to TFS. Use the Workspace.PendAdd method queues files or a folder for addition to the version-control repository. Either create a temporarily workspace or use the one your project file located.
Here is a detail example of using the TFS API to add pending changes, checkin code. You could aslo take a look at this question: Calls to `Workspace.PendAdd` not adding items
I have a core project and several sub projects. I link to files in the core project for the sub ones. I righted clicked my csproj and said existing file > add > link. Here is how my project looks:
Here is a picture of my Windows Explorer:
When I check in, I receive this error:
Could not find file C:\Users\joe_a84\Documents\JMASoftware\QuickBooks\Main\Source\Platform Support\NOP\Source\Versions\nop265\Nop265\Module\QuickBooksSettings.cs
The file does not exist there because it is linked. How can I tell TFS that it's a linked file?
There is the following question which states that symbolic links are not supported in TFS 2008 or TFS 2010. Symbolic links in TFS 2010 Source Control?
However, I did find the following ancient blog post which seems to show how to do it for TFS 2005: http://blogs.msdn.com/b/ericlee/archive/2006/07/20/sharing-files-in-team-foundation-server.aspx
That said I would highly recommend that you simply don't do this.
If you really need to share a file between projects then you should be using the branching functionality built into TFS. Typically you don't want just a single code file due to namespace and assembly generation concerns. It is much cleaner, and certainly easier to maintain, by having a separate project for those artifacts that are passed around. This way you either branch the entire assembly project; or just refer to it in it's normal place.
This is a local file level linking by another project. There is only one file at a specific subfolder. Other projects can link to the file via this approach. The problem with this approach is that from TFS viewpoint, you cannot tell if a file is shared by other projects. A good practice will be to keep such files in separate folder with name like Common or Shared etc.
People who have been using File linking across branches in Source Control would have to change their approach quite differently.
Linking between files in TFS is pretty simple. You just open the "Add existing item" dialog and search for the file you want to link in your local workspace. If you would click "Add" now Visual Studio would create a copy of the file in your projects directory. What you do instead is to choose the other option (you have a little drop down menu on the button) and add the item as a link. Thats it.
I faced the same problem. I just did undo on the file which was showing this error in the TFS Pending Changes window and checked-in. This undo did not remove the link that was added in the project. Make sure you do not undo the project file.
I need to add some source code to TFS and having never used it before i would like to get some advice on the best way to structure it.
I have one solution 'GenericLibraries'. This is a set of class library projects which could be used by any application within the business.
I have 2 other solutions 'FormsApp1', 'FormsApp2'. Both of these solutions contain dll references
to the libraries compiled in the 'GenericLibraries' solution.
My question is how to best place this source code into TFS?
Does all the source code have to be placed into one TFS project because 'FormsApp1' and 'FormsApp2' contain references to assemblies in 'GenericLibraries' OR can i have 3 TFS projects? Or is there another standard way of doing this?
Ultimately i would like to have Continuous integration set up too, and both 'FormsApp1' , and 'FoprmsApp2' would always compile against the latest version of the assemblies in 'GenericLibraries'.
This is a single TFS Team Project, with a common library. Consider the following structure:
$/MyTeamProject/Dev/GenericLibraries
$/MyTeamProject/Dev/MyProduct/FormsApp1
$/MyTeamProject/Dev/MyProduct/FormsApp2
When using TFS with a tool outside of Visual Studio (Specifially ORMS), modifications to the project file to include a new file will not cause the file to be added to source control.
Does anything exist that could potentially say "Warning: You are about to check in change to a project file which include a file which is not versioned"
In addition to Martin's answer, the latest release of TFS Power Toys includes:
"Windows Shell Extension (NEW!)
Allows core version control operations within Windows Explorer without using Team Explorer."
So you may just be able to commit those new files without having to fire up Team Explorer or use an MSSCCI compliant source control client.
Not quite, however you might want to download the TFS Power Tools and check out the command line utility tfpt.exe.
The "tfpt online" and "tfpt treeclean" might be most useful to you when working outside of an integrated TFS client. tfpt online will look for files in your local directory that are not under version control, treeclean will show you files in your local directory that are not under version control so that you can remove then if they are not required.
Good luck,
Martin.
One gotcha I've found using tfpt online is that it doesn't always pick up changes unless you use the /diff switch. That one caused us all kinds of headaches with our automated build until I realised what was happening!