I have a multi-project solution being stored in TFS.
Each project has separate Debug/Release build configuration folder specified.
The main project's bin folder is "included" in source control because it contains some third party DLLs that are included in the repository.
Each reference is a "project" reference type as per MS/TFS best practices.
Every time I build the solution, VS/TFS copies all of the built dependencies for the main project into both the build configuration folder (debug/release), and the root bin folder. When the file appear in the root bin folder, they get added to source control (or if they were already there due to this same issue, checked out)
For now, I have removed the bin folder from source control, but this is less than ideal, because now each developer must maintain the local DLLs, rather than just getting them from source control.
My ideal solution would be to just use SVN instead of TFS, but I'm locked into this one.
What's the best practice in this scenario?
If you want to include binaries in your source control (and some people would burn you at the stake for doing so) I would do the following:
Create a "Binaries" folder inside the project
Copy the dependencies in there
Add references to those DLLS in that location
The project file will then contain relative paths to them, so you can safely include that directory in source control and have it work for all devs, without having to add your "bin" directory to source control.
After using the solution outlined in the above answer and comment, I've found that for some reason, one of the DLLs is not being copied to the bin folder when the solution is built. (Copy local is set to true for the reference.) The DLL is copied into the build configuration folder, but not the main bin folder. It is used in the application, so dependency checking should pick it up. As it is now, a runtime error occurs whenever code attempts to access this component (as would be expected with a missing DLL.
Any ideas?
Related
I always understood that best practice was never to check into TFS binary (e.g., bin and obj) files.
A while ago, someone in our implementation of TFS did not adhere to this, and checked in the bin and obj folders.
Thereafter, when I try to GLV code to a new machine, TFS downloaded all the project folders including items such as bin, obj, Debug etc and temp files like .dll, .cache, pdb. Then, when I run Clean Solution, TFS removes such files inside these folders, but then, when I Build, I get errors that there are dll files missing in obj\Debug folder.
To fix this, I then took the following steps:
I undid current changes so that TFS had nothing checked out.
I deleted the bin and obj folders from Source Control Explorer within TFS.
I checked it.
Such folders seemed to disappear from TFS, and I thought the problem was solved.
However, after that, when I GLV on the same machine, then Clean, then Build, then check-in recursively from the root of the TFS workspace, TFS automatically adds the dll’s and other extension like .cache files in those folders back into TFS! And we are back to square one.
So, should I try to prevent such files being checked in, or is there a way for all those files to be stored inside TFS without then causing me compilation errors??
Also, if best practice is to avoid checking in the bin and obj folders, how to I check in recursively from my local drive, after building, without checking in the bin and obj folders? Is there a way to exclude certain folder or file types?
Add a .tfignore file to the repo root so that those folders are not tracked by source control.
bin
obj
should be enough.
I am working on configuring a XAML build definition for a .net solution (of another company) stored in TFS2015.
The solution uses Dll references from a software X, installed on the developers computers, but not present in the Build server. (FTS and Build servers are shared among many clients).
I have option to add the required Dlls in a folder along with the source code, but I do not have option to modify the .csproj files.
In the Build definition, I tried to add the following in the MSBuild arguments field :
/p:AdditionalLibPaths=$/[long tfs path here]/CommonDlls
/p:AdditionalLibPaths=$(SourceDir)/CommonDlls
but it is not working.
Ideally, I would like to specify a relative folder from the root of the source code.
(a static path might work but only for one build server and agent, which is not the objective of shared build).
Any ideas on how I can define this parameter ?
There is also option to add a prebuild script path. I can store a script file along with source code. Any pointers for how to write such script file ?
You do not really need a script.
There are two things to make this work.
The first step is making sure that the DLLs are downloaded to the Agent working folder, the simplest way is have the $/[long tfs path here]/CommonDlls mapped in the Build Workspace; this is specified in the Source Settings tab of the Build Definition. Be careful to use the $(SourceDir) token in the mapping (see here).
The second point is to use a proper reference to the downloaded folder: use the TF_BUILD_SOURCESDIRECTORY variable (see here for full list).
So, if you added a mapping like
$/[long tfs path here]/CommonDlls -> $(SourceDir)\CommonDlls
use $(TF_BUILD_SOURCESDIRECTORY)\CommonDlls.
It took me almost 20 trials to get the right one, it all started with how long it took that warning to consider all other directories, I could've ignored it but here's the warning first
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "nameOfDllFile". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
and this is the argument that got it working
/p:ReferencePath="$(build.sourcesdirectory)\Binaries"
where Binaries is the equivalent to CommonDlls from the question, and it is all because of the vague documentation and differences between versions of MSBuild, mine is 14.0 (VS2015).
In a project I'm working on we check in Ruby with sass in order to compile scss files during the build. I switched to using a local workspace when updating gems so that changes are detected automatically. This works great except for the fact that files for new gems that reside in a bin folder are always ignored.
I have no existing tfignore files so I wonder is there some global ignore list that I could potentially edit or override.
I've tried adding a tfignore file at the root and even at the same level as the bin folder in an effort to force team explorer to stop ignoring those files but have had zero success thus far.
The content of the tfignore file is just one line:
!bin
How can I get team explorer to detect these changes automatically so I don't have to go through the extra step of finding and adding these files manually?
Bin and Obj folders are never shown in the project and adding files within those directories require some kind of manual step. If your goal by "not adding them manually" means you don't want to add them through "Source Control Explorer" but would just rather add them while working with a solution and project through "Solution Explorer", then you can click the "Show All Files" icon at the top of VS 2013/2012/2010.
This will then show you your potential bin/obj folders you may want to add files from:
Then you just right-click and include them. Once they're included, when you go to check them in, TFS knows you intend to add them to source control so it will show up in the Team Explorer pending changes window, if you are checking in from a higher-level in tree hierarchy. If you're not, then you can go to the "Excluded Changes" to find pending change you want to include in your final change.
If items are being excluded in anyway, try removing the .tfignore files and depending on your version of Visual Studio and settings, you may also be excluding your files through options such as this:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\AddOptions
We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.
We have multiple config files (app.DEV.config, app.TEST.config, etc) and a pre-build event that copies the correct config file to app.config. Obviously the configuration specific files are in source control --- but at the moment so is App.Config, and that shouldn't be.
How can I mark that one file as excluded from source control, but obviously not from the project.
I'm using VS 2005, and 2005 Team Explorer.
It's easy in TFS2012, create a .tfignore file
http://msdn.microsoft.com/en-us/library/tfs/ms245454%28v=vs.110%29.aspx#tfignore
######################################
# Ignore .cpp files in the ProjA sub-folder and all its subfolders
ProjA\*.cpp
#
# Ignore .txt files in this folder
\*.txt
#
# Ignore .xml files in this folder and all its sub-folders
*.xml
#
# Ignore all files in the Temp sub-folder
\Temp
#
# Do not ignore .dll files in this folder nor in any of its sub-folders
!*.dll
# EDIT https://msdn.microsoft.com/en-us/library/ms245454(v=vs.110).aspx#tfignore
# A filespec is recursive unless prefixed by the \ character.
Select the App.config file in Solution Explorer, and choose File -> Source Control -> Exclude App.config from Source Control.
There is a checkin policy (Forbidden Patterns Policy) in the MS Power Tools which lets you screen filenames against a regular expression. See: Microsoft Team Foundation Server Power Tools
While checkin policies are not completely foolproof, they are the closest thing TFS has to enforcing user-defined rules like what you're looking for.
(And as the others have said, you can also cloak a file or folder, which means it stays in Source Control and is visible to everyone else on the team, but it's not copied to your PC until you decide to uncloak it; or you can delete the file, which means it gets deleted from everybody's PCs when they get latest - but neither of these options will prevent such files being added to source control in the first place)
There is an option that is hard to find:
1. Select the file or multiple files in Solution Explorer
2. Go to File -> Source Control -> Advanced
and here it is
Keep in mind:
If you right click a file in Solution Explorer you only find "the most important options" not all :)
If all you want is to have a file in the project but not under source control with TFS, just go into SourceControl, delete the said file, and undo your checkout of the project file (it will attempt to remove the file from the project as well). Then check-in your delete of the file you are excluding. In the solution explorer you should see that there is no source control icon next to the file you're excluding. The project file should list a file there, but that file should now no longer be under source control.
Keep in mind, any other person will now see a missing file in the project when they get latest.
TFS allows you to cloak at the folder/file level. When something is cloaked, TFS won't attempt to sync it (much like a svn:ignore).
When setting up your workspace, cloak anything you want TFS to ignore. A more detailed how-to is here.
This worked for me:
One way is to add a new or existing item to a project (e.g. right click on project, Add Existing Item or drag and drop from Windows explorer into the solution explorer), let TFS process the file(s) or folder, then undo pending changes on the item(s). TFS will unmark them as having a pending add change, and the files will sit quietly in the project and stay out of TFS.
Source:
=">How can I exclude a specific files from TFS source control
Visual Studio 2013 (and 2012)
This feature is available by selecting the file(s) and going to:
File > Source Control > Advanced > Exclude ... from Source Control
This question was asked a while ago but it pertains to the same type of issue I was having.
The Problem:
We want to check in our code.
We then want build our project.
During our build we depend on Build Events to move files around so we have the proper files in place for the build process to complete.
When our Build Event tries to copy the files, we get Access Denied errors.
The Reason:
Team Foundation Server Visual Studio Plugin changes the Read Only attribute on our files to READONLY TRUE when we check in our files.
Build Event Example:
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
Above, we simply need to move a file from our Target Build Path (the bin\debug or bin\release folders) to our Project Folder. In my situation, this was so I could include project built files in my installer. My Installer wasn't grabbing them as part of the Project Output.
The Fix: (nearly kicked my self in the face when I figured this out)
New Build Event:
attrib -R "$(ProjectDir)SomeFile.ext"
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
attrib +R "$(ProjectDir)SomeFile.ext"
We're all having fun with Build Events right? Above I simply do 2 things, I remove the read only attribute, now the files not read only. Copy my file as I was originally wanting to. Then replace the Read Only Attribute (optional I guess) to keep Visual Studio and Team Foundations happy.
And yes... I'm still kicking myself in the face on this one.
I have a similar issue, my App.config contained sensible data (e.g. username) that this data should not by sync with TFS.
The article Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service describes an good approach to prevent this issue:
Use the "file" attribute of the "appSettings" element to reference an config file that is not added to source-control
If you have an older version than TFS2012 and thus can't create a .tfignore file or use the File > Source Control > Advanced > Exclude … option, you can try this:
Make a copy of the target file in Windows Explorer.
Undo Pending Changes (if any) on the target file in Team Explorer/Visual Studio.
Delete the target file in Windows Explorer.
Move the copy of the target file to the location of the deleted target file, and rename it so it has the same name as the deleted target file.
TFS now seems to ignore the changes in the target file. If you need to edit the file again, don't use Visual Studio, as TFS will then put the file back in the list of files with Pending Changes.
You can just simply select the file from your Source Control Explorer and Right Click on it, and the select the "Rename" option from there, and you can add ".exclude" at the end of the file name.
And then do remember to check-in the file, and after that you can see that your file is excluded from Source Control.