3,044 votesGiovanni Bassi gave this 3 votes ·
And settings should be per test class, test method, or test assembly.
Thank you all for sharing your feedback and for voting on this suggestion. We are continuously reviewing and evaluating our SKU model to determine if there is a need for change driven by market conditions. At this time we have no plans to extend CodeLens beyond Visual Studio Ultimate. We are declining this suggestion so your votes can be used on other suggestions.
Visual Studio Team
I like the idea of using \.
Still, I wouldn't limit the expressions inside the curlies. Most languages that have string interpolation allow any expression inside the curlies, and it might confusing people used to how this works for other languages. It is not what you'd expect. Can't we just adhere to what has become a common practice, and allow just any expression inside the curlies? The compiler could easily interpret the code inside the curlies as normal code and move on. Right?
It works fine, but it is insufficient. Code readability suffers with string.format. Also, this is a really small change that Microsoft could add to make the language more elegant. Plus all the other things I have already replied on this topic before (see below).
The term is well known in the computer science world and used by many computer languages and experts: http://en.wikipedia.org/wiki/String_interpolation
It is not because you don't know it, that it is wrong.
Apparently, some uninformed programmer did not study enough.
First of all, it is quite depressing that we can't have an open discussion and still have to face faceless people.
Still, users of languages that have that disagree with you. You might not be talking to any of them, so I deeply encourage you, if you can leave your anonymous house. They find it quite useful, as it really is. Also, this is the 6th most demanded feature in C# in uservoice. Right now, up to 358 people may disagree with you as well.
Also, it does make it more readable, it may allow to specify format if we specify it this way, and it can be made equally powerful.
And C# is becoming a scripting language as well, please see project Roslyn. It is coming. But it has nothing to do with that, this feature has nothing to do with scripting. You might need to work on a few different projects and platforms to realize that.
You can still interpolate resources using string.format.
But I see no reason to use resources for a single language app, as most of them are. It would be naive to believe that this is not a common use case, we should optimize for it, not fight it.
It is not as readable as it is in string interpolations. When you have small string like that it makes little difference. Take a longer one with several placeholders and you are going to take longer. So why not have the language to help?
Also, the compiler could make some smart guesses. Noticing a large string and several concatenations, the compiler might use a StringBuilder instead of doing a string concat.
String templates are options, but first, not everyone uses them (and you are not the one going to force them to do it), and second, they do not fit every scenario.
We could maybe try a new string delimiter for strings with interpolation, instead of double quotes.
Maybe something like the pound (#):
var c = #This list has $(list.Count()) items.#
Or any other delimiter that makes sense, like %, $ or maybe used with the double quotes, as the @ is currently used:
var c = $"This list has $(list.Count()) items."
Another option would be a compiler directive that would be turned off on project migration, but turned on for new projects.
Trevor, you actually could write a proper date:
var a = "Now is $(DateTime.Now.ToShortDateString()).";
This would be parsed by the compiler and the IL was reversed engineered would look like:
var a = "Now is " + DateTime.Now.ToShortDateString() + "";
or maybe something using a StringBuilder.
There is no reason this should be debug only. At least no more than String.Format.
A LOT of language designers disagree with you, and a lot of developers as well, as we see on the voting of this idea, currently the 3rd most voted one.
I, like them, believe it makes for cleaner code. The big advantage is that you are not restricted to string.format or console.writeline, you may use it in any string. And you may reference the variable by name, not by index, as in string.format. And not need to call any methods.
Yes, yes, yes, yes!
I am so happy!
And it is not just DVCS, it is the best one on the market. Microsoft adopted Git!
This is a suggestion to TFS, not to Visual Studio, so I'm not suggesting using plugins on VS, but for TFS to support DVCS.
Git-TF is a good start, but the server is still a central one. This has imposes several restrictions on what we can do. We need real DVCS support from the server.
The suggested feature is to add DVCS support to TFS, not to Visual Studio. I don't really care about VS support, I use git or mecurial on the command line, and yes, there are several tools that do this already.
You can't vote anything down on uservoice. Only up. It is a voting system. And apparently people disagree with you, as this is the second most important feature for TFS currently on uservoice.
Kudos for democracy!
Matthew, I saw the git-TF. Good job, BTW.
And I continue to look forward to a full DVCS in TFS.
I am not arguing anymore... I know that it is possible to enable this. And time will prove me right.
Last time I checked, gittfs folded all my git commits into one big TFS commit. This makes the tool useless to me. Also, I don't think I can work decentralized with other peers, pull from each other, etc...
You don't *need* to have several repos for qa, dev, prod, etc. You may use regular branches, as you would on a CVCSs, as branches are supported in the DVCS model. But you *may* do so if you want. I completely disagree that using branches is better, I prefer using other repos, but only DVCSs support both models. Don't assume everyone prefers your way. I already exposed why I think branches are not the best option for this scenario on my previous comment.
Creating a branch to share code with a small subset of your team is just waste of effort and it pollutes the repo. What do you do after your work is done? Delete the branch? Also, the source code line is going to be with several old branches that don't serve any purpose anymore.
US, Europe and Urban Asia is not the whole world, please look around and you'll actually see that a lot of development now happens outside this markets. I won't even go there, I myself am not there, and I can tell you that my city (Sao Paulo, Brazil) tops the number of developers in cities like New York or London easily.
The concept of DVCS is that there is no central repo, and anyone can act as a node. This is doable on TFS, where you would have one of the nodes to act as the canonical reference, and the one where we do builds and take reports from. It would still be decentralized, as I would be able to share code with a coworker without having to push it to the server. This is very useful when you are working on a feature that is not yet ready to be shared with everyone, but that a small subset of the team is sharing. This is very helpful and is usually done for small periods of time, and is not possible in any easy way with CVCSs. Also, I might be working by myself on something that I don't want to share, but I do want to commit. To be able to commit to a local repository means I have repository of my own, a kind of DVCS, and then, why not just enable it?
The idea of a secondary repo is very interesting. Let's say you have a dev repo, and you push your changes there, and then it builds and run tests, quick tests. You might have a different machine that would be your qa machine. When you push to it it also builds, runs the quick tests, but also runs the more thorough tests, slower, integrated ones. When it is done testing and everything passes, it pushes the build to a QA server(s) where the QA team would be able to test. This is doable in CVCSs, but only with branches. In reality, we don't need dev and qa branches, we need dev and qa repos. We need branches for v1, v2, v3, etc... or maybe to control different customer versions, etc. Using branching to control how ready you are is pushing the idea beyond where it should be.
Also, you assume an all time connected world, and this is not possible. I am very used to see a situation where people travel a lot, and don't want to use their lame hotel connections to be able to commit. A 1 day interruption of internet or connectivity would stop tens of development teams. This does not make sense.
Also, please consider the idea of being able to start a repo easily anywhere. I have been to events where an idea flourished, people started a git repo and commited there, then shared the repo with history through a pen drive. This is not doable at all with a CVCS.
The idea of DVCS enables scenarios that did not exist until it's creation. I could argue that the idea of a central server is the one that is as old as computing itself.
I do understand that most companies have reliable networking, and people are online most of the time. Still, with a CVCS you lose the ability of easily move code around repos, ease of creation of repos, team sharing, etc.
Now I understand what you meant on 2d. It is already in works for TFS 11.
You are assuming that github/hosting off-premisses is the only option. You can host it on premisses with security, and it works perfectly.
Also, please don't assume git when I say DVCS. Git is one of them, not the only one.
Hg supports the git branching model and also a model similar to SVN/TFS. And it is distributed. So, no problems there, plus you get the additional feature of not really needing to branch if you just need to experiment, allowing you to have a totally new workflow, just impossible with current centralized systems.
Performance is a problem in TFS, and it will be a problem anywhere where latency is a problem. P4, TFS, SVN, it doesn't matter. I have seen "fast" centralized version control systems that, when they are on a slow network they become slow. And the internet is a problem, as it is the media where WANs go through. I have seen 300ms latency WANs that make it very hard to work with CVCSs. With a DVCS you minimize the problem, as you may checkin offline, and only when you push you'll need the network. And you may do so from a local cache, or from a peer, making everything faster. Also impossible when using CVCSs.
It is no wonder that DVCSs use a primary ("default" is the right name) repository. The difference with DVCSs is that you can have a secondary, tertiary, etc, repositories, impossible with centralized control. So yes, there usually is a central repository. But it is not required, and you may have more than one. For exemple, one for dev, one for qa, one for prod. Impossible with CVCS, as well.
When you say DVCS doesn't support security, what exactly do you mean? Do you actually believe that all git or hg repositories are insecure and anyone can pull or push to them? Maybe you should check your facts... Also, even if that was true, there is no reason Microsoft couldn't make a secure DVCS.
The branching model is no more confusing than it is in a centralized system. Actually, you need to branch less in a DVCS because you can, for example, do a quick experiment locally without ever pushing a new branch to the server. If you say it is confusing, you should say how it is confusing. Only saying it is confusing is like saying it is ugly. The same goes for other claims you don't explain.
And saying p4 is faster than git is a joke. It is not, and many benchmarks show that.
Centralized don't allow you to work offline currently. You can't check-in offline. If you could, this would be a nice improvement, as well. But isn't this just approaching DVCS from a different angle?
And 2d you mention is already default on current version.
Items 2 and 3 are already in the works for TFS 11.
Alfred, it is on the roadmap, but we don't know for when. We should vote to get this up on their priorities.
Under review by ALM Rangers.Giovanni Bassi gave this 2 votes ·