VSCode Azure Functions - Error: Cannot read properties of undefined (reading 'createClient') - azure

I'm unable to upload the code to azure functions for some reason. It was working few days ago when I tried.
Now I get the below error. Here is a screenshot of the error.
4:27:59 PM: Error: Cannot read properties of undefined (reading 'createClient')
4:28:03 PM: Error: Cannot read properties of undefined (reading 'createClient')
4:31:28 PM: Error: Cannot read properties of undefined (reading 'createClient')
Only thing I modified this time is the local.settings.json as below.
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "dotnet",
"AzureWebJobsStorage": "##########",
"CosmosDBConnection": "##########",
"StorageConnectionString": "#########"
}
}
tried the old version of the code which used to work and there were no modification but now that also reports the same error.
Any idea what the issue is? I'm guessing something wrong with vscode.
Here is my local.settings.json:
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "dotnet",
"AzureWebJobsStorage": "#############",
"CosmosDBConnection": "#############",
"StorageConnectionString": "#############"
}
}
Here is the .vscode\settings.json
{
"azureFunctions.deploySubpath": "bin/Release/netcoreapp3.1/publish",
"azureFunctions.projectLanguage": "C#",
"azureFunctions.projectRuntime": "~3",
"debug.internalConsoleOptions": "neverOpen",
"azureFunctions.preDeployTask": "publish (functions)"
}
Update: Uploading from resource view works but uploading from workspace doesn't work. Here is a reference to the bug reported and the work around.

Figured it out.
Deleted the .vscode folder from within the project folder and restarted the Visual studio code and it initialized the function app again. Now I can upload the function without any issues.

Related

Unbound breakpoints in Docker node.js TypeScript application

There are a lot of questions on this topic, and I have tried many of the solutions that worked for others, but the solution seems to depend on several things such as the version of VS Code and the recipe used.
This is my VS Code Help>About info:
Version: 1.60.2 (user setup)
Commit: 7f6ab5485bbc008386c4386d08766667e155244e
Date: 2021-09-22T12:00:31.514Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.17763
The OS is Windows 10.
The Docker plugin is installed.
I have Docker Desktop 2.3.0.3 installed.
The application is written in TypeScript with inversify IOC.
I am using the launch.json and tasks.json files in src/.vscode.
The Docker container is built with the contents of the workspacefolder in /app. It is running locally, using the VS Code Docker plugin.
launch.json:
{
"configurations": [
{
"name": "Docker Node.js Launch",
"type": "docker",
"request": "launch",
"port": 9229,
"protocol": "inspector",
"preLaunchTask": "docker-run: debug",
"localRoot": "${workspaceFolder}/",
"platform": "node",
"remoteRoot": "/app/",
"sourceMaps": true,
}
]
}
tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"type": "docker-build",
"label": "docker-build",
"platform": "node",
"dockerBuild": {
"dockerfile": "${workspaceFolder}/Dockerfile",
"context": "${workspaceFolder}",
"pull": true
}
},
{
"type": "docker-run",
"label": "docker-run: release",
"dependsOn": [
"docker-build"
],
"platform": "node"
},
{
"type": "docker-run",
"label": "docker-run: debug",
"dependsOn": [
"docker-build"
],
"dockerRun": {
"env": {
"DEBUG": "*",
"NODE_ENV": "development",
},
"command": "node --inspect-brk=0.0.0.0 dist/index.js",
"envFiles": [".env"],
},
"node": {
"enableDebugging": true,
"inspectPort": 9229
}
}
]
}
tsconfig.json:
{
"compilerOptions": {
"target": "es2018",
"module": "commonjs",
"noImplicitAny": true,
"strictNullChecks": true,
"removeComments": true,
"preserveConstEnums": true,
"sourceMap": true,
"outDir": "./dist/",
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"typeRoots": [ "./types", "./node_modules/#types"],
"resolveJsonModule": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "src/**/*.test.ts", "types", "**/tests/*.ts"]
}
When I initiate debug (select the Docker Node.js Launch option and hit F5), the docker builds and starts. The application stops on the first line of dist/index.js, but all my breakpoints (which are all in classes) show as unbound and the debugger does not stop on any of them. The application runs normally otherwise.
I assume that the breakpoints are unbound because VS Code can not map the running code back to the breakpoints in the source. But I have tried opening the files inside the container and setting breakpoints there, and that doesn't work either.
What do I have to do to make breakpoints work?
I had a similar issue today and was finally able to solve it. I will provide my findings here in the hope it might be helpful to you too.
1. Use trace
By setting trace: true in the launch.json configuration, you will get a lot of more details in your logs.
You can read how to make use of that here: NodeJs Debugging in Visual Studio Code
When starting the debugger config with trace: true, you will get a log entry in your debug console in the likes of
Verbose logs are written to:
/somepath/vscode-debugadapter-xxxxxx.json.gz
You can take this logfile and analyze it here in this interesting online tool by Microsoft: vscode-pwa-analyzer (Whole Project on Github)
There's a whole lot of logs in there. Probably best if you just try it out and see if you see anything helpful in there.
2. check your sourcemaps
For me it really helped to look at one of my sourcemap files. Go to your build / dist or whatever name you use for your build directory and look for a .map File.
If you open it, you should see something along the lines of
{"version":3,"file":"somefile.js","sourceRoot":"","sources":["../../../src/somedir/somefile.ts"] ... }
Make sure that the sources path is correct. Otherwise there might be something off with your tsconfig File.
3. check the outFiles config
This seemed to be necessary for me to configure to make it work. Add all the paths as glob patterns that contain compiled Javascript Files.
"outFiles": ["${workspaceFolder}/dist/**.js"],
4. sourceMapPathOverrides
There might also be an issue with the Source Map Paths. You can see if adding this snippet here helps:
"sourceMapPathOverrides": {
"webpack:///./*": "${workspaceRoot}/*",
},
5. check the program config
For me, adding the program config property finally did the trick.
If you don't know which one that might be, in my case it helped looking at what my Chrome used as the entry File.
Go to chrome://inspect in your Chrome Browser while your application is started and check what you see there.
In this example the entry File would be the server.js, which led me to configure the source of that file as the program, (with the local path) like so:
"program": "${workspaceFolder}/src/server.ts"
Conclusion
Your setup is probably different from mine and I still don't understand all the settings 100% to be honest. But maybe one of these things helps you get closer to find a solution. Let me know if it helped, and good luck.

