-
Notifications
You must be signed in to change notification settings - Fork 357
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
Where did QueueTrigger attribute go? #1870
Comments
These are part of a new Microsoft.Azure.WebJobs.Extensions.Storage package |
Thanks, just downloaded it and found it! But now I can't find where JobHostConfiguration went :-) |
I have been using WebJobs in a dotnet core project, so I have code like this: ` class Program
Maybe the approach is completely different now? Where do I find the new pattern? This is deployed along with a netcore webapi to an Azure App Service |
You're right, there's a whole new way to configure webjobs that's based on the generic host which is similar to the asp.net host. Here's an example of the new setup https://github.com/Azure/azure-webjobs-sdk/blob/00686a5ae3b31ca1c70b477c1ca828e4aa754340/sample/SampleHost/Program.cs |
I am not going to switch to 3.0.0 from 3.0.0-beta5 because the whole thing needs to be reworked. Thanks a lot for breaking changes. |
There is zero documentation on this breaking change. Could someone please convert this to the new way? A code snippit tells me nothing. It explains zero things.
Really what i need to know if how to set up a NameResolver using the new methods ETA: |
This team is the worst with regard to breaking changes. |
So how come when I create a new WebJob project in Visual Studio with the latest updates it uses the old, invalid configuration? And using the new way I get an assortment of errors:
This is with the "latest stable" package versions. What package versions am I meant to be using? |
Of what benefit is it for them to try to share a common generic host builder, when there is nothing common or generic about the host? This is a thing that happens at the start of an application, where the abstractions haven't even started yet and you're declaring, in definite and specific terms, exactly what you want to happen. It's the rest of the code that needs to be agnostic to the type of app it's running in. Building the host is where you declare unambiguously what type of app is running. Taking it a step farther than the rest who downgraded their SDK, I literally switched off Azure Webjobs entirely as a direct result of this change. Worst. |
Wow, nothing more fun than expecting to spend a couple of hours doing something you've done successfully before to find that the process has completely changed and no longer works! Is it impossible to use WebJobs with .NET framework now? I can't tell if we're supposed to be able to include some Core libraries or if we have to completely switch to it to make this work? VS 2017 sample. Wow, this is really terrible!!! Two hours of googling and I'm no better off than when I started. Can anyone point me to a simple example using a SCHEDULED webjob in C# .NET F/W - I don't need processing queues or anything fancy. Just some maintenance work that should be done every day to clean up expired assets. |
I'm so confused, so if we create a WebJobs project and upgrade all the packages, it totally breaks. Is this upgraded project still the old .NET Framework or has updating all these packages made it a .NET Core project? There is no information on this or how to get it compiling. |
I tried upgrading from 3.0.0 beta5 to beta8, and [QueueTrigger] no longer resolves when compiling
The text was updated successfully, but these errors were encountered: