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
Related
As per MS documentation, the testEnvironments.json can be used for running unit tests in a docker container.
My testsEnvironments.json looks as follows:
{
"version": "1",
"environments": [
{
"name": "debian-net6",
"type": "docker",
"dockerFile": "./testsDockerfile"
}
]
}
Everything works as expected - my unit tests can be executed in a docker container. Now I would like to configure how the actual container is created. For instance, I would like to mount a docker socket, using docker run -v //var/run/docker.sock:/var/run/docker.sock .... or mount other volumes explicitly.
The Visual Studio creates the container (if not running) behind-the-scenes and mounts the solution directory whenever the unit tests are executed. Unfortunately, I haven't been able to find a way how to customize how the container is created.
I am aware of other options, such as running a remote machine or a local WSL distribution, but I am interested mostly in this dockerFile/dockerImage approach.
From what I was able to gather, it seems to me that this sort of configuration is not supported right now (this testsEnvironment.json feature is still in experimental preview). I have also looked into .runsettings file, but it does not seem to offer anything of interest.
When i build and run the project everything works fine.
When i publish the project and run it from within publish directory, it doesn't respond to any message.
In the emulator i get the message:
Cannot post activity. Unauthorized.
POST403 directline.postActivity
dotnet myBot.dll //from within publish directory, bot runs, doesnt repond to any message
dotnet run //from project directory, everything works fine
So, the problem was that i was tying to test production configuration trough localhost endpoint and in my .bot file i had this:
{
"type": "endpoint",
"appId": "myId",
"appPassword": "myPass",
"endpoint": "https://my.azurewebsites.net/api/messages",
"name": "production",
"id": "4"
},
The production endpoint is the azure service. So, you either test locally on localhost or set your service on Azure to point to your localhost(ngrok provided link - In that case you need to configure ngrok to expose your localhost to the outside).
https://blog.botframework.com/2017/10/19/debug-channel-locally-using-ngrok/
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.
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 would like to connect to my Kestrel server with ASP.NET 5 application hosted on it from another PC in the same network. Is it possible? I can ping my computer from cmd, but I get 'Connection timed out' when I try to connect from a web browser (I type this: "http://{my_kestrel_ip}:5000/").
The hosting.ini was not working for us. I have to add this to the project.json file. I believe that the hosting.ini file is being deprecated after Beta8.
--server.urls http://0.0.0.0:5000
or I prefer the following which I believe is less confusing.
--server.urls http://*:5000
So you would end up with something like this in your project.json.
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://0.0.0.0:5000",
"ef": "EntityFramework.Commands"
},
In your project folder you should have a file called hosting.ini. In that file by default you should have something like this:
server=Kestrel
server.urls=http://localhost:5000
You need to make the HTTP server listen on your public IP address as well as localhost. To do that, you can add an additional address by separating them with a semi colon:
server.urls=http://localhost:5000;http://{my_kestrel_ip}:5000
Just did a quick test that seems to work.
Create a hosting.json file beside your project.json file.
hosting.json:
{
"server.urls": "http://localhost:5000;http://192.168.1.4:5000"
}
project.json:
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel --config hosting.json"
},
In a command prompt simply run dnx web, output:
Hosting environment: Production
Now listening on: http://localhost:5000
Now listening on: http://192.168.1.4:5000
Application started. Press Ctrl+C to shut down.
You'll get a firwall prompt, accept it, and tadaaa!! You can access the site from the LAN and localhost.