AWS Toolkit + VSCode local testing

I'm trying to figure out how to use AWS toolkit for vscode. I go to the AWS extension and click Create New SAM Application, point to project directory and it creates a hello world function. Above it, it says Add Debug Configuration. I click that, choose nodejs 12.x and save the launch.json, but I don't get the run option. It still says Add Debug Configuration for some reason. How can I run my lambda functions locally in the console?
The launch.json file generates, but I can never run the code.
launch.json
{
"configurations": [
{
"type": "aws-sam",
"request": "direct-invoke",
"name": "new test:app.lambdaHandler (nodejs12.x)",
"invokeTarget": {
"target": "code",
"projectRoot": "new test/hello-world",
"lambdaHandler": "app.lambdaHandler"
},
"lambda": {
"runtime": "nodejs12.x",
"payload": {},
"environmentVariables": {}
}
}
]
}
I also tried navigating to the hello-world directory in terminal and executing node app.js, but it doesn't return anything
What am I doing wrong? I appreciate the help!
Make sure you have SAM CLI install in local, here are the instructions for installation https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html
Then run the command sam local start-api.
You should be able to access the api at http://127.0.0.1:3000/hello
You can also do the same via vscode by selecting Run > Run without debugging (shortcut: ctrl + F5)

Getting error when deployed: An attempt was made to access a socket in a way forbidden by its access permissions

I have created an Azure Function in Go. The function is working properly in local machine. But, when I deploy it to Azure, I am getting the below exception:
An attempt was made to access a socket in a way forbidden by its access permissions.
Inner exception method is: System.Net.Http.ConnectHelper+<ConnectAsync>d__1.MoveNext
Error log is here: https://github.com/mpurusottamc/azurefunc-go/blob/master/errorlog.json
local.settings.json file has below code:
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "node",
"AzureWebJobsStorage": "<proper storage link>"
}
}
host.json file has golang executable reference as the worker.
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true
}
}
},
"httpWorker": {
"description": {
"defaultExecutablePath": "hello.exe"
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[1.*, 2.0.0)"
}
}
My code is hosted in github here: https://github.com/mpurusottamc/azurefunc-go
deploy.sh file contains the deployment script.
Followed this reference article: https://itnext.io/write-azure-functions-in-any-language-with-the-http-worker-34d01f522bfd
Am I missing something?
I updated golang version to 1.14 on my machine. And also applied --force in the deployment script and that resolved the issue for me.
go.mod is updated like this:
module hello
go 1.14
deployment script updated to include --force argument
func azure functionapp publish hellogoapp --force

Hosting environment why is it set to Production, Difference between host.json and local.settings.json

I have two questions on .net core applications for functions. I am using blobtrigger.
1) When I run my project locally I get this 'Hosting environment' on the command prompt console, I want to understand where is this variable set and how can I change it to development. Its misleading since I am only developing locally.
[5/23/2019 7:00:20 PM] Host started (773ms)
[5/23/2019 7:00:20 PM] Job host started
Hosting environment: Production
Content root path: C:Myproject\bin\Debug\netcoreapp2.1
Now listening on: http://0.0.0.0:7071
2) What is the difference between host.json and local.settings.json. When can host.json be used? So far I have only used local.settings.json and when I publish to azure I am creating configurations mentioned in local.settings.json but Host.json is not used it looks like. Whats the purpose of host.json file is.
"Hosting environment" on the console comes from the environment variable ASPNETCORE_ENVIRONMENT. When this variable is not set, it defaults to "Production".
It's set here: HostingEnvironment.cs
The reason behind this default is described in this github issue.
This variable is popular in dotnet core web apps, but it is not mentioned in official docs in Azure functions (I am not sure why). If you write a for loop and output all the environment variables to console from within a function, you will find that this variable is not set by default - neither in production, nor when running in Visual Studio.
If you wish to define this variable locally, you have a few different ways.
Setting the environment variable via command line:
setx ASPNETCORE_ENVIRONMENT "Development"
Defining this in Properties\launchSettings.json:
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
Defining this in local.settings.json:
"Values": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
Note that this variable is not automatically defined to production when you publish your app to azure. You will have to define this variable in "Configuration" -> "Application Settings" in Azure portal.
In azure functions there appears to be another similar environment variable called AZURE_FUNCTIONS_ENVIRONMENT. This one is defined by default locally.
AZURE_FUNCTIONS_ENVIRONMENT = Development
This is not defined in production by default, and can be defined in the azure portal.
Difference between host.json and local.settings.json:
host.json is to configure pre-defined settings that function app infrastructure understands. It applies to both local and production environments. It doesn't allow custom settings though. local.settings.json on the other hand is useful for defining custom settings. host.json is committed into source control, but local.settings.json is usually left out of source control, and is considered to be a good location to store secrets and connection strings for development.
More details here about the differences: https://learn.microsoft.com/en-us/azure/azure-functions/functions-develop-vs#create-an-azure-functions-project (scroll to the end of that section)
host.json reference
local.settings.json reference
You can add "ASPNETCORE_ENVIRONMENT": "Development" in the local.settings.json, to change the hosting environment:
As you know, local.settings.json is just for local testing and will not be published to azure portal. For host.json(which will be published to azure), you can configure settings like loglevel(if you want to log) in azure portal. More details, please refer to this article of host.json.
Sometimes, most times, Microsoft has strange ways of doing things... we as the community have to either find a way around them, or conform. Well, if you are one of those who cant survive the idea to conforming to something that doesn't make sense, here is a solution:
Delete local.settings.json
Create two files (or many, each for your environment), and name them {environment}.local.settings.json eg: development.local.settings.json and production.local.settings.json
Create a task to copy your current environment file to local.settings.json
Here we go again: we got to duplicate tasks...
[
{
"label": "use development.local.settings.json",
"command": "cp development.local.settings.json local.settings.json",
"type": "shell",
"options": {
"cwd": "${workspaceFolder}/..."
}
},
{
"label": "use production.local.settings.json",
"command": "cp production.local.settings.json local.settings.json",
"type": "shell",
"options": {
"cwd": "${workspaceFolder}/..."
}
},
{
"label": "azure-func-development",
"type": "func",
"dependsOn": [
"use development.local.settings.json",
"build"
],
"dependsOrder": "sequence",
"options": {
"cwd": "${workspaceFolder}/.../bin/Debug/netcoreapp2.2"
},
"command": "host start",
"isBackground": true,
"problemMatcher": "$func-watch"
},
{
"label": "azure-func-production",
"type": "func",
"dependsOn": [
"use production.local.settings.json",
"build"
],
"dependsOrder": "sequence",
"options": {
"cwd": "${workspaceFolder}/.../bin/Debug/netcoreapp2.2"
},
"command": "host start",
"isBackground": true,
"problemMatcher": "$func-watch"
}
]
Don't get tired, we are not finished duplicating, yet...
Lets duplicate the launch.json configurations:
[
{
"name": "[Development] Attach to Azure .NET Functions",
"type": "coreclr",
"request": "attach",
"preLaunchTask": "azure-func-development",
"processId": "${command:azureFunctions.pickProcess}"
},
{
"name": "[Production] Attach to Azure .NET Functions",
"type": "coreclr",
"request": "attach",
"preLaunchTask": "azure-func-production",
"processId": "${command:azureFunctions.pickProcess}"
}
]

Angular 2 Deployment to IIS with Visual Studio 2015 gives "route is undefined" error

I have a .Net core project in VS 2015 (update 3), using Angular 2, which is running perfectly in Visual Studio, using IIS Express, on a Windows 10 professional PC.
But when I deploy the application to my local IIS instance (using file system publish method), I get an error saying:
In Firefox: Uncaught (in promise): TypeError: route is undefined
In Chrome: Uncaught (in promise): TypeError: Cannot read property 'outlet' of undefined
I can't understand what would cause this, since it is working fine locally. I am not getting any 404 errors, and I can see on the Chrome network tab that tons of files are loading successfully.
I have not been able to find many deployment configuration parameters to tinker with. The stacktrace information is not at all helpful (to me), but may reveal something to someone, so here it is (from Firefox):
Unhandled Promise rejection: route is undefined ; Zone: angular ; Task: Promise.then ; Value: TypeError: route is undefined
Stack trace:
getOutlet$1#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:734:9
expandPathsWithParamsAgainstRoute#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:550:13
expandPathsWithParams#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:540:24
expandSegment#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:530:20
expandSegmentChildren/<#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:534:76
mapChildren/<#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:210:44
forEach#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:82:17
mapChildren#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:208:9
expandSegmentChildren#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:534:16
expandSegment#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:527:39
applyRedirects#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:503:43
Router</Router.prototype.runNavigate/<#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:1871:17
ZoneAwarePromise#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:584:30
Router</Router.prototype.runNavigate#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:1866:20
Router</Router.prototype.scheduleNavigation/<#http://localhost/CrsInstrNetCore/node_modules/#angular/router//bundles/router.umd.js:1851:65
Zone</ZoneDelegate</ZoneDelegate.prototype.invoke#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:323:20
NgZoneImpl/this.inner<.onInvoke#http://localhost/CrsInstrNetCore/node_modules/#angular/core//bundles/core.umd.js:9100:36
Zone</ZoneDelegate</ZoneDelegate.prototype.invoke#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:322:20
Zone</Zone</Zone.prototype.run#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:216:25
scheduleResolveOrReject/<#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:571:53
Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:356:24
NgZoneImpl/this.inner<.onInvokeTask#http://localhost/CrsInstrNetCore/node_modules/#angular/core//bundles/core.umd.js:9091:36
Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:355:24
Zone</Zone</Zone.prototype.runTask#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:256:29
drainMicroTaskQueue#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:474:26
ZoneTask/this.invoke#http://localhost/CrsInstrNetCore/node_modules/zone.js/dist/zone.js:426:22
I'm not at all sure what files would be helpful to show, since it's all working fine in the development environment. If useful, here is my tsconfig.json file:
{
"compilerOptions": {
"noImplicitAny": true,
"noEmitOnError": true,
"removeComments": false,
"sourceMap": true,
"target": "es5",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"module": "system",
"moduleResolution": "node"
},
"exclude": [
"node_modules",
"wwwroot"
]
}
Can anyone suggest how to explore/resolve the problem?
In my case, this was ultimately due to an extra comma inadvertently added to a *.routes.ts file. Took forever to figure it out, but turned out that the typo was the whole problem. "route" was undefined because there was nothing between two commas in the routes.ts file. All my own fault. :(

Resources