When I checkout files from tfs the modified date of the files get set to "now" (checkout date and time).
This behaviour, however, is not wanted from me for files that belong to purchased 3rd party controls from other software vendors. If I distribute these files to customers then I can't reliably check which version of the file is installed if there is a problem.
I know that tfs 2010 will have an option where you can select the desired strategy, but until then I need a different workaround. anyone else had this problem? how did you solve, or get around it. any advice is welcome, thanks!
One possible work around is to look at wrapping all third party files and controls within a class library and embedding any binary files within either that project resources or assembly file, you can then extract them as required when the program runs (example here).
As your project is under version control you will know exactly which file is in use by the version number of your project.
Related
I know I can look at the "Source Control - Team Foundation" output in the Output window but it's hard to tell where the results from the current request begin and the last request ended sometimes, and any files that I want to compare that are in the list I have to go look up.
In the past when I used subversion, I had a tool (I think tortoise) that did an awesome job showing me all the files that were changed and I could click directly on them to compare with latest version. I would often use this to do quick code reviews, and it made it much easier to make sure I wasn't about to get an updated project file that had been improperly merged.
Are there any extensions/plugins or anything that can help with this for TFS when getting latest?
Unfortunately there isn't such a tool can exactly achieve that, there is a user voice submitted here, and it's ARCHIVED.
Based on my experience, the best thing to do is a folder comparison before you get the latest version. In Source Control Explorer, you can compare the differences between two server folders, two local folders, or a server folder and a local folder. Right click on the target folder and select Compare. Read more here.
To see the changes block you can introduce the third compare tools. (e.g BeyondCompare, ExamDiff, Code Compare etc, you can reference my answer in another thread : Visual Studio TFVC Merge Lines Misaligned). In short you can get the change list from Output window, then compare each file accordingly.
Besides, you can also try using the Tf Command Line Utility and the Visual Studio extension Diff All Files for VS2013. Reference this thread for details : TFS Shortcut to do a diff on all modified files with latest version
We're using Team Foundation Service instead of a local TFS.
Our solution was created on Visual Studio 2012.
My problem is now that we want all assemblies to have the same version number (this part is already solved by using a CommonAssemblyInfo.cs that is linked into all projects).
The issue I'm facing right now is that we need the tfs changeset number at the last digit of the assembly version (e.g. 1.0.0.4711 where 4711 is the changeset number).
I've found several examples, but none of them worked for me.
And yes, I especially searched here on stackoverflow a lot.
I also have to admit that I've never looked into the MSBuild scripts...
Can anyone please give me a hint on how to accomplish this?
Is it for example possible to use the MSBuild Extension Pack on Team Foundation Service (not local TFS) and if, how to do that?
As always, time is my worst enemy...
Note that from 2010 Tfs employs Windows workflow for building the package the workflow calls msbuild for compiling the projects only - while its possible to pass changeset this way to msbuild its rather more hops.
Following deals with your problem, however the linked solution is more complex that needed:
Can assembly version been automatically updated with each TFS 2010 Build?
This is one of best series of tutorials on the custom build activities, the author is on stack as well i believe, one specificly about versioning
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
In short you need a custom activity to run before compilation on source files, find all CommonAssemblyInfo.cs files, feed this list to your custom activity, it modifies the values inside with passed value of full version number or only the changeset and optionaly check in the change (probably not since your changeset will be out of sync then).
You can also take a look at https://tfsbuildextensions.codeplex.com/ set of activities there is TfsVersion activity among them, at the very least it will provide examples.
Functionality need for this should be available through Team Explorer and source control - The Custom activity assemblies and build templates usually are located in folder in your team project root - the location of this folder is defined for build controller you can change this through team explorer build section.
Changeset is available from value BuildDetail.SourceGetVersion, not sure if this was fixed/changed in 2012 however there were 2 issues about this value in 2010
Its doesnt respect GetVersion override in default build template - you will manualy need to update if override is used
When running latest build (no override) it will get the last changeset number from tfs - depending on your branches this may not be the same as 'last' changeset for the branch of build. You will either have to live with this, provide overrides for each build or implement activity that checks branch history for last changeset value and overrides it again.
It should be noted that GetVersion should be able to accept any sourcespec version - changeset, date, label etc. I havent played around with this enough to provide more details to you.
Colin Dembovsky wrote a great overview of doing version embedding using the new pre-build script setting in TFS 2013 build definitions.
The Changeset number is easily accessible within the pre-build process in the environment variable TF_BUILD_SOURCEGETVERSION. I was able to use this to embed the Changeset value in our binaries using a script based on Dembovsky's work above. (I used Perl, not powershell, so you probably don't want to see it ;-)
This approach doesn't require any changes to the build workflow which makes it a big win for me.
I've used Wintellect's solution - MSBuild-only, no TFS magic needed. I also added to the auto-generated CSharp file:
[assembly:AssemblyInformationalVersion("$(BuildNumber)")]
So I get the TFS build number.
Has anyone used WiX to generate an installer for an ASP.Net MVC website? Do you harvest files from the web project? I can’t find any good examples of this being done. There doesn’t seem to be a documented way to include all the right files, only the right files and put them in the right place.
If you add the website project as a reference in the installer project, and set harvest=True in the properties, then all the website files are captured, but there are issues:
Some files that should not be copied are included, e.g. packages.config, Web.Debug.config There doesn’t seem to be any clear or simple way to exclude them (as per this discussion).
The .website dll file is in the wrong place, in the root rather than the bin folder (as per this discussion)
However if you do not use harvesting, you have a lot of files to reference manually (e.g. Under \Content\ alone I have 58 files in 5 folders. Most of that is jQuery UI) and they change from time to time, and errors and omissions could easily be missed from a WiX file list. So it really should be kept in sync automatically.
I disagree with the idea that the list of files should be specified explicitly in WiX and not generated dynamically (which is what seems to be suggested at the first link, the wording isn't very clear). If I need to remove a file I will remove if from the source control system, there is no need to do the extra work of maintaining two parallel but different catalogues – one set of files in source control, and the same files listed in WiX. there should be one version of the truth. All files in the website's source tree (with certain known exceptions that are not used at runtime e.g. packages.config) should be included in the deployment.
For corporate reasons I don't have much choice about using WiX for this project
In our MVC 3 project we use Paraffin to harvest files for the installer. For example, you can use "-ext " to ignore the files with extension , use "regExExclude " to ignore the file name matching the regular expression, etc.
Paraffin also keeps the proper structure, all your files would be in the correct folder as they appear in your project.
I use a program that I wrote called ISWIX that makes authoring wxs merge modules a simple drag and drop operation like InstallShield. I then consume that merge module in an installer that handles the UI and IIS configuration.
I also have postbuild automation that extracts the content of the MSI and compares it against what the project published. If there is a delta I fail the build and you have to either a) add it to the wxs or b) remove it from the publish.
I find that the file count churn from build to build is minimal and that this system is not difficult to maintain. The upside is everything remains 100% intentionally authored and files don't ever magically add or remove from the installer unless you intended them to. Dynamic installer generation isn't worth the risk and most people who argue that it is don't even know what those risks are.
As far as I know, Team Foundation Server 2010's source control (and prior versions) doesn't support linking (Symbolic links) of files.
Linking (per Visual SourceSafe) was the concept of providing one "hard" file in a folder, and then "linking" to it in other locations - exactly like file system hard links are designed.
Does anyone know if files can be linked at all? I realise it is not a good practice in general, but I have some scenarios where it makes sense.
According to an answer in this thread: Linking TFS source control folder from another TFS project it's not possible, but I can't find a definitive answer.
Closest thing I can find courtesy of Google is a thread on the MSDN forum but it's quite old (2006). I'm pretty much assuming that this is still the answer though (unless anyone knows differently)?
This thread is more recent (2010), about TFS 2008 and 2010:
TFS (2008 and 2010) do not have support for links. There is a server-side extension for TFS 2010 (ie. what VS2010 used for gated checkin) but this sounds like a client-side solution since the link must be converted to a file to be recognized by the client OM.
If you only work with the command line, how about a wrapper tool for some version control operations? For example, the check-in wrapper would convert links to a linktext file and add or replace the existing linktext file before doing the normal check-in. The check-out wrapper would check-out the corresponding linktext file. Note that there will be quite a bit of work since you'll have to wrap many commands.
There seems to be a work-around for this for Linux-based systems.
This page - Applying Unix Filesystem Attributes to Files under Version Control - describes how to use a .tpattributes file text file to store details about file attributes. The article applies to the Visual Studio 2010 edition.
The process is described here: How to work with symbolic link files under Linux/Unix and TFS?. It involves the use of both a .tpattributes file, and a 0-byte file representing the symlink.
There have been some reports of success for this, according to the comments on an updated request to Microsoft for this feature to be implemented in TFS 2015.
In Perforce, symlinks may just be checked-in without having to go through any of this.
It's not possible to make classical links, but it's possible to use branches for simmilar functionality. You can use a branch over folder to make something simmilar as were links. The only drawback is that you still work with branches, so it's necessary to do merges etc. See section "Source Code Sharing" of this document for detailed instructions.
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.