As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
You're in Visual Studio... you press F5 (Run) and are greeted by this dialog:
There were build errors. Would you like to continue and run the last successful build?
Wonderful.
I'm sure there are cases where running the last successful build is useful, however, I have never purposefully answered yes to this question. Oh sure, I've clicked Yes plenty of times, and waiting in frustration for the first opportunity to undo my blunder, but nothing more.
So, have you ever found this feature useful? And if so, under what circumstances did it become helpful for you to be able to run the last successful build of your application?
How often do you accidentally click Yes and kick yourself while waiting for the app to start?
In VS2008 there are the following options you can set to change the behavior (not sure if there are similar options in other versions of Visual Studio):
Projects and Solutions/Build and Run
- On Run, when projects are out of date:
Always build
Never build
Prompt to build <== default setting
- On Run, when build or deployment errors occur:
Launch old version
Do not launch
Prompt to launch <== default setting
Set the above options to "Always build" and "Do not launch" and you get what I consider a more ueseful behavior. Though sometimes when I try to launch the debugger and there's a build error it takes me a few seconds to realize why I'm not getting to the breakpoint I thought I'd be hitting (it might be nice to get some sort of 'toaster' type of message to knock me out of my stupor).
This behaviour can be defined under
Tools->Options->Projects and Solutions->Build And Run->
On Run, when Build or Deployment Errors occur
here you can select:
- Launch old version
- Do not launch
- Ask to launch
This can be useful when you debug a web application and one of the pages does not compile, because some other developer checked in a bad version, or you can't check out the latest code for whatever reason, but you know you will not hit that page. I do it all the times.
Interesting. I've actually never seen that dialog - I know there's an option to enable/disable running the previous successful build, so perhaps it shows a dialog first. You can look into disabling it if you won't use it.
One reason this can be useful, however, is if you want to remind yourself what the bug was that you were working on. Not all things can be fixed in edit-and-continue, and you might need a memory jog.
It's also helpful on web applications, because it will force the cassini servers to start. You need this if you are working on one project in the solution that won't compile, and you need to refresh the web services in another project.
When using VS 2008 Express, there is a box to never show this dialog again. Just tried it and it will take away the dialog, leaving only a build failed message in the bottom left hand portion of the screen.
As for how often do I hit it, quite often. Frustrating as sometimes I have changed the code complete while testing things and will get something completely unrelated to the task at hand. Not sure when Microsoft figured this would be useful.
It works on the preference of selection of appropriate dll on runtime. Executables are not generated if there is any built error so the compiler looks for the executable which is existing which is obviously the last successful compiled.
Related
Lately, VS has been getting more and more annoying about warning me about editing code while debugging. Regardless of whether it is a popup telling me that a file has been edited, purple underlining, or a warning that gets grouped with the compiler warnings and errors, I don't want it. I wish it would just let me edit, continue running the program that was built, and keep quiet about it.
Is there a way to tell it to do that?
Incidentally, I have already disabled edit and continue. See Edit and Continue: "Changes are not allowed when..."
You can apply changes to the source code in debug mode when you stop at a breakpoint.
Manual: How to: Apply Edits in Break Mode with Edit and Continue (Visual Basic)
This is a workaround but some workarounds, well, work.
Run two instances of VS on the same solution. Debug one and encounter needed edit. Ctrl+TAB to the other instance and make the edit (without saving... by the way use auto-save). Continue until you’re done, and then save the files in instance 2. After debug, the changes are available to both instances.
Rarely (at least in my experience) do you actually want edit-and-continue; usually you’re watching the code under debug and realize it is wrong and want to fix it, but also want to see some downstream effects without killing the debug session.
This gives you that with a minor inconvenient task switch.
I have a really strange problem with my Visual Studio.
I usually press CTRL + S pretty often (call me paranoid, well however I got that habit some years ago now and I really don't want to get rid of it :-))
Now I had the issue that I was editing one file, changing a few dozen of strings according to a spec I had open in Word; so I switch around these two tasks pretty often, make one or two changes and then save.
The odd thing is, every once in a while, after saving, my file is suddenly in read-only-mode, so I cannot navigate through my changes (CTRL+Z/CTRL+Y) and have to reopen that file to continue to code and pray.
Indeed it feels random to me when this occurs:
sometimes I only change 1 thing and save and then it's immediately read-only,
well in other cases it will let me edit several things until it is stuck.
Someone else also experiencing this and maybe got a tip?
Maybe I hit some magic hotkey or something?
My bad, please check if your projects folder is not a synchronized one, so when you edit (change) your project, the backup tool starts to update in remote location for synchronization purposes, so locks the file.
The answer to this problem is most likely that you are currently in Debug mode - i.e. the application is being run. Click "Stop" and it'll allow you to edit the files again.
By default, you cannot edit source files while the Debugger is running.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a bit confused about a pull request I did on a fairly large open source project I use in my work. I won't reveal the project, but it contains a large collection of mostly user submitted scripts that are used to monitor various aspects of a mission critical system or application. I found a user-submitted shell script that I needed to use for my own work, but it had several major bugs, and was stylistically a wreck. I fixed the bugs, and refactored almost the entire script, bringing it up to a fairly clean "bash form". I did a pull request on the script, and the project lead rejected the patch with quote:
"This is mostly coding style changes. Your effort is really
appreciated, but we won't get anywhere if we start accepting that kind
of patches. Please try to focus on the matter, i.e. stuff which really
needs fixing. Thanks!"
Here's an example of a bash coding style change for readability I made throughout the script:
- start_time=`date +%s%N`
+ start_time=$(date +%s%N)
Is this common on open source projects? Most projects I've committed to were my own, and I refactor stylistically bad code all the time. If code will be used by other people like the script in question, shouldn't a usability refactor be welcomed? I'm just a bit confused, as the project has no coding style guides.
Did you split the patches so that the bugs are fixed first and the style changes made later? If not, I'd reject the patch as well. A patch that changes logic should be as small and self-contained as possible. Nobody wants to go through dozens of style changes to ensure they have no effect on the logic when trying to understand what you fixed.
This is absolutely not a universal thing among open-source projects. I'll just give one counterexample, from a recent pull request:
https://github.com/djcb/mu/pull/65
My pull request related to the Emacs component of mu, called mu4e. My only changes were to make many more variables from the project available to edit via M-x customize (the Emacs equivalent of "Edit -> Preferences", or "Tools -> Options"). There were no changes to any of the program logic at all. As you can see, the pull request was merged without any fuss after just two hours. (I had never contributed to this project before, so I didn't get fast-tracked based on my past contributions or anything like that.) So that's one example of a pull request of only cosmetic changes that got happily accepted without any complaint.
As to why the project in question rejected your patch, maybe they're just being stubborn or too proud to let someone else mess around in their code or something like that, but on the other hand, there are valid reasons not to merge cosmetic non-user-facing changes. If they accept your code and they are at least minimally responsible, they will have to at least look at all the changes you're making and make sure you didn't break something, and make sure that your code changes match what your commit log says that you changed. I'm guessing that your pull request changed a whole bunch of isolated lines or blocks throughout many files, right? That's probably what you'd end up with if you did a blanket search and replace of backticks with $(). That kind of patch can be hard to verify, because you look at the same change on line after line and your eyes glaze over and you miss the one case where the close-paren is missing which causes the entire project to break.
The point is that even though you're giving them code for free, actually merging your code is not free, and the work involved in integrating your code into the project must be done by the people who run the project, or else they will be merging code that they can't trust. In some cases, the people who own the project may look at what your changes claim to improve and make the rational decision that those improvements do not justify the effort required to merge your code in a responsible way. If you disagree, you're free to create your own fork (not a "hostile" fork, just a run-of-the-mill "Project X with my customizations" fork) and put your changes there, and use them yourself. If your changes are really worth having, people might start switching to your fork, at which point the original developers might reconsider their position and merge your changes after all.
Each project has its own rules and guidelines. You've been told that this project works to different rules from the ones you'd work to. If you want to contribute, it sounds like you'll have to follow their rules. (I tend to be on your side in the debate — but when I'm not in charge, I go by the rules of those who are!)
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm trying to update Extensions in Visual Studio 2010, and I am suddenly getting errors. I open the extension manager and let it load the list of updates. I select one, and click Update, but I get a dialog with an error. One of two errors occurs depending on which extension I am trying to update.
For example, trying to update Nuget gets me:
Value cannot be null
Parameter name: v1
Code Maid, on the other hand:
Invalid entry to install/download
Parameter name: entry
Ankh SVN gives me the same error as Code Maid. (Haven't used or updated Ankh SVN in quite some time, but I tried it to see if it worked)
I am not aware of any recent changes which I have done which could have caused this. The only thing which remotely comes to mind was installing VS11 Beta, but I'm fairly sure I've updated VS2010 extensions since then successfully.
Hopefully, I can avoid the Dreaded Reinstall ™
I appear not to be the only one with this problem:
http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c/view/Discussions
Incidentally, I was able to update the extensions in question by downloading and executing the installers manually. But I would still like to know what's going on here, of course!
Not really a full answer but I think I can help in regards to nuget issue:
In Control Panel -> Programs find and uninstall Nuget. (Make sure VS isn't running)
Go to http://nuget.org/ and click 'Install Nuget'
On the next page click Download.
Open the downloaded file (it should be associated with VS).
Follow the wizard.
This should install the latest version of nuget which means there will bo no update available. I'm not sure what will happen when next update is out.
I realise it's only a workaround.
Edit: Sorry, just noticed that you did exactly that.
Here is the hotfix for that issue.
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=38654
Worked like a charm for me.
Try loading DevEnv in /SafeMode and installing from there. I can't tell you what's going on, but VS does get itself knotted sometimes, and just needs a helping hand.
I've had similar issues with NuGet especially in the earlier versions (pre 1.4 I noticed most).
1) If it's listed in Programs and Features, remove it there.
2) open "%PROGRAMFILES (X86)%\Microsoft Visual Studio 10.0\Common7\IDE\Extensions", if Nuget is listed, delete it.
3) go to your users directory (c:\users\xxxx\AppData\Local\Microsoft\VisualStudio\10.0 if Nuget is listed in there. Delete that. Close/Open VS. See if the error persists, if so. You can try the /ResetAddin flag from the command line to see if something else was interfering.
If the error doesn't, re-install Nuget 1.7 (or latest) and hopefully all is well.
You using Telerik Extensions at all? The Silverlight stuff hosed me royally.
I get this when I have a WiX project open in my solution and go to update manage packages for the entire solution. If I right-click all of the WiX projects in my solution and unload the projects, then I can get update the NuGet packages fine. Then I reload the WiX projects.
I imagine it might occur for other "weird" project types as well. Something to try!
I have a VS solution containing several projects. While debugging a particular project all the source files are locked by VS. I would like to unlock sources that the debugee doesn't have dependency on. Is there any way to do this within one solution?
UPDATE:
I'm using Win XP SP3 32bit. Visual Studio 2010, C#. Edit and Continue is enabled. The solution contains 6 projects (number in not important actually), 5 of them depend on the data access layer project which uses Entity Framework. None of the 5 have any mutual dependencies. They are WinForms and Console applications. I would like to be able to run one of the projects and make changes to others without stopping the first. The problem is starting and stopping the project take considerable amount of time.
The Edit and Continue feature is preventing you from editing files if the debugger hasn't stopped the program. The simple workaround is Debug + Break All, you should then be able to edit the files, your changes will be immediately effective provided your changes do not violate the restrictions imposed by E+C. This is the most efficient work flow.
The heavy-handed approach is to disable Edit and Continue. Tools + Options, Debugger, Edit and Continue, uncheck the Enable check box.
I don't think that there is a way to avoid that. While debugging Visual Studio lock all files to prevent any change on them, including those on other projects.
You can try to open the project which you are interested on with another Visual Studio instance to make changes to your files or open files singularly with another editor.
This doesn't quite answer the OP's question per se, but for anyone who has stumbled upon this page in the same (very frustrated) boat as I am, this might help.
The solution: start without debugging.
It was driving me absolutely crazy that Visual Studio would not let me edit files while the app was running. My typical workflow is:
Make some changes
Run the app to see the effects of those changes
Based on the results, make more changes, etc. etc.
The problem is Visual Studio was preventing me from step 3. It demands that you STOP running the app before you can even make any changes (including to a XAML file or adding a file to the project), which also means that you can't go back to the app to double-check something while you are actually programming it at the same time (which is how I work, bro).
Thank god I finally discovered if I run without debugging it doesn't impose this ridiculous limitation. It's still a pain in the butt if you actually need to debug something you have to re-run the app in debug mode, but it sure beats having to kill the app before it will even let you edit a file.