Develop Reference

TFS branch from existing project

In TFS I have branch on my name but when this branch is make its maybe after 2 week and I have a many changes on this project.My questions is how to upload my change project in this branch to can merge MAIN and my project without errors?

You need to check-in your changes to the branch first, then merge the branch back to main via the Source Control Explorer.

The best way to do so is to first check in your changes into your branch (Pending Changes), den commit these changes.
Afterwards you have to Merge with your MAIN branch, but be sure to first review your changes with the branch you are merging with.
https://msdn.microsoft.com/en-us/library/ms181428.aspx
If you encounter errors, this official Microsoft resource will help you to resolve errors that can happen after a 2 week difference.
https://msdn.microsoft.com/en-us/library/ms181432.aspx
Something that you should never forget: Before Merging with the target branch of your desire, GET LATEST
microsoft.com/en-us/library/jj155787(v=vs.120).aspx

Visual Studio SDK - Handling File Add, Remove, and Rename Events

I'm working on a Visual Studio extension that should listen for events when the user adds, removes, or renames files in the current solution.
The answer to this question notes that VS provides infrastructure for listening to document events like saving, opening and closing through the DocumentEvents interface. For example:
Dte.Events.DocumentEvents.DocumentSaved
Are there similar events that would allow me to listen to the user adding/removing/renaming documents?

First, don't use DTE if you can help it. It's a very incomplete, shaky abstraction papered over an extremely complex interface. Having said that, I admit that sometimes it's super handy because the equivalent either can't be done without it (rare) or the alternate code would be quite long (less rare).
There are two concepts being conflated here. The first is the Running Document Table (RDT). The RDT represents all the open files (including the open .sln and project files). You can subscribe to RDT events to be notified of files being opened, closed, renamed, etc. But these events are for open files only!
The second concept is the project system. Each project loaded and displayed in the solution explorer is loaded by the project system for that project's type. C++ projects, C# projects, F# projects, WIX installer projects, etc. all have different project systems. There can even be custom project systems implemented by extensions. It sounds like you want to know about events in the project system, and not events for (just) open files. So your focus is the project system. However, since all project systems have different implementations, this becomes very tricky. VS is moving towards a common project system (CPS), but it's not 100% there yet, and even when it is there remains the problem of all the legacy extensions, etc.
You can subscribe to general "hierarchy" events which all project systems must furnish. They'll tell you for example when a file is added or removed (really, when a hierarchy item (node) is added or removed, since there's not necessarily a correspondence between files and hierarchy items). There's also an event that says the entire hierarchy has been invalidated -- a sort of refresh where you have to discard everything you know about the project and gather up new info.
Rename is probably the hardest thing to detect. Every project system implements it differently. In some project systems, a rename will present itself as a node deletion followed by a node addition, with no solid way to identify that it was due to a rename.
To sum up, nothing is as simple as it seems, particularly when it comes to project systems (one of the least extensible parts of Visual Studio). You'll likely end up with code that is specific to one or a handful of project systems, but won't work universally. (After all, not all projects even represent file hierarchies! And those that do still have folders, special reference nodes, etc. that aren't files.)
Some concrete pointers in the right direction:
Implement IVsSolutionEvents3 to be notified of a project being loaded/unloaded (and IVsSolutionEvents4 to be notified of a project itself being renamed). Register that object as a listener in your package initialization code (make sure your package is loaded before a solution is opened) via the SVsSolution service (cast to IVsSolution and call AdviseSolutionEvents on it).
Implement IVsHierarchyEvents to be notified of project changes like node properties changing (use the __VSHPROPID enum to find out which is which), nodes being added, removed, invalidated, etc. Call AdviseHierarchyEvents on the IVsHierarchy object passed to the IVsSolutionEvents3's OnAfterProjectOpen implementation to register the event listener object.

You can subscribe to the EnvDTE.ProjectsEvents, EnvDTE.ProjectItemsEvents or IVsHierarchyEvents.

I know this is an old post by now, but for anyone else, who is searching for a fast solution. Take a look at the IVsTrackProjectDocuments2 class and it's matching IVsTrackProjectDocumentsEvents2 event interface.
You will receive notifications for all project items (Not solution items!), including Solution Items, which match the following actions:
Rename Directories
Rename Files
Add Directories
Add Files
Remove Directories
Remove Files
SccStatusChanged (I am guessing, that it will fire after a file's source-control state changed.)
These will contain an array of the changed items, their new state and the projects in which updates occurred. Additionally you will get a VS*FLAGS array, which contains more information about the current operation.

Deploying branches and maintaining configs in VS2010 / VSOnline

I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam

How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah

In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.

Determine SVN working copy revision from C#

I'm writing a small console tool in C# that needs to know the revision number of an SVN working copy directory to process other data with this number. I already have support for SVN 1.4 to 1.6 by directly reading the entries file in all .svn directories. But SVN 1.7 has changed that to use a single .svn directory with an SQLite database in it.
What's the best method to determine the revision number of a working directory?
I've just tried to use SharpSVN, but it's largely undocumented and I can't figure out how to use it. It's also very huge with 5 MB and potentially several DLLs.
I can't find a simple SVN command line client that is freely downloadable. Also, last time I've seen one, it was huge and consisted of numerous files which is not exactly portable. (It would be great if my tool would only come as a single .exe file.)
Another option would be to use an SQLite library (available as a single separate DLL) and dig into the database myself. I've already done basic research on this but I'm not sure how to detect uncommitted modifications.
TortoiseSVN, which is likely already installed on the machines that will be using my tool, can't be used because it contains everything in a single GUI application, no DLLs that I could reuse.

If you don't want SharpSVN and work with Working Copy, then in 99% host may have SVN CLI-tools.
Check callability of svnversion and call it svnversion <PATH-TO-WC>, intercept output

I use Tortoise SVN's command line tool called 'SubWCRev' for this purpose (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html). It allows to determine latest revisions, commit date and more... The drawback of this solution is that this tool work with files, so you will need to define template file and parse tool's output file. This works good for me though.

How can I compile changes in only 1 document but keep the original build of the others? (C#, Asp.Net MVC)

I have a local install and a live install. My live install is working except I changed one of the methods to be restricted via [Authorize(Roles = "Admin, Host")] I want to remove this, but I need to do a build of the solution and move the .dll over for it to work (correct me if I'm wrong).
I cannot build the solution because my local install has changes to all of the files and will not build properly. All I want to do it update that one controller/page to allow access... is there any way of doing that?

What you need is branches (you are using Source Control, aren't you?)
Basically, what you do is have one branch where you do development, and another "stable" branch, where you only do small fixes to the code that is in production.
Once you deploy to production, you "merge" from the dev branch to the stable branch.
If you are not using Source Control, just have 2 copies of the code for now, and do the same kinds of things.
And learn to use Source Control, your life will change dramatically.

THis may not help you this time, but it sounds like a perfect example of what source code control systems are for. Tools like cvs, git, ClearCase, subversion and so on let you maintain a database of code and changes to it. Then when you make a release, or "live install", or deploy to a production server, you can make a snapshot of the code at that point. Then when you need to fix something urgently in the production version without a full release cycle, you can check out a copy of the code that is running "live", and fix it, without messing up the copy you're hacking on for the next great feature.