Visual Studio testc, how to get rid of it? - c#

I could have asked this question years ago, but I think it has finally annoyed me enough to ask this question. Many times while I am coding, Visual Studio tries to Intellisense my deal with testc. I know that testc is a snippet for a test class, but it is something I will never use in anything except maybe a test project, and likely not even then. So, how do I prevent this annoyance from ever appearing in my Intellisense options again? Yeah I know... stupid thing to worry about...

On the Tools menu, click Code Snippets Manager.
Select the directory Test.
Click Remove.

Press CTRL + K, CTRL + B. This will bring up the code snippets manager. In the Visual C# directory, you can remove the snippets (testc in your case) that you don't want to include. Note that system generated snippets cannot be removed by this method, although per mojits answer you could remove the entire directory of snippets.
One way around this is to delete the snippet file manually, by finding / deleting its actual file. I am using Visual C# express 2010 right now, and this is the directory they are in for me (you may have to modify slightly, and restart VS for changes to take effect).
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC#\Snippets\1033\Visual C#

Related

Locking files when building in Visual Studio 2010

Hello there, Stackoverflow.
Recently, when I've been programming in Visual Studio 2010, I've been getting the problem with VS locking the bin/Debug/(ProjectName).exe file when trying to build and gives me the error below after trying to build the project 10 times:
Unable to copy file "obj\x86\Debug\TileEngine.exe" to "bin\x86\Debug\TileEngine.exe". The process cannot access the file 'bin\x86\Debug\TileEngine.exe' becuase it is being used by another process.
The problem appears when I edit the source and then try to Debug.
I've checked using different programs, and the only program using the file is Visual Studio.
If I wait for about 10 minutes before trying to build, it seems to work properly, but when trying different things, it isn't good needing to wait 10 minutes before trying something.
I've tried different solutions both on this site as well as everywhere I can find on Google.
Some solutions I've found, but haven't worked for me
Solution 1 - Using a pre-build script
In some different questions here on Stackoverflow, I've found one solution being that you go into Project Properties > Build Events and then in the Pre-build event command line add:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This made it possible for me to build the project one more time than I usually could, but when editing the code again, and then building, the same error appeared.
Note: Trying to build a release instead of a debug build seems to break the pre-build script and it exits with the code '1', which seems to make VS unable to build properly. Removing the pre-build script makes it work like "normal" again, still with the same error though.
Solution 2 - Running Visual Studio as Administrator
This is another solution I've found, but havent worked either for me, so I assume that Visual Studio already have all the permissions required and running as Administrator doesn't actually make any difference.
Solution 3 - Changing the AssemblyVersion
In this question, Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug, I found another solution that included changing the AssemblyVersion, in the Properties\AssemblyInfo.cs file, to "2.0.0.0".
This, however, haven't made any difference whatsoever for me.
Solution 4 - Closing UserControl designers before building
According to some different answers here and there on the Internet, Visual Studio apparently uses the built project executable to render the UserControl designer(?). In my case, this is probably not it, though, since I use XNA mostly and it doesn't use the UserControl designer.
Solution 5 - Cleaning up resources when application quits
This might be a solution that I have failed to implement properly. I'm just thinking though, that if this is the solution, how come I haven't been required to do it before. I assume XNA unloads everything that gets loaded through the Content pipeline, therefore this solution wouldn't' make any real sense.
If there is anyone that is able to spread some light on this issue, it would be really awesome, as it is stopping me from programming anything really, because I don't like waiting for 10 minutes because I've made a 2 second change all the time.
I've run into this problem a few times myself.
Mine might not be from the same cause as yours, but I'll tell you what went wrong with me and how I fixed it, hopefully it'll be helpful to you.
Basically, my program never fully exited properly, even when it appeared to. It would continue to run, and thus continue to lock down the file.
A quick dirty fix I used initially (and a way to prove if this is the case) is:
Open Task Manager (Ctrl-Alt-Del)
Click Processes tab
Look for your program's name (TileEngine.exe)
Note: There will probably be name_vshost.exe (TileEngine_vshost.exe) That's a VisualStudio thing, ignore that, it's not relevant.
If you find it, it means your program hasn't actual exited fully.
If it's there, click on it and press "End Process"
So if it's there, then for some reason, your program didn't shut down, like mine did.
Often, this is from a thread being launched and forgotten, or an Async task that never completes, or something like that.
Make sure in your OnExiting(..) void function that you kill all running threads.
If your program is still running despite best attempts to close all threads and other blockers, you can use the very dirty bad method:
In OnExiting(...) run the code "System.Diagnostics.Process.GetCurrentProcess().Kill();" - this will taskmanager-style forceshutdown the current process... this is only as an emergency I-can't-make-it-work-any-other-way method.
I think I found the solution myself.
In the Project Properties, "Enable the Visual Studio hosting process" wasn't checked. Checking it seems to have fixed the problems, at least for now.
Got reminded of it from mcmonkey4eva's post. So thanks for that =)
And thanks for the other replied I've got. Stackoverflow is awesome!
Have you checked if any files are being blocked by your firewall? When I switched to the full version of Avast I find I have to disable the File System Shield It loves to remove my executable files when I try to run my visual studio projects.
I had problems when upgrading to VS2012 Professional. (SDK, .Net, Visual C++ Redistributable package)
ENSURE ALL OF THESE ARE COMPATIBLE WITH THE CURRENT VERSION OF VS YOU ARE USING
What I did, was I ended up uninstalling EVERYTHING that was associated with both Visual Studio downloads. If you are able to remove and save your project files elsewhere and then bring them back. Go through all your program files to see if there is anything hidden in the wrong folder and check your C drive.
Which meant downloading and reinstalling (fresh):
I think if you clean out your program files, it should be ok. I wouldn't recommend going into your register unless you are very sure of what you are doing. IF you have already made changes to the register then we'll have a look at that and other options (if this doesn't solve your problem).
Try removing the readonly check from your solution by unchecking at the folder level.
I ran into this problem and in my case was due to having bin included in the solution; as soon as I excluded the bin folder from my solution the problem went away.
Nothing helped, not prebuild commands, neither designers closing, but I figured out a way that helped me, just changing from debug to release and vice-versa releases locked files and you can delete them without closing the IDE.
I regularly get this problem if I switch from Debug to Release and then immediately F5 to compile. Crazy as it sounds, waiting for, say, one minute after switching between modes will prevent this.
If it's locked, the only solution is to close Visual Studio and re-open.
I solved this problem organizing my resources on solution. I noticed this error when I put some images on my application at the same solution folder.
So,
I'd removed all images and resources from app, save without it.
Moved the images to outside Solution folder.
Open the solution and add this images again, using "Import" button at controls.
If you will try this, remember to do with Application Icon, on Project Settings.
Now, everything is working fine for me.
I hope it helps.
You need to disable Windows Indexer as it locks up the file
Follow this Guide how to disable
In my case the problem seem to be caused by the remote debugger. It starts on local machine when you compile with "x64" option. Try to change the project setting (properties/buid) until you reach the final version.
Change Build Platform target from x86 to Any CPU.

SpecFlow: "Step bindings are still being analyzed. Please wait."

I keep getting the same message whenever I right click a scenario and "Generate Step Definitions" or "Go To Step Definition".
It worked the first time I tried, but it hasn't since.
I've filed a bug report, but in the mean time, anyone know how to solve this?
Over five years later and I'm getting the same problem... Here is the solution that worked for me:
Close the solution in Visual Studio.
Go to your temp directory in Windows Explorer (enter %temp% in the location bar).
Delete the 'specflow-blah-blah.cache' file.
Reload the solution in Visual Studio, rebuild the solution and give SpecFlow a bit of time to sort itself out.
ive gotten this issue before, we have about 800 SF tests in one of our projects and when we first load it can sometimes take quite a lot of time for it to load up. For me its always sorted itself out eventually.
Another thing to try would be to upgrade to 1.9 which came out a few days ago, it may have improved performance.
Although I'm using the last (1.9.2) I had the same problem. Re-opening VS2010 solved the issue.
I've found a work around for this problem; close the solution and delete the .SOU file. Re-opening the solution then re-creates this file and the SpecFlow context menu options then work.
I got the the same issue when I moved external assemblies to specflow.json file from app.config
1) Turned out that I got an assembly reference which didn't even have specflow nugets.
2) I renamed one assembly, but for some reasons the old name wasn't replaces in AssemblyInfo.cs file. I changed it manually, cleaned the project. Cleaned the specflow cache (see previous answers how to do this) and it worked.
So, check if all the references and assembly names are correct.
Cheers
P.S. Don't forget to setup "Copy to Output Directory" option for specflow.json :D
If you are still unable to force the steps to bind, but just need to get to the definition of a given step:
Place a breakpoint on the first step of the scenario
Debug test
Step into the function (F11 by default)
There you are! VS navigation may not work but the debugger knows the way:)
I get this may not be a direct solution to the original issue with steps not binding, but I think it gets where the OP wanted to go...
The root cause of this issue is your code has poor performance and that cause the slowness and hangs your Visual Studio or due to low performance of code Visual studio moves in unresponsive state.
The solution is improve the performance of your code. You need to optimize your code in all the possible ways:
Use less inputs in each step
Use less parameters in your parametrized methods
Avoid unnecessary loops
Divide the number parameters into more methods if taking more than 5 parameters. It will improve the performance.
Divide the input values into more sub-step or separate steps, it will improve the performance and speed of the code.
Use switch case instead of if else statements if there are more cases.
Free up the occupied memory if the reference variables or objects are no more of use.
Read data from external sources and store them into objects or lists locally and minimize make it one time read from external source once and access the values copied locally in the lists or any other objects/variables.
Close or quite the external files or call to them after use.
Hope this is the best way to improve the performance of code and this issue will not happen for sure and your steps bindings and definition will be more smooth and easy.
We fixed it like this:
close Visual studio
Deleted the obj and bin folders under the project(s),
open Visual studio again.
rebuild
After that the .feature files "came back to life"

