I moved a team project collection to a new server. Everything is fine in Visual Studio and the web site, but the build is trying to retrieve source code form the old server.
In the build definition I see no place to set the collection URI. There is a System.TeamFoundationCollectionUri variable but it's read only, trying to set it in Variables causes an An item with the same key has already been added. error on build.
Trying to add a new mapping in Repository works so the (web/app) server is aware that the source code moved, but the old location seems to be left somewhere in the build definition.
Is there any way to fix that? Without re-creating all build definitions I mean.
There is nothing visible in the web interface, but you can see the server name in the TFS SQL database. The column Repository is a nvarchar(MAX) containing all the mappings and the server name.
I fixed the server name with a replace in SQL and it works now.
Related
I created a project with visual studio 2017 and I want to add it to team foundation server but I get this error :
Failed To create Mapping
The mapping for $/sampleProject conflict with one of its parent's mapping
I was thinking it's because of duplicated name but I checked my team foundation server, there is not any project with this name.
please help, thank you
According to the error info, the cause of this issue maybe:
When you tried to map the parent local directory to a server subdirectory, it failed as the immediate child was mapped to the server root.
If you map each project to a different local directory, may get confused with how the server mappings and client mappings sync. To get around this, you could simply map the base server directory to a single client directory and let TFS match them up; for example:
c:\Dev\Workspace <--> $/
When you do a get latest or check in for your TFS repository, TFS will simply create any necessary directories; for example:
c:\Dev\Workspace \sampleProject\
Besides, also make sure DefaultCollection must be mapped first to you local path.
For details check this answer.
Another method is back up your project and delete it, then create a new one, make sure the locations you have selected is under your current local workspace, also check "Add to Source Control".
If above is still not working, delete your old workspace (back up first), then create a new one, repeat above step, which should do the trick.
In db projects, when you add a database dac-pac for example as a reference use in a view to reference a third party database, that seems to be valid only for your local copy.
In VS 2015 I can;t seem to find how you add that as a build so that it syncs and compares with the version you store in source control.
If I check out a team project, create a view referencing a third party DB, create a dac-pac for that DB, add it as a database reference, save, build, check in, by default that reference isn't checked in to the server for another developer to check out in the latest version and therefor they will get reference errors.
Does anyone know how to sync these? I can't find an option to do so!
Also, it would be nice to be able to edit the dam things, For example if they are on a different server you must define that. But say the server changes, you can only edit it in your publish profile, however if you do that but someone else doesn't it will flag as a change for them.
You'd better add the .dacpac file to TFS version control. When others check out from other machines, get down the .dacpac file together with that db project.
Make sure that when other check out that file and the db project to their local machine, the relative path between them are same with that in your environment. Actually, in the .sqlproj file of your db project, it has defined the relationship.
For example, I put the .dacpac file under a folder named "DACPAC" and this folder is at the same level of my solution folder.
In the .sqlproj file:
<ArtifactReference Include="..\..\DACPAC\TestDB.dacpac">
<HintPath>..\..\DACPAC\TestDB.dacpac</HintPath>
......
</ArtifactReference>
Note: The "..\" mean go to the uplevel path from where the .sqlproj at. It has 2 "..\", so go 2 uplevels.
Currently, my build process template has some redundant arguments that I want to remove:
I open this template in visual studio and remove the argument from the list:
Then, I check in modified template to TFS and refresh the build process template. But it seems nothing happen, redundant arguments is still there. I think it is because of some kind of cache. I try to restart visual studio and recreate build definition, but it not work.
I found a post say that we need to delete this build process template in tfs database: here is it . But I do not have permission to do this for now. Is there any other way I can do to clear the cache?
For your situation:
First double check your template xxx .xaml in TFS server to make
sure this arguments has been deleted and check in the server.
Try to delete TFS cache by going into default C:\ {User Profile Folder}\AppData\Local\Microsoft\Team Foundation\x.0\Cache and VS cache in appdata folder.
Also try to delete the arguments in metadata Property as below. More detail from MSDN:
If it still doesn't work and you don't have the permission to TFS database. The final workaround, just create a new template with the same setting to your template without this redundant arguments.
We are currently setting up Team Build 2010 for our company, and I am trying to use workflow activities to retrieve the exact local path to the current solution being built. I haven't found a way to get this value, does anybody know how (without writing a custom activity)?
Either one of server or local path would suffice (i.e $/TeamProject/Branch/OurProject or C:\TeamBuild\src\path\to\branch\OurProject) since we can use the conversion activities on the server item.
The reason we need this path is for updating version info files, and that needs to be done for only the current solution being built, and the files have the same names (AssemblyInfo.cs, for example).
In this similar question, the solution is to define a parameter, but since this information is particular to the solution being built and not some external path, we were hoping that this info would retrievable.
You can retrieve this particular info without adding anything. If you navigate within your Build Process Template to the position where MSBuild breaks out, you will see that the solution that shall be build is set as a string named localProject. This will contain the local path where TFS has downloaded your SLN, something like C:\TeamBuild\src\path\to\branch\OurProject\OurProject.sln.Open the XAML and navigate to:
Run On Agent
Try Compile, Test, and Associate Changesets and Work Items
Compile, Test, and Associate Changesets and Work Items
Try Compile and Test
Compile and Test
For Each Configuration in BuildSettings.PlatformConfigurations
Compile and Test for Configuration
If BuildSettings.HasProjectsToBuild
For Each Project in BuildSettings.ProjectsToBuild
Try to Compile the Project
Compile the Project
Run MSBuild for Project
if you select Run MSBuild for Project & hit F4 you see it.
In order to retrieve what you are after you can define another string-variable solutionPath in your Build Process Template & insert under the Run MSBuild for Project a new Assign activity withTo : solutionPath andValue : Path.GetDirectoryName(localProject)
Have you looked at the TFS Community Build Extensions, they give you a assembly versioning out of the box?
You can use the variable called SourcesDirectory to get the current Source Directory on the Build Server. You can also use an ConvertWorkspaceItem activity to convert between server and local paths.
There's also a blog post that cover's all of this here.
UPDATED entire question to clarify things.
Software
Team Foundation Server 2010.
Background
Some while ago we migrated our Team Project Collection (= TPC) using Microsoft Team Foundation Server Integration Tools to a new TPC. We wanted to keep our build definitions as well, so we created a new build controller for the new TPC and then manually migrated the build definitions since the tool didn't support that functionality. Once we recreated the build controller, the BuildID was reset. This behavior is understandable since each TPC has its own database where the unique BuildIDs are generated.
The problem is that our assembly versioning scheme uses the BuildID to make sure we can trace an assembly to the related build from TFS. This is why continuing the old BuildIDs (or manually configuring the next BuildID) is essential.
The question
Question is if there’s a setting by which we can define the range of the BuildID so that there’s no overlap with previous builds made by the deprecated Build Controller. For example, if in the old TPC, the last build was ‘499’, then we would like to set the range of the BuildID in the new TPC to [500-99999]".
There are two ways you can solve this problem. The simplest one would be to modify the build workflow, and add an offset to the build id. You can expose the offset as an argument and add it to the metadata, so that it can be modified externally, or you could make it a fixed constant inside the XAML.
A more intrusive solution would be to modify the database directly. In the project collection's database (e.g. Tfs_DefaultCollection), go to the tbl_Build table. The table's primary key is the BuildId. It is an Identity field. All you need to do is change the seed to a new value (e.g. 500); The next build will have the modified build id.
I tried this on my own database, with no observable problems. I suggest you back up your TPC before trying it, just to be safe.
And suggest you simply modify the build to take an offset to the build id.
Hope this helps,
Assaf.