I was wondering if it's possible to use tabs for indenting my C# code in Visual Studio 2013, but save the file with all tabs converted into spaces automatically. I know this can be changed in settings and then autoindenting used to fix it to the right one, but this isn't automatic.
The reason behind this is that I am currently working in a group where spaces are preffered way of indenting code, but this setup isn't convenient for me - having to click backspace 4 times after an exceeding tab (or undoing - which is almost the same inconvenience, albeit not that much) is quite annoying.
I don't want to interfere with my group's setup (nor could I, actually), but would like an easier way to traverse my code locally. We use Git for project sharing, so maybe if this cannot be made in VS maybe Git can do it?
Note: I searched Stack and Google, but couldn't find adequate answer due to arguments over which indentation technique is better. This post is not supposted to start another discussion about this either.
Since you're using Git, you could try checking out tabs and converting to spaces on checkin. This might cause issues of its own, but it might also solve your problem. This question should tell you how to do that if you're interested. It deals with Python, but I imagine it would do the same for C# just fine if you replace .py with .cs. Here's the accepted answer for completeness:
In your repository, add a file .git/info/attributes which contains:
*.py filter=tabspace
Linux/Unix
Now run the commands:
git config --global filter.tabspace.smudge 'unexpand --tabs=4 --first-only'
git config --global filter.tabspace.clean 'expand --tabs=4 --initial'
OS X
First install coreutils with brew:
brew install coreutils
Now run the commands:
git config --global filter.tabspace.smudge 'gunexpand --tabs=4 --first-only'
git config --global filter.tabspace.clean 'gexpand --tabs=4 --initial'
All systems
You may now check out all the files of your project. You can do that
with:
git checkout HEAD -- **
Although I too prefer tabs, I also suggest finding out how to use your tools effectively with the project's style. Maybe you could just find a way to make backspace delete sets of 4 spaces when found?
Since your primary issue deals with formatting concerns, I would recommend using Format Document (Ctrl+K,Ctrl+D or Edit>Advanced>Format Document or Format Selection) to fix this.
Its fast and will correct indentation for the whole file/section at once, and you don't have to worry about altering the IDE save behaviors.
If you are trying to keep everything well organized as-you-type-it, you may not be using the provided tools efficiently.
Related
On a reasonably large project I occasionally find myself in the following situation during a merge (I'm using the Windows GUI for Git called GitExtensions, but I'm equally comfortable with the command line):
File does not have a local revision. The file has been deleted locally (ours) but modified remotely (theirs).
I then get options to either: "Delete file (ours)", "Keep modified (theirs)", or "Keep base file".
I understand what has happened here and what these options are, but in most cases I don't know how to proceed unless I can see the changes that were made to the file on the branch that I'm merging in. If it was an unimportant change (whitespace / formatting / 'using' statements) then it doesn't matter and I can just keep the deletion, but if they made some more significant changes then I'm going to have to spend some time manually hunting these down and merging them.
Does anyone know of a git command I can run that will show me a diff of base -> remote in this situation? At the moment when this happens I'm going over to my colleague's desk to ask them what changes they made to that file so I can continue with my merge.
Well, it's not the best solution, but it's possibly the easiest. If you start the merge in Git (but before you act on it) Git will create a .BASE, .LOCAL and .REMOTE file in the same location as the file you need to merge.
In the case I've outlined above either .LOCAL or .REMOTE will be missing (depending on who deleted the file), but you can still go to the folder in question and manually diff either .BASE -> .REMOTE or .BASE -> .LOCAL.
This is probably easiest for Windows users.
If you really want to use the command line you can run
git merge-base <mergingBranch> HEAD
to find out the base commit hash. Then, using part of bundacia's answer above:
git difftool <mergeBase>..MERGE_HEAD -- foo.file
You can git a list of the changes made to the file on the remote with this command:
git log -p MERGE_HEAD -- foo
Explanation:
foo is the file in question.
MERGE_HEAD points to the HEAD of the remote branch you're merging with
-p causes log to print the diffs with each commit
I was successful using Git Gui. It came as part of msysgit and can be accessed from the Windows Explorer context menu.
At the point where git merge tells me to fix the conflicts and then commit, I opened Git Gui (see screenshot below).
In the upper-left corner, it shows all changes that are unstaged (because of conflicts). To the right of it, there's a diff of the file in question. It tells me that the local version has been deleted (first two lines), but also shows the remote changes (3rd-last line). I'm pretty happy with that!
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.
I have a repository cloned from GitHub, and I made changes to file A, however Git is detecting
changes to file B,C and D. All three files are detecting the changes as basically the entire contents of B,C,D. i.e. +all lines in B,C,D, -all lines in B,C,D.
I don't want to commit this as it makes for a dirty commit. Why is git detecting these changes and how to I get git to ignore these changes forever?
The project is in C#, I use the GitHub windows application and the IDE is VS Express 2012.
Edit:
I realize the files have changed, but is there a way to a) find out what changed and b) tell git to ignore them and not pick them up again between commits. It seems my editor is modifying files B,C,D in some way after I first openened the cloned project.
Even after running a git reset --hard, git diff still reports the changes.
You probably need to tell git about your line ending strategy.
See the following resources for more information on this subject
https://help.github.com/articles/dealing-with-line-endings#platform-windows
http://lydiapchung.wordpress.com/2012/06/01/github-for-windows-line-endings/
Note: Short time fix would require to tweak the core.autocrlf setting on your computer. The correct fix would be to create a .gitattributes files, commit it, and send a Pull Request to the upstream repository you've cloned. Indeed, it would not only fix your issue, but would also prevent new users from stumbling on the same problem later.
An example of a valid, C# project compatible, cross platform .gitattributes file can be found here. Feel free to get some inspiration from it ;-)
A very detailed blog post about line endings and Git inner workings is Mind the end of your line. It's very well worth the read.
This is probably related to the eol (end of line) style, as explained in Github page "Dealing with line endings".
I would recommend:
git config --global core.autocrlf false
git clone https://github.com/user/repo newrepo
And see if in that new repo the issue persists.
There are reason to have core.autocrlf activated, but it causes more problem than it solves.
You can manage the end of lines with other settings (see this question).
I'm using TFS source control.
When I add a new resource key to my resource file - Resources.resx - and hit save, TFS checks out Resources.resx but doesn't check out Resources.Designer.cs. This causes the update to Resources.Designer.cs to fail with error:
The command you are attempting cannot be completed because the file 'Resources.Designer.cs' that must be modified cannot be changed. If the file is under source control, you may want to check it out; if the file is read-only on disk, you may want to change its attributes.
The error is correct in that the file IS read only and the file IS NOT checked out. I don't want to have to manually check out the designer every time I add/edit a resource key. Does anybody know of a solution or work around to this issue?
Note that I have TFS set up to "check out on save" as opposed to "check out on edit". This is deliberate to reduce the amount of unedited checkouts.
EDIT:
This happens in other file types also. For example, I am using RazorGenerator to create compiled MVC views. The same problem occurs if I try to edit the .cshtml without checking out the .generated.cs first.
UPDATE:
This issue occurs on all (as far as I've seen) files that have an autogenerated code-behind: .resx, .edmx, .aspx, .cshtml (when using RazorGenerator for compiled views), etc. I've decided that it's not worth the pain just for having "on edit: do nothing" set. I've decided to reset this to "on edit: checkout automatically". Thanks to everybody for your input. No thanks to TFS team for this FAIL.
Well, I did not think this counts as an answer so I wrote it in comment.
Checkout on save is only triggering when you save file, it does not trigger when file is autogenerated (autogenerate is not trigger for save which does checkout, as this file is edited by custom tool assigned to resx).
I'm afraid you will not get proper answer (the one which will solve your problem) besides that it is by design, but it may be worth opening a case on connect and ask to change this behavior.
Why do you want to reduce the amout of unedited checkouts? If a file is checked in without changes, TFS notices and it will not show in the checkin history of the file.
You can test this yourself by checking out a single file and immediately checking in. TFS will tell you there where no changes and the checkout is undone.
So maybe consider setting it back to checkout on edit? As mentioned in the other answer, this will solve your problems...
I think this is the problem
Note that I have TFS set up to "check out on save" as opposed to
"check out on edit". This is deliberate to reduce the amount of
unedited checkouts.
To avoid above problem, revert back to default settings. Then download TFS power tools.
Then use this command to revert changes which are checked out but contain no edits
tfpt uu /noget
Update: On changing above setting the issue no longer occurs. For details, refer below discussion in comments.
I have to work with TFS at work. I've seen to many miracles and we've spend a lot of time figuring out where the problem is. TFS is the choice of my company, but it's not my favorite.
TFS (especially when server is slow and you have regular network problems) is a disaster for me as a developer. VS looks for modification only over files in solution, and as you can see not all of them. When you use third party tools (fitnesse for integration tests or custom build steps) wich requires to modify files outside VS - you'll probably get the same error as you have.
But we found a solution. On my machine I use git. We've installed git-tfs.
And all you need to remember is three magic commands
git tfs fetch
git merge remotes/tfs/default
git tfs ct
That's it. You will never break company rules. And at the same time you will be free of that kind of weird problems. We've forgot about that nightmare.
EDIT: Local workspaces in the upcoming TFS 2012 will solve several issues, and TFS 2012 will become closer to SVN, but it will not be DVCS. MS invest in integration with external DVCS - please, welcome - Git-TF.
I'd like to host some of my C# VisualStudio 2010 projects on github. I'm guessing that it's good practice to at least add a minimal .git/info/exclude file. For my FluentWpf project, I've got this in my exclude file:
FluentWpf/bin/*
FluentWpf/obj/*
Are there any other best practices to follow before checking my projects into git?
You can use GitHub's default .gitignore for it:
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
If you happen to use Git Extensions, it has its own default .gitignore. In Visual Studio just go to Git menu->Edit .gitignore and click "Add default ignores".
Before making the initial commit I think it's also a good idea to decide on how you're going to treat line endings.
As you probably know, Windows uses a combination of CR-LF ASCII characters to denote the end of a line, while UNIX systems use an LF character alone. If your project is going to be developed only on Windows, I don't think it makes any sense to use the UNIX endings, so I would make sure the core.autocrlf option is set to false. If your project is going to be edited both on Windows and a UNIX system, you may set it true - then the repository will internally store all line endings as LF characters, but files on your disk will contain CRLF.
These are at least the choices I would make, someone else might do differently. Whichever option you choose, CHOOSE IT NOW, because changing it later may be problematic.
Git Extensions allow you to change this option in GUI: Git->Settings->Global/Local settings tab, "Line endings" groupbox.
Make sure all developers in your team have the same setting on their machines.