I recently upgraded my version of VisualStudio Code to the latest release and am I getting an error when trying to debug csharp applications. I am running in windows 10 (14393) and am using vs code 1.23.1. I have an application that I created a few months ago using visual studio code and at the time it was working fine. it is a MVC application that uses dotnetcore2.0. When I try to run debugging I get a message "command 'csharp.coreclrAdapterExecutableCommand' not found. I can execute the application by running "dotnet run" from the project folder.
I tried creating a new blank console application that just says "hello world" and again am able to run from "dotnet run" but when I try to debug I get the same message. I am able to run the build task successfully.
I tried to reseaerch the method mentioned in the error but can find little to nothing about it. I believe that omnisharp is the solution that the csharp debug runs in and I looked it up. From their documentation it says that it needs .net framework 4.6 to work. I verified that I have the sdk and runtime for each .net framework installed.
I am usually pretty good at figuring things like this out and this is my very first post on stack. I am hoping that someone might know what the heck this is so that I can move forward.
It would be good to note that I have tried to reboot my machine several times and even uninstalled/reinstalled vs code. An example of the launch.json file is below.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceRoot}/helloworld/bin/Debug/netcoreapp2.0/helloworld.dll",
"args": [],
"cwd": "${workspaceRoot}",
"stopAtEntry": false,
"console": "internalConsole"
}
]
}
Thanks to #bman7716 I was able to figure out what was going on. The issue was the omnisharp extension was corrupted (or a related dependency). I was able to resolve the issue by:
Uninstalling the c# extension from VS Code
Close VS Code
remove all C:\Users{username}.vscode\extensions\ms-vscode.csharp-{version}
Open VS Code
Install C# extension
Open Project
Go to Debug mode and start debug
This forced VS Code to re-install omnisharp and its dependencies and things worked just fine afterwards.
Related
I'm running vscode version 1.73.1
I have the following extensions installed on a new VM that sits behind a corporate proxy:
Microsoft C# v1.25.2
Azurite v3.20.1
Azure Functions v1.9.0
I have a C# Azure Functions project that I'd like to debug.
My tasks.json file contains the following:
{
"type": "func",
"dependsOn": "build (functions)",
"options": {
"cwd": "${workspaceFolder}/bin/Debug/net6.0"
},
"command": "host start --dotnet-isolated-debug",
"isBackground": true,
"problemMatcher": "$func-dotnet-watch"
}
The launch.json is as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to .NET Functions",
"type": "coreclr",
"request": "attach",
"processId": "${command:azureFunctions.pickProcess}"
}
]
}
I click the debug icon from the sidebar menu and choose "Run and Debug - Attach to .Net Functions"
The function app is then build and starts. The VM is slow so it takes more than 60 seconds for the function app to start. During that time VS code pops up a message to say is it slow. However, the function app does start and the http endpoints are presented in green text.
I then see the following presented in the terminal window:
Azure Functions .NET Worker (PID: 12116) initialized in debug mode.
Waiting for debugger to attach... Host lock lease acquired by instance
ID '00000000000000000000000083B41702'. A debugger was not attached
within the expected time limit. The process will continue without a
debugger. Worker process started and initialized.
I don't see any text in the "Debug Console"
I am able to call the http endpoint and a successful response is returned, but the breakpoint does not break!
If I run the same solution in vs code directly on my laptop, then the debugger is attached. Problem is, I need to debug on the corporate VM because the code selects from an on-prem sql db.
So, I guess there must be some difference between the two configurations of vs code / extensions or perhaps the corporate proxy is causing a problem?
Not sure which text file this gets saved to but was able to resolve by extending the timeout in the workspace preferences section:
I increased from the default of 60 (seconds) to 180
I am trying to debug a simple "Hello world" application in VS Code, however, when I press Ctrl + F5, it gives me the following error:
If I manually change the path in launch.json from:
${workspaceFolder}/bin/Debug/insert-target-framework-here/insert-project-name-here.dll
To:
"${workspaceFolder}/bin/Debug/netcoreapp2.1/test.dll"
It does work, however before it was working fine without me manually typing the path. Also, I have noticed that VS Code no longer asks to rebuild assets like it did before:
So far I have tried the following:
Uninstalled VS Code, then .NET Core 2.1, deleted the VS Code extension folder from %USER%\.vscode\ , re-installed VS Code, then .NET Core 2.1, and then the C# extension (C# for Visual Studio Code (powered by OmniSharp)).
When the VS Code starts, it does download the "OmniSharp" package successfully, but still, no prompt to rebuild assets when I open a C# file. Debugging gives the same issue as before.
Here is the launch.json:
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceFolder}/bin/Debug/<insert-target-framework-here>/<insert-project-name-here>.dll",
"args": [],
"cwd": "${workspaceFolder}",
"console": "internalConsole",
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart"
}
And the tasks.json:
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "dotnet build",
"type": "shell",
"group": "build",
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$msCompile"
}
]
}
I found a solution that worked for me.
My VS Code was giving me the same error message, and what I did to fix it was:
- Press the combination Ctrl + Shift + P
- Restart Omnisharp
- Then it asks if you want to add missing files for build.
- Click Yes.
After this I was able to debug my app.
Hope it works for you!
Visit your \bin\Debug\netcoreapp3.1 in your project folder (That you open in VS)
Go to launch.json file in VS:
Replace:
"program": "${workspaceFolder}/bin/Debug//.dll",
With:
"program": "${workspaceFolder}/bin/Debug/netcoreapp3.1/CSharp.dll",
In may case, the project is called CSharp. Watch out.
I had a the same error. The debugger was looking for the .dll file in ${workspaceFolder}/bin/Debug/netcoreapp3.1/myApp.dll but the file was located in ${workspaceFolder}/bin/MCD/Debug/netcoreapp3.1/tradeAppl.dll
After changing the launch.json file to read
...
"program": "${workspaceFolder}/bin/MCD/Debug/netcoreapp3.1/tradeAppl.dll",
...
I was able to debug the application without any problems.
Since you have :".dll" taged with "<" and ">", it means that you have give it a value.
The easiest way to do it is to open the project in VSCode and use find&replace to replace the:
with your project name which I do believe its: "test" as per the .dll name
Configure your Launch.json like this Gist
And there is no need to Tasks.json , you can Press F5 to build or configure it your self to which command should be run in default shell when you press F5
// "program": "${workspaceFolder}/bin/Debug/<insert-target-framework-here>/<insert-project-name-here>.dll",
"program": "${workspaceFolder}/bin/Debug/netcoreapp3.1/csharp_multi_threads.dll",
You need to change the program value as it reminded
I switched to MS Visual Studio, since I did not find any other solutions.
-Right Click on Project Name And Click on Reveal in Explorer
-Copy Url In Explorer After Folder Name
For Example My Folder Address is
D:\IOT\Projects\LWSIOT_WebApiWM2\LWSIOT_WebApiWM2\LWSIOT_WebApiWM2\bin\Debug\netcoreapp3.1\LWSIOT_WebApiWM2.dll
And In Launch.json :
${workspaceFolder}/LWSIOT_WebApiWM2/LWSIOT_WebApiWM2/bin/Debug/netcoreapp3.1/LWSIOT_WebApiWM2.dll
-Paste in Launch.json on "Program":"<Your_Address>"
-Click On Debug And Its OK
In launch.json , replace :
"program": "${workspaceFolder}/Api/bin/Debug/netcoreapp3.1/Api.dll",
with:
"program": "${workspaceFolder}/Api/bin/linux/Debug/netcoreapp3.1/Api.dll"
Since I was running code in Linux machine so I should have provided Linux Folder' path
Must be an issue with the path to the dll in the program property of the launch.json file.
In my case, it still contained the old .net core framework version after the version upgrade.
I have a 'Hello World' Kestrel server generated by Yeoman (as described here).
yo aspnet
When I run the site via the command line everything work well:
dotnet run
If it's run through Visual Studio Code though bootstrap.css, jquery.js and bootstrap.js don't load (404).
Looking at the F12 tools, they are actually coming from different locations. When run via dotnet run they come from https://ajax.aspnetcdn.com/..., but when run through Visual Studio Code the browser is looking for them in a local folder ~/lib/....
a. Why are the files being sourced differently depending on how I run the site?
b. How do I fix this?
Thanks
When you run it from command line, it runs in production mode (no ASPNETCORE_ENVIRONMENT variable set. When you run it from Visual Studio it sets the ASPNETCORE_ENVIRONMENT to Development.
Inside your Razor files, you have a <environments> section which controls which files are served in which production mode. Depending on your environment/OS, you need to set the variable differently. i.e. in Linux you'd need to run ASPNETCORE_ENVIRONMENT=Development dotnet run.
As for the reason why you get 404 when running in development mode, you probably need to copy over the wwwroot folder to your output directory, with this entry in your project.json.
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true,
"copyToOutput":
[
"wwwroot",
"Views",
"appsettings.json",
"web.config"
]
},
"publishOptions": {
"include": [
"wwwroot",
"Views",
"appsettings.json",
"web.config"
]
},
Though usually it should be necessary to add wwwroot to copyToOutput
I inherited a project and the tests ran fine. Today, I created a new class, and xunit errors out when I try to use this class in a test.
Both the test project and the app are targeting .NET Framework 4.6.1.
I do clean and rebuild on the both the solution and the test project, but I still get the error.
error:
Could not load type 'MyNewClass' from assembly 'MyApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
project.json:
"buildOptions": {
"warningsAsErrors": true
},
"testRunner": "xunit",
"dependencies": {
"xunit": "2.2.0-beta4-build3404",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"MyApp": "1.0.0-*",
"Microsoft.EntityFrameworkCore.InMemory": "1.0.0",
"NSubstitute": "1.9.2"
},
"frameworks": {
"net461": {
}
}
Anyone have any ideas how to fix this?
Sometimes for whatever reason .NET Core dependencies restore won't work as expected. I've just tried your project.json on my machine and it was complaining about xunit version, however after several project.json edits it was able to restore all the dependencies, and run tests successfully.
In such situations following might help:
Try dotnet restore and/or dotnet build commands in the folder where your project.json file is.
Delete project.json.lock file and try step #1.
Use dotnet test to run unit tests.
I find these commands to run .NET Core projects more stable and provide better error output for troubleshooting than Visual Studio.
So, my problem was that MyApp.dll was not getting updated/re-created, even after I did a clean and rebuild. I had to physically delete the files (including MyApp.dll) in MyApp\test\MyApp.Tests\bin\Debug\net461\win7-x86
I had this problem too and could solve it recreating the project.
Sometimes, things simply stops working correctly, as pointed in the others answers, and the best is just start over, restart the program, recreate the project, reboot the machine...
This is Visual Studio, sigh... :)
I'm working on a ASP.NET 5 MVC 6 web application with React and TypeScript in Visual Studio 2015 with ReSharper 2016.2. I'm using a tsconfig.json that looks like this:
{
"compilerOptions": {
"noImplicitAny": false,
"noEmitOnError": false,
"removeComments": false,
"experimentalDecorators": true,
"module": "commonjs",
"moduleResolution": "node",
"sourceMap": true,
"target": "es5",
"jsx": "react"
},
"exclude": [
"node_modules",
"wwwroot",
"typings/index.d.ts",
"typings/index",
"jspm_packages"
],
"compileOnSave": true
}
As you can see, noEmitOnError is false. However, after installing Update 3, Visual Studio no longer lets me build the solution if there are any typing errors. Every TS error is reported twice in the error list:
And the first error, without the error code, stops the solution from building.
I've tried:
Reinstalling/Uninstalling TypeScript tools for VS (doesn't change anything)
Recreating the tsconfig.json file.
Switching to the mode without tsconfig.json and making sure emit on error is enabled.
Disabling/enabling ReSharper
Uninstalling various other extensions
Creating a new project and solution. The error occurs in all projects.
The only solution I've found to the issue is removing the following line from the .csproj file:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
After I do this, the TypeScript tooling still works fine (there are a few minor issues) and the error that begins with Build: disappears.
The problem is that after some operations on .ts files Visual Studio raises the following helpful message:
And helpfully adds that line to the .csproj file again. At first everything is okay, but the Build: error comes back after I restart Visual Studio.
Edit: Better Workaround
Okay, a better workaround is to replace the bad line with the following:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="False And Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
This 'tricks' VS into believing that the line already exists so it won't add it again. However, there are still issues, such as errors only appearing if you open the file containing the error, rather than on build.