I just downloaded Visual Studio Code and my Intellisense is not automatically working.
The two settings that control this seem to be set correctly:
"editor.quickSuggestions": true,
"editor.suggestOnTriggerCharacters": true,
I do get an Intellisense menu when i start typing and press "CTRL + Space", but this gives me a list of everything and not things specifically for my object.
What am i doing wrong?
If you have a workspace and for some reason have multiple folders you may need to 'help' omnisharp a bit. I initially had a big project and added a solution for it further on - ending up with TWO workspace folders (one to a startup project and one to the solution). After composing that setup I experienced only the first project to have intellisense working.
Solution to get intellisense working was to make sure omnisharp worked its way from the solution instead of the project:
Ctrl + Shift + p
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Inspiration gotten from 'swaner':
https://github.com/OmniSharp/omnisharp-vscode/issues/1889
Visual Studio Code's more advanced editing features (IntelliSense, refactoring tools, etc.) only work in C# files if you have a project.json file or *.sln file that VSCode is aware of. Open the folder (i.e. open the File menu and click Open Folder...) with the *.sln file or project.json and VSCode will attempt to find all project/solution files in the folder. If there are multiple projects, you may need to select one from the projects button on the right side of the status bar (bottom of the window).
From the VSCode website:
Selecting a project.json-file is opening a DNX-project and VSCode will load that project plus the referenced projects
Selecting a *.sln-file is opening a MSBuild-project. It will load the referenced *.csproj-projects and sibling or descendant project.json-files but no other project files that are referenced from the solution file.
Selecting a folder will make VSCode scan for *.sln and project.json files and VSCode will attempt to load them all.
If you are start your project with c#, then some time you haven't download extension.
Process by written
Ctrl + Shift + p.
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Then enable the c# extension for "OmniSharp : Project".
Process by image
Downgrading to 1.23.9 of the C# VS Code extension fixed the intellisense for me. So if nothing else is working for you, perhaps try installing an older version of the extension (doesn't necessarily have to be that exact one I mentioned). You can do this by selecting this option in VS Code:
As of the 0.5 version I have found that I need to close and re-open my working files to get some new intellisense information to start working for my own files. This usually happens after I have a file open that needs to use type information from another file I just created. Until I close and re-open them (within the editor) the intellisense doesn't always work.
Hopefully this is something that'll get fixed as the app matures.
Inorder to make the intelligence working, the Visual Studio Code extension OmniSharp should be there along with Mono. When you open a project/solution folder, the OmniSharp gets the project dependencies from either project.json or from the dotnet solution file (if the project/solution created with other versions of visual studio).
So, when you look at the omnisharp's output window after immediately opening the project/ solution folder, you may see the following lines
Starting OmniSharp server at 2017-9-18 09:26:44
Target: /Users/{username}/Source/{Your Solution Folder}/{Your Solution
file}.sln
OmniSharp server started wth Mono
Path: /Users/{username}/.vscode/extensions/ms-vscode.csharp-1.12.1/.omnisharp/run
PID: 5808
post that, you may see couple of lines coming up like below,
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project1 Name}
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project2 Name}
....
they mean that your projects are getting recognised by OmniSharp Extension.
If you get any error message informing you about timeout, please get into the settings of the Visual Studio Code, and add a configuration override like the one below:
"omnisharp.projectLoadTimeout": 200
I know it is too long to wait for 200 seconds. But don't worry, this won't stop you anymore working with project files. But, remember that the IntelliSense will be automatically available once all the projects in the folder are successfully loaded.
Feel free to extend the Timeout setting since it will help you getting intellisense even-though you are not getting it immediately.
Here is another link with the same solution: https://github.com/OmniSharp/omnisharp-vscode/issues/1585
Hope my information helps you! Enjoy your VSCode!
This case was for an existing project that was working fine before. Opened via the vs code "recent" history.
For dotnet core. I opened my project's *.csprog file, made no changes, and saved it via the vs code editor.
As soon as I saved, all of the intellisense stuff starting working again in my other files within that project.
Another troubleshooting strategy to try if none of the above works out is uninstalling Mono, which is unnecessary anyways if you're using .NET Core. I also experienced a sudden disappearance of Intellisense after pulling changes to one of our enterprise repos that included an upgrade from ASP.NET Core 2.0 to 2.1. Strangely, at the same time, Intellisense was working fine in another C# project repo running ASP.NET Core 2.2.
For the project in question, I was puzzled to see successful logs for each reboot of the Omnisharp server as well as perfectly clean builds and runs. The puzzlement increased as I compared these Omnisharp logs to those from the 2.2 project and found them effectively identical.
Upon uninstalling Mono, the one detail that changed is how Omnisharp started. Now it boots up from a shell script located at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/run. Previously, Mono itself was booting the server from the executable at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/omnisharp/Omnisharp.exe.
Other troubleshooting I attempted in this instance though to no avail:
dotnet clean / Deleting bin and obj directories
Updating launch.json to point at the proper /bin/Debug/netcoreapp2.1 build
directory
Wiping my local nuget cache
Restarting Omnisharp
Uninstalling and reinstalling VS Code, as well as bumping back a version from 1.33.1 as the breakage coincided oddly with the March 2019 update
Uninstalling and reinstalling the C# VS Code extension, as well as bumping back a version from 1.19.0 given other users' reports of said version interfering with Intellisense for certain projects*
Adding a global.json file at project root to override default utilization of latest .NET Core SDK (mine was 2.2.105) and run instead using 2.1.302 in concert with the project's version
Wiping/rebuilding the project .sln file
Specs: VS Code 1.33.1, C# Extension 1.19.0, MacOS High Sierra 10.13.6.
*NB: As it turns out, in another .NET Core 2.1 project with the same issues in VS Code as described above, uninstalling Mono alone did not fix things. I also did wind up needing to bump back the C# extension to v. 1.18.0 to recover Intellisense. Weird.
The issue I had was OmniSharp was an older version. I set the flag to update to latest version in Settings.json file. This ensures the extension is always the latest version.
"omnisharp.path": "latest"
And restarted VS code. That fixed it for me.
Simply reinstall the extension and restart the VSCode/PC.
I use Task Manager and kill the Visual Studio Code process, then restart Visual Studio Code, the intellisense shows and fixed.
I've had some good experiences in C# with this extension so far:
https://marketplace.visualstudio.com/items?itemName=jchannon.csharpextensions
This extension traverses up the folder tree to find the project.json or *.csproj and uses that as the parent folder to determine namespaces.
Try "Install Extension" from command Pallete - probably if C# intellisense is not there:
https://code.visualstudio.com/docs/customization/colorizer
if intellisense in not working for react js or javascript or node js this solution will help for windows
uninistall type script by typing npm uninstall -g typescript
install specific version of type script that is 3.3 by typing npm install -g typescript#3.3
add the typescript location in vscode by navigating to file > Preferences > settings > here search for edit in setting.json then add this path "typescript.tsdk": "/Users/yourusename/AppData/Roaming/npm/node_modules/typescript/lib"
settings.json should look someting like this
{
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection":"automaticallyOverrodeDefaultValue",
"typescript.tsdk": "/Users/yourusername/AppData/Roaming/npm/node_modules/typescript/lib"
}
I was able to fix this by changing the Api Compatibility Level from .Net Standard 2.0 to .NT 4.x. You can find this setting on Project Settings / Player.
After that, intellisense started working again.
This is because of C# extension issue.
Reinstall the extension will work.
https://code.visualstudio.com/docs/editor/intellisense
https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp
I fixed this with a multiple project solution in .net5 / .net core 3.1 by
opening each project (not the sln folder) in VSCODE. This then prompts to add the resources/ .CSX? files to the project; enabling intellisense, per project. Finally close that window and reopen the solution folder and all works as expected.
See image
Add VSCode assets
Downgrading to 1.23.9 of C# for Visual Studio Code (powered by OmniSharp).
https://i.stack.imgur.com/VrdJl.png
After trying several things I looked at the OmniSharp logs only to realize that because I had two different sln files in my workspace. It had picked up the “other” one and thus wasn’t working. I deleted it, reopened vs code, and all is well again.
For me I had been working without internet for a long time. It had previously been working but then stopped. I closed+reopened VSCode with a stable wifi connection and the Output tab in VSCode popped up, displaying the the extensions were re-installing. After that it worked!
in my case , the extension wasn't enabled
I just had this happen (this being no code completion suggestions appearing). What resolved it for me was changing the VSCode Editor package in Unity to a previous version and then back to the current version.
For me, this was going from 1.2.0 to 1.1.3 and then back to 1.2.0. I believe removing and reinstalling 1.2.0 would have accomplished the same.
Window > Package Manager > Visual Studio Code Editor
I know this is probably the most obvious answer. But I had enough dealing with VS Code ridiculous bugs. You should be focusing on code, not the buggy IDE. Their documentation doesn't make it easy either to debug.
Steps for complete uninstallation:
Save your personalization files such as keybindings.json,
Just put it on GitHub or something so whenever you need have trouble with VS Code you simply just need to go to GitHub and copy-paste it.
Uninstall VS Code completely
When you uninstalled VS Code, it doesn't erase your extension files and some old settings. This is the cause of the re-installation ended up the same. Horrible move VS Code. For the list of the files that you must delete, you can check out this answer.
Go to their website and install the new one.
I hope this helps some people who are already had enough with the VS Code ridiculous bug.
In my case, the issue was not with VS Code settings. The error was due to a corrupted TEMP path configured in my PC's registry user profile environment settings.
I got this error from Help --> Toggle Developer Tools --> Console
The error was flagged in the console when I opened a new typescript file.
Unable to write file c:\Users\XXX\AppData\Local\Temp;C:\wamp64\bin\php\php5.6.25;C:\vufind-3.1.2\install.php\09cf49d8-af5b-42e9-8194-43f5b566be0f'
Obviously this path was corrupted. After updating the environment variables in registry settings, the VS code IntelliSense started working. Checking the console is a good start to find the root cause of this issue.
Earlier intellisense was working for Angular in VS-Code but for some reason (which I don't know) intellisense stopped working. I had extensions installed i.e. Angular Essentials and Angular Language Service etc. that were responsible for this intellisense and all that.
What I did?
I disabled the extensions, restarted VS Code and enabled them. It was all working fine as before.
If everything in VSCode is working ( No errors in output console, language server is working etc.) and built-in extensions are enabled. Still, if your IntelliSense is not working for normal .js files make sure variables are defined with a type identifier such as var d = new Date() or let d = new Date(). In my case, IntelliSense was not working for d = new Date() (No autocomplete for Date object 'd' APIs in this way) but started working fine when I specified a type before my variable names.
Download and install "Tool for Visual Studio 2019" as the C# extension under hood use the build tools: https://visualstudio.microsoft.com/downloads/
In my case, I had an extension installed (Explorer Exclude) to help me focus and hide certain files that I don't regularly work with within the Explorer.
I so happened to have disabled viewing *.sln, *.csproj and *.vsconfig files and folders, which apparently prevents VSCode from even knowing the file is there in the first place. Disabling these specific rules solved the problem instantly.
Took me ages to figure out... The more you know.
I solved it by uninstalling all SDK's (not sure if this is needed)
and installed 4.7.1 developer pack
win 10, vscode 1.63.2, unity 2020.3.25f1
I fixed this by installing .NET Framework 4.7.1 Developer Pack:
https://dotnet.microsoft.com/en-us/download/dotnet-framework/net471
How can one debug the .NET framework source code using Visual Studio 2017?
There are some questions here on stackoverflow about this topic, but even after reading all of them, I still wasn't able to make it work.
I thought it would be useful to present an up-to-date, working solution about how to debug .NET framework source code.
I would like to solve it without using any external tools (e.g. dotPeek as source server).
First of all, I tested it using Microsoft Visual Studio Enterprise 2017, Version 15.9.7 and via .NET Framework 4.7.2. Though, I think it should work on Community edition the same way.
Steps to take:
Go to Tools / Options / Debugging / General, and perform these settings:
check Enable .NET Framework source stepping (this will automatically disable "Enable Just My Code"; if not, do it manually)
uncheck Require source files to exactly match the original version
check Enable source server support
Go to Tools / Options / Debugging / Symbols, and:
in the upper listbox check Microsoft Symbol Servers
click Empty Symbol Cache button (to make sure you will get the correct symbols)
select Load all modules, unless excluded radio button at the bottom
Download the source of the .NET framework version your project is targeting, from the https://referencesource.microsoft.com/download.html site.
Unpack the downloaded archive (zip) file to a convenient path on your PC.
Debug your application; set a breakpoint to the line of .NET code you wish to debug, and step to the desired code line with the debugger.
Note: your application may start slower since it will download PDBs from the internet.
Press Step Into (F11 by default). If your settings are correct, this will cause some delay (if your VS crashes (like mine did), Empty Symbol Cache again). Eventually it will ask for the sources of the given file, e.g. dictionary.cs.
Two things can happen here:
A) It asks for the source file (.cs) in a file dialog. Go to step 7.
B) It says whatever.cs not found, and there is a link that says "Browse and find whatever.cs...". Click that link.
Select the corresponding .cs file on your disk (you can search for the file on the OS).
Note: I had to restart VS several times until it "did not crash" while looking for sources, this is most likely a bug in VS.
If you did everything correctly, you will find yourself debugging the .NET source code.
Note: Since VS saves the path you entered for the source files, you can stop debugging or restart VS; it will work next time, too.
Besides, you do not have to manually select any more source files within the framework, because the VS will use the source folder you entered and will search in source files there.
Many people wondering why they can't step into source although they does set the checkboxes as described above. I'm, too.
Because you can extract dotnet sources to any location, Visual Studio isn't able to know about them and the reason can't be the source files itself (why Visual Studio doesn't find the files).
But some dll's are browseable, some not (through double clicking in Visual Studios stack view or context menu > goto source). This brought me to the assumption, that the .pdb itself must be the reason. If you look into a file which works (e.g. notepad), you see at beginning a list of strings with file pathes (source files). In files, which doesn't work, the files starting immediatelly with binary data.
For some reason microsoft doesn't create her .pdb's with full debug information in every build process. But why not - good question! g
In short: you have to search a dll version of your file (which you like to debug) which contains FULL DEBUG INFORMATION. This is also the reason why context menu disables "goto source".
I'm replacing this file temporary in global assembly cache for time of debug. This works for me.
Here an example of PresentationFramework.dll
- 4.0.30319.298 => pdb size: 1219 KB
- 4.0.30319.18408 => pdb size: 15.562 KB
Perhabs somebody can create a public database (wiki), which everyone can add files and versions for which full debug information are available?
(If you are like me and after following all steps you still can't step into code...your PDBs downloaded from Microsoft are wrong, try this)
Using JetBrains dotPeek as the symbol server worked for me. (4.6.2 framework) (I did everything mentioned in this thread and many more threads, and nothing worked)
https://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/
JetBrains dotPeek decompiles your actual .NET DLLs, then hosts a symbol server that you download symbols from in Visual Studio. After a pretty slow download, then a restart of VS, I was able to breakpoint and step into the code.
You can find the path to your .NET DLLs in the "Modules" window when debugging in VS. Enter this into dotPeek. Then Host Symbol server in dotPeek. Then add http://localhost:33417 as your symbol server in VS symbol settings. then load those symbols. it takes a minute and a VS restart, but works.
I have a weird problem with PDB files in a VS 2013 C# project. Basically what is happening is that the PDB files are not getting rebuilt when the project is getting rebuilt. This is causing the project to always think it needs to get rebuilt. I've tried cleaning the solution, but if anything changes in the project it gets put back into the same state again.
I created a simple class library project and the behavior was the same. As a sanity check, I created the same class library on another PC and it worked as I would have expected.
Does anybody have any ideas as to what might be causing this strange behavior?
Please check “Advanced Build Settings Dialog Box”
Is “Debug Info” set none?
see MSDN
I had this problem. I went into Build > Configuration Manager. Make sure that the active solution configuration is Debug. Next change the platform to be Any CPU. Somehow many projects were getting built on a mixed platform which was only allowing a couple project's pdb files to get built.
I have exactly the same problem. The only solution I've managed to come up with is to add a pre-build step to each project to delete the .pdb:
del "$(ProjectDir)obj\$(Configuration)\$(TargetName).pdb"
Which then seems to force it to create a new file when it's built.
For some reason, visual studio (2012) is not reading any changes in my code. It will recognize an error but, for example, if I get rid of something that makes a window appear, a window will still appear. I am also unable to debug my code (I get the 'symbols not loaded for this document' error). This has been going on for a few days.
I'm not quite sure what to do. I've cleared the visual studio cache but that didn't help. I've changed the startup project settings around but that doesn't change anything either. This is all from my local machine (no source/version control). Does anyone know why this is?
I fixed this by deleting the .suo (silverlight user options) file, as was suggested in the link below, thanks #amalgamate
http://www.kunal-chowdhury.com/2011/08/why-visual-studio-debugger-is-not.html
Try Build > Clean Solution then Build
This may not be your answer and I do not know silver light, but I have found the symbols not loaded error often when the solution file lost track of where a project file was, or when a project file lost track of a library. Maybe the file is missing, or maybe someone else on your team directed it else where etc.. To fix this in project explorer, right click on the solution or project and re-add the particular reference or project (using the add menu item). You may then have to remove the old project/ or reference. You will know the references and projects are bad because of the icon next to them in the project explorer. The bad links will also be listed in the output of your build with the bad links named.
Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.
Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.
http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.
Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?
Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.
I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.
AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.
Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).
Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.
In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]
Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?
Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?