2 votes0 comments · Azure DevOps (formerly Visual Studio Team Services) » Release Management · Flag idea as inappropriate… · Admin →
I just came over to suggest the exact same thing. There are times when you are making a code breaking change and you just need to test it on one unit test before committing to the pattern of change that you think will work.
As long as the current unit test file compiles, then build the test runner and let me run the single unit test.
You know, in fact, this could be more generic and would help increase the speed of running unit tests. Why not build a unit test runner out of just the single unit test file when ever the user requests running a single unit test with ctrl-r/t . This should make things so much faster because you aren't linking and loading all the other unit test files into the test runner.
I recently had to break apart my unit test project because at 5000 unit tests in the project it took forever to recomplie (link?) and load just to run a single unit test. So if the system would recognize that it only needs the current file I am working in, it could compile and link just that single file and run the unit test. This would satisfy the "run and ignore compile errors in other files" as well as speed things up.
Oh and if MS is reading this, the message in the dialog box that comes up could have clearer wording or more explicit instructions on how to change the setting. now that the previous bug is fixed, the wording is almost good enough, but maybe change the last sentence from "Set the executable project as the startup project." to "Set the executable project as the start project by right clicking on the executable project in the solution explorer and select 'Set as startup project'"
I have been shown a solution to this. I am pretty sure that in previous versions of the IDE there was a bug that prevented the below steps from working properly, but I just tested this in 15.6.3 and it worked.
You can right click on the project that represents your executable. On the menu that comes up, you can select "Set as startup project". What this does is change the solution setting from "Current Selection" to "Single project" and sets the single project's target to the project you selected. From then on no matter which file you have selected, it will start up your application.
Like I said, I am positive that this didn't work in fairly recent older versions because I tried this many, many times, but it works now.
If you have an older version where this doesn't work, you can achieve it a different way. You can right click on your solution and select "Set startup projects...". This will bring up a dialog where you can change the selection from "Current Selection" to "Single project".
Hope that helps.
Please, please, please do this. I tell VS to F@$&-Off every time that stupid dialog box comes up and it comes up A LOT.
I run into this many times a day. Once I finish working on my unit tests for the back end, it is time to run the application so I can start working on the front end. So I go hit Start without Debugging and BAM, I get this stupid, completely avoidable dialog box getting in my way. Then I have to go hunt for a non-unit test file to make active so Start without debugging can do the right thing.
Sorry for the rant, but this causes me such anger and frustration for such a small thing. And the fact that I run into it so often just makes it worse.
I went and removed my votes from other items so I could put votes here.
I just did some googling to figure out which is which and I found this article https://docs.microsoft.com/en-ca/vsts/git/tutorial/merging?tabs=visual-studio that shows a screen show of a branch merge operation where Source and Target are indeed the branch names. So it seems that you guys already do what I am asking for when you are doing a git merge, but not when doing a git rebase.
Yes please add this capability. I just added webpack to my project and I need to run the production version of webpack before all release builds, but I don't need to run any webpack before a debug build because we are using the webpack-dev-server to handle that. I also need it because I need to create the bundled js files before doing a publish to azure.
This is a really important feature. I am going through updating 50 packages and I just happen to know that two of them include breaking changes, but what about the other 48? Without release notes I have to go track down the package website and try to figure out the difference between the version I have and the version that I am pulling in.
And, the package manager most often doesn't include a link to the packages website where I could get that information so I have to go hunting in google to find it.
Please, consider putting a link to the release notes for this version.