C# - Visual Studio project build

I have the following problem.
I made an application in C# (using Visual Studio 2010). Everything worked fine.
Then I had to make some changes in a "main.cs". Did those... all fine again.
Then I had to make other changes in same file. Did those... cleaned the solution built it. The problem is that when I run/debug/anything the application I get the same result as I did before I made the changes. I even tried to break the code (called a random function that didn't exist, used wrong syntax), but the result was the same "Build successful" and the old version.
Is there some kind of cacheing mechanism or something? How do I get rid of this problem?
I added prints for the "compile" solution... I can't find the build property.
Try deleting the bin and obj directories in the Visual Studio project directory. The obj directory contains the temporary files used to create the binary while the bin directory contains the binaries for that project. In addition, check if there are any warnings being shown when you build your solution.
I was able to reproduce the same error i.e. build successfully even though the file has not been compiled. The Build Action of the file had not been set to Compile.
The correct Build Action for a code file (main.cs) would be Compile.
According the updated question the file properties does not have the compile option
The reason for this is that the file (main.cs) has not been included in the project, but the "Show all files" button is "on" in the Solution Explorer. The file has not been included in the project (hence not compiled) and the file icon is greyed out in Solution Explorer.
To include this file in the project, right click on add existing item to the project (see following image). In the subsequent dialog select the file (main.cs) and click on the add button.
This should solve your problem.
In future, it is best to keep the "Show All Files" button as "off" to avoid confusion.
Is it possible you have selected the build and run last successful version? Check out my answer to something similar here. If the changes you made broke something and you had checked the boxes and hit yes to the dialog boxes in my answer below then that's most likely the issue.
Cannot see changes I make when I run my application in Visual Studio
Make a backup of your solution.
Delete the .cs files from within the solution explorer. If your program compiles and runs, than you are linked to source folders and not actually using the one in your solution.
I doubt this is it, but worth a try. The other things that came to mind you have already eliminated out with the previous answers.

Code changes not being included when compiling in Visual C# Express 2010

At seemingly random times, whenever I load up VC# Express for the day and start working, any changes I make to my code don't get reflected in my debug runs. It's as if VC just refuses to compile the code and just runs the old already-compiled version. Deleting the "bin" folder in the project directory doesn't help, as then VC just complains that it can't find the *.exe instead of recompiling. Doing a rebuild helps, but only for that one rebuild, so I'm continuously having to rebuild the solution to see any changes, which is really slow.
The only way I've found to get rid of this problem (for maybe a week or two) is to create a new project and manually copy over my code. Needless to say, this is really frustrating and tedious. Is this a documented issue? What can be done to fix it? Searching online doesn't really turn up any answers, as the search terms most applicable to the problem bring up a lot of noise results.
You might see if the project you are working on is set to Build when the solution builds. To check this, right-click your Solution and go to Properties. Click the Configuration Properties node on the left and make sure all of the projects you want to build are checked on the ride side for your given build type.
UPDATE: Also, what is the timestamp on your build files? Is the timestamp getting updated on your build?
I had this problem when working on a network drive, and the time on the server was out of sync. Linux+Samba accessed by Win7 Pro and VB 2010 Express.
Correcting the time-difference solved the issue.
click on BUILD-->REBUILD SOLUTION and you are now good to go

Long load time in Visual Studio for Large Project

Is there a way to turn off intellisense in Visual Studio 2008? I know about deleting a DLL to turn off intellisense in C++, but that doesn't work for C#. I also know about the preferences but that just turns off the visual display. I want to turn off ALL of intellisense so it does not scan my code at all.
Update 10/14/09: Eric was kind enough to take a look so I sent him some log info. I'll post the resolution here when we get one.
Update: updated title to reflect the changed direction of the thread
Related Question
Turning off Intellisense for a single project in Visual Studio 2008
The guys on the VS team looked at this for me and found a problem with intellisense. Here's their description:
"It looks like both of the files you gave me contain a part of static partial class EntityPropertyDescriptors, and I would guess that all the rest of the 500 files do too. What’s happening is that as we build up our IntelliSense cache, each time we parse one of these files, we see that it has a static class in it, and we decide to see if that static class has any extension methods. In order to look for the extension methods, we look through each method in each part to see if it’s an extension method. This causes us to reparse every file in order to see if the type has any extension methods."
They found a similar problem with VS2010 but are fixing it now. Unfortunately, they are not going to fix it in VS2008, so we are left with the workaround of putting all the partial classes into a single file. They can still be partials, but they must be in the same physical file to get around the problem.
After combining all partial classes into a single file, load time for this problem project when from 30 minutes to about 10 seconds.
Big thanks to Eric Lippert and Kevin Pilch-Bisson for helping me with this.
You need to switch off background compilation.
Here is a HowTo:
http://ira.me.uk/2008/09/01/switch-offon-visual-studio-2008-background-compilation/
Tools -> Options -> Text Editor -> C# -> Advanced -> Show live semantic errors
You will still get error underlining, but you must hit the Build button before they show up.
In tools > options > Text Editor > C# there is a Intellisense section which looks like it does what you want.
Have you tried cleaning your solution from all temporary files created by Visual Studio? Sometimes these files could get corrupted, the chances might especially be high if you migrated from VS 2005.
Close your solution, look for all *.suo and *.ncb files and remove/rename them, and then re-open the solution.
Just another thing to make sure: Are there any third-party add-ins installed? Try to start VS in SafeMode using the /SafeMode command-line option.

Categories