The way we use TFS is that in our development tool we export all classes of the project into one XML and manually upload that XML as the new version to our TFS project. However sometimes the export process includes classes that must not be in that export.
Can TFS validate the content of the upload and give a warning that the file contains illegal strings, such as "class this.that.shared.never_include_this_in_exports()"?
Can TFS validate file content and reject / give warning?
AFAIK, I do not think TFS supports validate file content feature when we upload it to the repo.
For TFS, whether it is a centralized TFVC or a distributed git, TFS only tracks and controls the file itself, and does not provide verification of the syntax in the file. This should be a function of our compiler. It should not be a function of a version control tool.
So we need to use other tools locally to verify whether there are any errors in our XML, or, as Daniel said, to verify whether the file is correct through CI.
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.
This is more of a hypothetical question as I am sure this is not a very good way to do things.
Say I have an SSIS package, under source control in TFS, that needs to read and modify some files, say a csv. how does it handle modifying the csv if the csv is also under source control in TFS?
i don't have a complete understanding of how it works, but i assume the csv would be under write protection until it is checked out. Does the ssis package just error out when attempting to write to a write protected file? Having to modify the SSIS packages to somehow get around the write protection would require a lot of work as all the these packages are already written and being added to source control now. alternatively, I assume there is some kind of settings you can do in TFS to turn off write protection on your local copy or automatically check out a file if it is being modified.
is the real solution to just keep the input and output files from the SSIS package outside of source control (as there is probably questionable justification for them to be there in the first place?)
TFS is integrated into Visual Studio. When you edit a package, VS checks it out of TFS for you and you can use Visual Studio's interface to check it back in.
In VS, Tools/Options/Source Control sets up the source control provider. File/Source Control is where you manage the connection to the project.
If you change your workspace over to a local workspace the read only attribute is removed for all files.
If however you need to edit the file in a normal workspace why I'd it under source control at all? A better way would to have separate files for DataIn, DataOut, and DataCompare. You should have DatIn and DataCompare under source control, but DataOut should be generated.
It is not recommended to have any generated files under source control.
We're currently setting up a number of builds in TFS2010 for our various projects/solutions.
We have a large number where the structure and paths, etc. are essentially the same, but one word may change (for example, using all Integration workspaces versus our Trunk workspaces).
In TFS2008, I would simply edit the XML directly and do some creative search and replace or some magic in textpad before saving the file. However, I do not see any immediate way of doing this in TFS2010 - so I'm stuck slogging through the build definition UI.
I know, in doing a SQL Trace, that all of this ends up as XML - so is there a way to directly access this XML for hand-editing vs. being forced to do all changes through the front-end?
Thanks!
Edit for additional clarity
I have the Power Tools installed, etc. and can clone my builds - but my editing options are still limited to the UI, so if I have a large number of workspace path changes I have to do them by hand (one at a time).
My goal is to be able to directly edit the XAML for a specific build definition so I can do a clone, open the XAML, and then do a search/replace in bulk.
Download and install the Team Foundation Server Power Tools. You can also get them through the Visual Studio Extension Gallery. After installing, you can right click on a Build Definition in Team Explorer and select the Clone Build Definition command (added by the Power Tools installation) to make a copy of an existing build definition. Then you can tweak it appropriately for another branch, etc.
The following tool (VS Addin) will satisfy your requirement>
Community TFS Build Manager
http://visualstudiogallery.msdn.microsoft.com/16bafc63-0f20-4cc3-8b67-4e25d150102c
The build definitions are all .xaml files now - they're WF4 workflows, and they're XML files.
Jim Lamb is right. The build templates are .xaml files now. The definitions are accessed through web services.
I'm about to experiment with a quick HTML form posting to /tfs/_tfs_resources/Build/V3.0/BuildService.asmx/QueryBuildDefinitionsByUri. I noticed when I clicked the build definition in Team Explorer that it has an associated URI: vstfs:///Build/Definition/2. Stay tuned.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information
What would be the best method of automatically generating a Release Notes text file from a Team Foundation Server 2008 nightly build?
We created a TFS report that lists all Work Items associated with a specified Iteration (version). In addition we added a custom field to Work Items to indicate if we wanted the work item included in the release notes report. (Not all Work Items are appropriate for all clients/users.)
You could automate this process but you would need to specify the iteration in your build task. Or you could list every work item that has been completed as of a specific date.
I think the solutions here are describing "build notes". If you want that, you really need to checkout the TFS Community Build Manager. It has a feature to generate build notes in Word files by using the OpenXML. It's clicking the VSIX and you're done.
But imho, build notes are not release notes. Release notes provide a more customer friendly way of listing you changes. And you need to be able to specify what work items you want in the notes, and the ones you don't want your customer to see. So for that, I have created a custom Team Explorer add-in. And it does more or less what the build manager does as to generating the OpenXML Word.
I use queries to define what the bugfixes are, what new features are available, ... and then the team explorer extension provides the GUI to specify the document fields (Title, descriptions, remarks, ...) and to select the queries corresponding to the blocks on the release notes. After filling in the details, the word document gets generated. I can provide with all the details if you want.
UPDATE:
I uploaded a sample xsl file for transforming the buildlog.xml to get an informative plain releasenotes.txt. Get it here: Automatically generate release notes textfile from Team Foundation Build
That one is actually pretty easy. Grant Holliday describes it on his blog. It basically goes something like this:
Install MSBuild Community Tasks (which contains the WebDownload Task)
Install MSXSL.exe from Microsoft (for transforming xml files)
Extend the tfsbuild project with information regarding the retrieval of the buildlog.xml (using WebDownload task) and transformation with MSXSL.exe
However, you need to download the MSBuild Community Tasks directly from tigris and not use the link provided in this blog post. This is due to the fact, that the link refers to the wrong version which does not support the UseDefaultCredentials options (that you need for the MSBuild Task to be able to connect to the proper TFS Webservice).
Here is the link to the article:
Building a release notes text file with team build
I got everything working except for the xsl file, because unfortunately, Grant does not offer a sample xsl. If you manage to create a proper xml transform file that fits your needs, it would be awesome if you can send me a copy. ;-)