Hello guys I have a easy problem but I can't solve.
I open normal project and add something when I try to close without debugging client asks "Do you want to save" but when I use debug then I try to close project client don't ask "do you want to save" just saves automaticially I want to change this options i change a lot setting (tools>options) but I couldn't do it.this situation makes me crazy can you help ?
When you start debugging, it compiles the source code. In order to compile, it has to access the latest version of the files, so it has to save them, else the compiler (another program than Visual Studio) can't access them.
Conclusion: there is no way to change this unless you can change the entire working of Visual Studio and the compiler.
Sounds like you need to look into one of the Source Control options that will allow you to revert to older code if needed.
Related
I am not new to coding and I know I have never had this issue.
In Visual Studio if I just create a .cs file and check it's intellisense nothing works. auto complete for using. does not work, nor does simple syntax checking work (see image)
Am I crazy? Can someone else try this out, what am I missing?
NOTE this only happens when I just have a .cs file for an external script. I just need simple auto complete and syntax checking to work
A C# file is somewhat meaningless without a project file. Versions, references, etc… all depend upon having a build system. This is a somewhat pedantic truth, but it is how VS works. Pathologically, I could have a CS file Console.WriteLine(“Hello world!”); which in one project results in hello world, and in another results in the program formatting a disk.
Add the CS file to a project, or create one. If you frequently come across this issue in some unique use case, visual studio may not be the best editor for the job. VS Code or another more lightweight tool may be better suited.
I often get blue question marks on files in my VS2012 Solution Explorer when opening a solution bound to Perforce through P4VS.
Looks like something is having trouble to "synchronize" with the depot/workspace/whatnot. Hitting "Refresh View" always solves the issue but I'm growing tired on doing this everyday:
This is my VS version:
Microsoft Visual Studio Professional 2012
Version 11.0.61030.00 Update 4
And P4VS:
2014.1.85.4506
This is persistent across P4VS versions for a few months now, and seems to be affecting sometimes individual files, sometimes entire projects, with no apparent pattern.
How can I diagnose what's going wrong, be it a server issue, a VS issue, a workspace issue?... The Perforce Source Control output shows nothing special.
Actually it's not entire folders, it's entire projects. It appears that even if refreshing a project "fixes" the issue for one run, re-opening the solution brings it back. Whereas I think that for individual files, refreshing them solves the issue once and for all. I'll play with it a bit more to confirm that.
To help diagnose what is going wrong you should probably turn on logging, and check the preferences that will show everything in the output window. For the P4VS log, go to:
Tools- > Options -> Source Control -> Perforce - Logging
(This is not the same thing as the Visual Studio Activity log.)
There could be a possibility that you are getting disconnected and refresh reconnects you. I am not sure if you have your connection set to use solution-specific settings, since you did not mention the connection dialog coming up.
This "solved" the issue for me, at least for the entire projects that went blue-question-marked:
1) Tools > Options
2) Source Control
3) Perforce - General
4) Tick the option "Treat Solution/Project as directory when
selected"
Not sure why but that's one less annoyance for me every day. Thanks to Perforce support for suggesting that.
The file is probably not marked for version control. I noticed this icon in one file and opened Perforce to check. For whatever reason, this file was not marked for add in Perforce. After marking the file for add and submitting, the blue question mark went away.
I am working on an Asp.net web application. Since yesterday I am unable to check in my code. But I am able to get latest code, compare files , View history and create work items.
While check in- Neither the error message is displayed nor The file that needs to be checked in is locked.
Suspect:-
The application is written for VS 2010. But,Once I opened it on vs 2012. Later I made necessary changes to the solution file so that It re-opens on VS 2010 again. Can this be the reason why check in is not working? Please let me now if you have any suggestions. Thanks.
"Lock "Check-in". This is also known as the "antisocial":-). A check-in lock prevents anyone else from committing their changes to that file until you have released the lock. This means that they will be responsible for performing any conflict resolution activities that result. You can place a check-in lock on a file even if somebody has a file checked out with a lock type of "none" i.e. I know you are working on this file but you are not allowed to check in your changes until I have made this important quick fix."
Probably this is the case, someone check out the file after your check out. Check who check out the file and contact with him, this is the best advice which I can give you.
I have a very odd situation where by changes committed to the repository by my colleagues when updated to my local copy of the software, Visual studio doesn't recognise them immediately, and reload. the result (and this is very odd) is that most of the times, I will save my changes without the reloaded projects and will overwrite my colleagues changes. It is so embarrassing that sometimes I am asked why I had to change a piece of code and in reality I hadn't.
Another thing is, when I check in some VS project level changes like when someone added a new class, or form or anything and continue to work in Visual studio, it will take me at least 5 to 10 minutes before I get the warning that there was some changes and be asked to reload the project etc...
I think there should be a setting somewhere in visual studio to trigger an automatic reload, but can't find it.
This affect me and another person so far but mine is the strangest as it can take up to 30 minutes before a project start reload.
Any Ideas welcome
This is my settings
If you are working using Source Control, you will need to synchronise your local workspace with the server ("get" the latest code) before any changes by your colleagues will be copied to your PC.
If you don't "get" the latest code before you make changes then you may have to merge your changes with somebody else's, which can be a difficult, time consuming or even dangerous process - especially if you use the default Visual Studio automatic merge process, which usually does the wrong thing, resulting in essentially corrupt code (making it look like you deleted your colleague's works, just as you are describing, for example).
The best way to work with source control is the "little and often" approach:
Get the latest source code before you start any new work, so that your PC is as up to date as possible.
It's usually a good practice to "get" the latest code frequently (e.g. I do it first thing every morning) so that any merge conflicts are flagged up and dealt with as early as possible. The longer you wait before merging the worse the merge process tends to get. (Caveat: Check with your build system that the current version of the code on the server is working before you get it - you don't want to get broken code onto your PC as it may stop you being able to work at all).
Arrange your work as many small incremental steps that can be safely checked in as they are completed (rather than working for 3 months on hundreds of files and then dumping it on the system as one massive change )
When you are ready to check in, get the latest code, rebuild, and re-test your changes to be sure they still work when integrated with the latest program code. Only check in if everything works well.
Also be aware that when you try to edit a file, the source control provider may automatically "get" the latest version of that file for you (which could cause Visual Studio to tell you it has reloaded the file, and perhaps explain why you say it sometimes takes a while to "update", as it doesn't happen until you start editing a new file that has been changed recently by someone else). If this is the case, then the truth is that you have not "updated" the entire set of source code, only one file - in this case you really need to get all the latest changes to the source code (if you don't you may find it is uncompilable or (even worse), compiles but exhibits undefined behaviours due to only part of the code being up to date)
Lastly, a very good practice when checking in your code is to go through the list of files you are checking in and diff them one by one against the latest server code to see what you have changed. This may sound laborious but it confers several benefits:
It reminds you what you did, which can sometimes be helpful for filling in the check-in comment to clearly describe all your changes and make sure you don't miss an important note.
You will easily spot anything that has been screwed up in the merge process - there will be chunks of code that appear to be created or deleted that you know you didn't touch. So you'll be able to discover and fix these problems before you check in rather than annoying your colleagues by "deleting" their changes.
I find this very useful for finding temporary debugging code that I have forgotten to take out before I check in.
Sometimes you may even do a double-take on a bit of code you are about to check in and think "huh? why did I do that?". And then you might decide to re-examine and possibly even rewrite the code you thought was good to go.
Final Note: The options you show in your edit only relate to changes that are made to the files on your PC by another program on your PC. If another user makes a change and checks it in to source control, these options will have no effect. It is only when your Source Control system copies those changes to your PC's hard drive that you might see Visual Studio reacting to those changes (depending on how well your source control system is integrated with VS).
If you're sure the problem is Visual Studio (e.g. the file really has changed on the disk but you don't see it in Visual Studio)
Make sure that the Detect when file is changed option is checked.
Tools > Options > Environment > Documents > Detect when file is changed outside the environment
Since you are sometimes getting an alert to reload your project due to external changes means you already have the settings required to detect file changes in Visual Studio.
However, reloading of project/solution will only be triggered if the .csproj (or .vbproj) or .sln file was changed.
By the way, are you using some version control system? It seems that you are just sharing the solution and editing simultaneously.
In the output window, there are sections called Build, Debug, and Refactor.
When I do Trace.Write("Hello World!");, it goes to the Debug section.
Can I create my own section like that and print data to it? I know there is a way to write a file but I just need to see the output temporarily in Visual Stutio.
I'm not sure if my question is clear or not, but is this possible?
Only Visual Studio addins can create new output sources (those inside the output tool-window), like AnkhSVN does, and many others may also do.
I don't think you can do that from the code being debugged.
You can however try to create a custom listener and add it to Debug.Listeners.
You can make your own output form, with a text-box on it, and make a listener that outputs to that window, or something similar.