Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooling Issue with Binding direction #1507

Closed
mathewc opened this issue May 12, 2017 · 13 comments
Closed

Tooling Issue with Binding direction #1507

mathewc opened this issue May 12, 2017 · 13 comments

Comments

@mathewc
Copy link
Member

mathewc commented May 12, 2017

The logic our VS tooling uses to determine the direction of a binding is too simple. E.g. currently it (from @ahmelsayed):

  • assume it's "out"
  • if it's a trigger, then it's "in"
  • if there is a FileAccess property on the attribute, then use it

However, for many input bindings (e.g. Bot IDirectLineClient, NotificationHubClient, etc.) this doesn't work, and ends up generating incorrect metadata, causing runtime failures.

We need to update IJobHostMetadataProvider to be able to serve the correct information.

@mathewc
Copy link
Member Author

mathewc commented May 12, 2017

@MikeStall
Copy link
Contributor

The ideal fix is #1508

That's complicated.

  • We could make short term tactical fixes. The VS tooling could match to 'out' via the parameter signature (out T, ICollector, etc)
  • more accurate would be to traverse the graph.

@colbylwilliams
Copy link
Member

Correct me if I'm wrong, but the project type included with the new VS tooling requires the use of attribute-based binding - there's no way to "opt out" and manually provide the function.json file? If that's the case, what is the best alternative approach to writing Azure Functions with VS17? Create an empty asp web app and call the command line tools post build?

@mathewc
Copy link
Member Author

mathewc commented May 13, 2017

@paulbatum and I just tried and we were unable to get the workaround of providing your own function.json to work, though we think it should. @lindydonna might know of a way?

@lindydonna
Copy link
Contributor

Make sure you set function.json to copy to output directory, and use the same folder name as function. You can't use attributes in that same function though, because the output will be overwritten by the build step. Perhaps that's what you meant?

@colbylwilliams
Copy link
Member

Not what I meant, but makes perfect sense. I'll give that a shot. Thanks.

@colbylwilliams
Copy link
Member

@lindydonna Unfortunately I couldn't get your suggestion to work. As soon as a add a MyFunctionName\function.json to the csproj, the MyFunctionName directory isn't added to the output directory on build.
Now, if I try the same thing with a new json file named anything other than function.json, it copies the file to the output directory as expected. Not sure what I'm doing wrong, or if its a bug in the build step. My project is here, and the specific function is GetBotToken

@lindydonna
Copy link
Contributor

@ahmelsayed Could you take a look?

@ahmelsayed
Copy link
Contributor

the problem is you fighting with the cleanup logic for the build task which deletes any folder with a function.json in it. Let me think about it.

@lindydonna
Copy link
Contributor

@colbylwilliams I've created this issue to track the function.json problem: Azure/azure-functions-vs-build-sdk#44

@paulbatum paulbatum added this to the May 2017 milestone May 19, 2017
@paulbatum paulbatum assigned ahmelsayed and unassigned MikeStall May 19, 2017
@paulbatum
Copy link
Member

@mathewc will work with @ahmelsayed on getting the right fix into the MakeFunctionJson tool until the real fix #1508 happens.

@paulbatum
Copy link
Member

I also moved the discussion about being able to manually add a function.json when using the VS tooling to Azure/azure-functions-vs-build-sdk#50

@christopheranderson christopheranderson added this to the Next - Triaged milestone Jul 7, 2017
@lindydonna
Copy link
Contributor

Closing in favor of #1508.

@ghost ghost locked as resolved and limited conversation to collaborators Jan 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants