blog add blog

contents/_draft/2021-10-05-aspnet-framework-build-deploy-github-action/readme.md

@@ -11,7 +11,8 @@ unsplashImgCoverId: VUBAE-Bmugk
 ---
 
 
-![](github-action.png)
+No need to use publish po[]\
+
 
 ```yml
 name: Build and deploy ASP app to Azure Web App
@@ -34,7 +35,7 @@ jobs:
 
     - name: Setup NuGet
       uses: NuGet/[email protected]
-
+  qwertyuogp[]\
     - name: Restore NuGet packages
       run: nuget restore
 
@@ -57,7 +58,7 @@ jobs:
     steps:
     - name: Download artifact from build job
       uses: actions/download-artifact@v2
-      with:
+      with:qw ertyuiogrtyuiop[]\
         name: ASP-app
 
     - name: Deploy to Azure Web App
@@ -68,6 +69,8 @@ jobs:
         publish-profile: ${{ secrets.AzureAppService_PublishProfile }}
         package: .
 ```
-
+![](github-action.png)
 
 Ref: https://timheuer.com/blog/building-net-framework-apps-using-github-actions/
+
+

contents/posts/2023-09-20-azure-functions-v4-weird-part-ep1.md

@@ -0,0 +1,107 @@
+---
+title: Azure Functions Node.js v4 with TypeScript Weird Part EP.1
+uuid: 2blwllg
+tags:
+  - Azure Functions
+  - TypeScript
+---
+
+Welcome to the first episode of our "Azure Functions Node.js v4 with TypeScript Weird Part" series. In this series, we'll dive into some intriguing nuances and challenges you might come across while working with Azure Functions in Node.js version 4, especially when using TypeScript. In this episode, we'll explore a type-safety issue that arises when dealing with input and output bindings and provide a practical workaround.
+
+## The Official Documentation
+[Azure Functions version 4.0.0-alpha.12](https://www.npmjs.com/package/@azure/functions/v/4.0.0-alpha.12) introduces a host of exciting features and improvements. However, as you explore this version, you might encounter a seemingly peculiar issue when working with input and output bindings. Let's examine the official documentation to get a better understanding.
+
+### Input Binding
+According to the official documentation, you can define an input binding as follows:
+
+```typescript
+const blobInput = input.storageBlob({
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-input/xxx.txt',
+});
+
+// To retrieve the value in the handler function, you can use:
+const blobInputValue = context.extraInputs.get(blobInput);
+```
+
+### Output Binding
+Similarly, for output bindings:
+
+```typescript
+const blobOutput = output.storageBlob({
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-output/xxx-{rand-guid}.txt',
+});
+
+// To set the value in the handler function, you can use:
+context.extraOutputs.set(blobOutput, blobInputValue);
+```
+
+## The Type-Safety Issue
+At first glance, everything seems fine. However, there's a catch - a lack of type-safety. The issue becomes evident when you attempt to assign a name to your input or output bindings, like so:
+
+```typescript
+const blobInput = input.storageBlob({
+  name: 'MyBlobInput', // Error: 'name' does not exist in type 'StorageBlobInputOptions'.
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-input/xxx.txt',
+});
+
+const blobOutput = output.storageBlob({
+  name: 'MyBlobOutput', // Error: 'name' does not exist in type 'StorageBlobOptions'.
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-output/xxx-{rand-guid}.txt',
+});
+```
+
+As you can see, TypeScript complains that 'name' does not exist in the type 'StorageBlobInputOptions' even though the documentation suggests using it. This can be quite frustrating for developers looking to add some meaningful names to their bindings.
+
+### The Workaround
+But don't worry, there's a workaround that allows you to use 'name' and call it later in the handler function while maintaining type-safety. Let's see how it's done:
+
+```typescript
+import {
+  app,
+  input,
+  InvocationContext,
+  output,
+  HttpRequest,
+  StorageBlobInputOptions,
+  StorageBlobOptions,
+} from '@azure/functions';
+
+const blobInput = input.storageBlob({
+  name: 'MyBlobInput',
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-input/xxx.txt',
+} as StorageBlobInputOptions & { name: string });
+
+const blobOutput = output.storageBlob({
+  name: 'MyBlobOutput',
+  connection: 'AzureWebJobsStorage',
+  path: 'demo-output/xxx-{rand-guid}.txt',
+} as StorageBlobOptions & { name: string });
+
+app.get('copyBlob', {
+  authLevel: 'anonymous',
+  extraInputs: [blobInput],
+  extraOutputs: [blobOutput],
+  handler: (req: HttpRequest, context: InvocationContext) => {
+    context.log('Storage queue function processed work item:', req);
+
+    const blobInputValue = context.extraInputs.get('MyBlobInput');
+    context.extraOutputs.set('MyBlobOutput', blobInputValue);
+
+    return {
+      body: `Hello, ${blobInputValue}!`,
+    };
+  },
+});
+```
+
+By using type assertions (as) to extend the StorageBlobInputOptions and StorageBlobOptions types with the 'name' property, we can now use 'name' and maintain type-safety in our code.
+
+## In Conclusion
+In this episode of "Azure Functions Node.js v4 with TypeScript Weird Part," we've explored a type-safety issue related to defining names for input and output bindings. While this issue may appear unusual, we've provided a practical workaround that allows you to use the 'name' property as intended without compromising TypeScript's valuable type-checking features.
+
+As I prepare to submit your Pull Request and engage in discussions with the project's author, Keep an eye out for upcoming episodes in this series, where we'll continue to investigate and resolve other peculiar aspects of working with Azure Functions in Node.js v4 and TypeScript. Happy coding, fellow geeks!