Never thought about it before but is there an easy way to count all lines of code in a project? You can see how many lines of code there are in a single form but if you have hundreds its not an easy task.
Does RAD Studio have a feature to count the number of lines in your project?
Yes, there is a simple way. You can just build a project and you'll see total number of compiled lines. It's funny sometimes... say, when I built a release with exactly 666'666 total.
Make sure that 'Automatically close on successful compile' is unchecked otherwise the compile window may disappear too quickly. Or look under Project/Info right after the build.
Related
I am facing 2 problems during checkin of design changes in TFS 2012.
When I made the some design changes (for example alignment of buttons), codes in frm file gets rearranged. Which gives me a lot of differences even though there are very few (If I manually cut and paste the code in proper place then I can see only few lines of mismatching)
If there are some unwanted changes in frm files then there will be changes in respective frx files also. My question if I undo (delete the unwanted changes in TFS ) then how can I differentiate between required and unwanted changes of frx files ?
These two things are killing my lot of time. Please help me to solve these problems.
Its not always the case, but usually the amount of churn in generated files like the frm file is caused by people by selectively checkin parts of that file. By selectively checking in parts of a generated file it causes visual studio to make more drastic changes to the file than one would expect beforehand. If you checkin the complete file a few times this behavior should go away. If it still persists, another option would be to swap the merge tooling to something that suits you better https://blog.paulbouwer.com/2010/01/31/replace-diffmerge-tool-in-visual-studio-team-system-with-winmerge/. E.g. winmerge can be modified to ignore moved sections if they are not modified.
Every VB6 project in source control faces this issue. I find it useful to break up my work into many smaller changes, and diff and/or check-in changes only in those smaller chunks. This usually makes it much clearer what actually changed.
As in subject:
Go to "Find Changeset" option.
Find a changeset.
Double-click on changeset to open Changeset Details window.
It gives a list of all files that have been checked in within given changeset.
Why I cannot apply a label on those files from that level where I have them all in one place? Especially, that very often they are part of different solutions and projects, so normally I would have to create a label for one file and then search and add one by one to the existing one.
It is so inefficient!
Is it some bug or lack of functionality? If the second - it is hard to believe MS guys forgot about such handy function.
How do you deal guys with such situation?
EDIT - to clarify my reasoning:
If I use jessehouwing's method - yes, it works and it's simple.
But then when I search in the future for that label and want to see what code was included, it gives me a list of all solutions - even those totally unrelated (IWP and PDPRO are the unwanted ones):
If I use it my way - it gives me that:
I think it looks cleaner and gives directly the information of what solutions and files underneath where included at the time when I put stuff into Production environment and applied corresponding PROD label.
The feature you're looking for doesn't exist. generally a single file or group of files at a label doesn't make a lot of sense. While it's possible to "scope" labels in TFVC, it's only possible through the commandline.
generally you'd create a label at the repo or branch level at the specified changeset. That will include all files, including the ones you just checked in. Creatign such label is relatively easy from the source control explorer, though you need to copy the changeset number:
It's unclear to me why you'd only want the changed files to be included in the label, maybe you can elaborate a little more on that requirement.
Update: What you desire isn't possible from inside VS and isn't simple from the commandline either. I suppose that with a bit of Powershell Magic against the TFS Client Object Model you can do this from the commandline and it should also be possible to build this as a Visual Studio Extension (or maybe suggest it to the author of the TFS Source Control Explorer Extensions.
I am in the process of setting up continuous integration in our TFS system. One major part of our system are the development of about 50 DotNetNuke modules to support our CMS infrastructure. Right now, each of those projects have their own solution since their code bases are mostly siloed (with common code in 1 or 2 common projects). Keeping them in their own solution is done because it makes the development process faster (loading, compiling, etc....)
However, this has proven difficult to maintain when setting up TFS team build as each solution has to be manually added to the build definition and MSBuild seems unable to take advantage of parallel compiling due to each project being in its own solution. This causes about 5 minute full build times, which while isn't horrible isn't ideal. Mostly though, it's not ideal from a build definition maintenance aspect.
To solve this I creating a global solution that included all projects. The idea being that if you want your project to be automatically compiled and deployed by TFS you will have to include your project in the global solution. This seems works well, as it's easy to maintain from a build definition standpoint and brings the total build time down to 70 seconds.
The one problem is that the displayed TFS build log groups all warnings and errors together under the solution instead of separating them out by project. This makes it difficult to quickly see what project caused which errors and warnings.
Is there a good way to see project level error/warning messages in the build log summary view without delving into the cluttered build log?
To answer your direct question, I believe the answer is no (at least not without some heavy customization).
For me this is never a big concern as I am pretty aggressive about getting my teams to bring errors/warnings down to zero, then enforcing it via TFS Build (/p:TreatWarningsAsErrors=true). This means you should never have to wade through hundreds of warnings in the build summary.
If you add all your individual solutions to the build definition, you can always use the TFS Power Tools to "clone" a build def to make maintenance easier. You could also modify the Build Template to build the solutions/projects in parallel, although this runs the risk of having file contention issues.
I'm trying to work with MSBuild and TFS.
I've managed to create my own MSBuild script, that works great from the command-line. The script works with csproj files, and compiles, obfuscate, sign and copies everything that's needed.
However, looking at the documentation of TFS & Team Build, it appears that it expect solutions as the "input" for the script.
Also, I haven't found an easy/intuitive way of performing a "Get Latest Version" from the TFS as part of the script. I'm assuming that the Team Build automatically do a "Get Latest" on the solutions it's suppose to compile, but again - I don't (want to) work with solutions...
Any insights? any pointers? any links?
Team Build defines about 25 targets of its own. When you queue a Team Build, they are automatically run for you in the predefined order listed # MSDN. Don't modify this process. Instead, simply set a couple of these properties that determine how the tasks behave. For example, set <IncrementalGet> to "true" if you want ordinary Get behavior, or "false" if you want something closer to tf get /force.
As far as running your own MSBuild script, again this shouldn't be necessary. Start with the TFSBuild.proj file that's provided for you. It should only require minimal modifications to do everything you describe. Call your obfuscation & signing code by overriding a task like AfterCompile or AfterTest. Put your auto-deploy code in AfterDropBuild. Etc.
Even really complex scenarios are possible if you refactor appropriately. See past answers #1 #2.
As far as the actual compile, you're right that Team Build operates on solutions. I recommend giving it what it wants. I'll be the first to admit that *.sln files are ugly and largely undocumented, but at least you're offloading the work to a well tested & supported product.
If you really wanted to, you could give it a blank/dummy solution and override the CoreCompile task with your custom compiler logic. But this is really asking for trouble. At bare minimum, you lose all of Team Build's flexibility WRT building multiple platforms and flavors. More practically, you're bound to spend a lot of time debugging something that's designed to "just work" -- and there are no good MSBuild debuggers yet (that I know of). Not worth it, IMO.
BTW, the solution files do not affect the Get process. As you can see in the 1st link, the Get is done very early on, long before Team Build even reads the solution file(s). Apart from a few options like <IncrementalGet>, this is not controlled from MSBuild at all -- in particular, the paths to be downloaded are determined by the workspace mappings associated with the build definition. I.e., they are stored in the Team Build SQL database, not the filesystem, and managed with tools (like Team Explorer) that call the TFS webservice API.
I am trying to come up with best practices regarding use of TFS source control. Right now, anytime we do a build, we label the files that are checked into the TFS with the version number. Is this approach better or worse than simply checking the files in and having the version number in the comments?
Can you then use the changeset to go back if necessary or the labels are still more versatile?
Thanks!
They have two different purposes, ChangeSets are when the files have actually changed and you wish to keep a permanent record of that change. Labels mark a certain version of the files so that you can easily go back to that point. Unless your build actually changes files under source control and you wish to record these changes. You should be labeling.
Also, labeling is much less resource intensive. And you can have multiple labels on the same version of a file.
You should label the versions of source files that make up your build. If you're using TeamBuild, it does that for you automatically. It combines the name of your build definition, date, and the build number. So you don't need to do anything.
Your other option is not very conventional and requires a lot of unnecessary work. If I understand it correctly, you would check out your source files during the build process and then check them back in with a version number specified in the check-in comments. This is as Alex mentioned very resource intensive in terms of your build process and also your source control repository. Moreover, how would you get the source files for a particular version if the version information is embedded in the comments? It will be very hard and you would have to sit down and write your own application that uses TFS source control api to download the source files to a workspace by searching for the version number in the check-in comments. This creates unnecessary complexity and headaches.
If you use labels instead, you can do a get by label in VS IDE to download the source files that make up that label. You can even tell TeamBuild to use a label instead of downloading the latest source files during build automation. That way you can build previous versions of your application easily. With labels, you can also apply later changesets to an existing label if there were code changes by simply getting that label and then getting specific changesets and then doing a quick label or creating a brand new label.
Labeling is very powerful, convenient to use, and is a part of TFS. Rather than coming up with your custom solution that requires a lot of effort to make it work and maintain, just try to use what's already available.
Right now, anytime we do a build, we label the files that are checked into the TFS with the version number
You don't need to do this. TFS can refer to a state of the codebase in numerous ways, of which labels are indeed one - but so are builds and even changesets. You can see the available ways to reconstruct a particular point in time by doing a Get Specific Version... and examining the options in the Type dropdown:
Changeset
Date
Label
Latest Version
Workspace Version
Changeset allows you to get just after any changeset; Date is obvious; Label is too, except that builds automatically* create labels (choose Label from this dropdown then have a look in the Find Label dialog).
*I think it's automatic! Unless it's something we've set up specially where I am at the moment...
StackOverflow won't let me comment on the answers above, so I'm writing this as a new "answer". I want to clarify some of the misconceptions listed above.
First, using TFVC Labels is MORE resource intensive than using changesets. A lot more. Commands such as Branch, Merge, and Get by Label is slower. For enterprise servers with huge databases you do not want to be using labels.
Second, Builds don't automatically create labels, although the default build steps include a step to create a label.
Third, as others already mentioned, labels can be moved or deleted, so they are much less dependable than changesets which are immutable.
Overall I recommend you NOT use labels. The simplest alternative is to just remember the changeset number for your builds. Or if you want to isolate different release versions, you should create release branches.
Labels are OK for small systems, but are not good for large enterprises.