Throw if the update handler service is not registered with the IoC container.

First cancellation token passed to the update delegate should be None for the polling update and request's timeout for the webhooks.

In your current implementation all update handlers share a scope because getUpdates can return more than one update at a time. I think it would be better if every individual update would have it's own scope. It can be achieved by using IServiceScopeFactory and explicitly creating scope for each update inside HandleUpdateAsync.

What do you think of the idea making update handlers more like middlewares is ASP.NET Core which share mutable context instance? That way there could be a common session middleware (e.g. with separate storages for a chat and a user). Or a middleware that constructs ClaimsPrincipal and attaches it to the context instance. It would open possibilities to leverage existing packages from ASP.NET Core that aren't tied to HttpContext or HTTP in general like Authorization.

The UseWhen method doesn't wire up the next delegate properly.

Expected

In the example pipeline below, the C middleware should be the next delegate passed to the B middleware. Therefore, C should be invoked only if next is invoked in the B.

new BotBuilder()
  .Use<A>()
  .UseWhen(predicate, branch =>
    branch.Use<B>()
  )
  .Use<C>()

Actual

But the C middleware is always invoked regardless of calling the next delegate in B.

Methods of a command class (canHandle, parse, handle) should only get a Message as input not the Update because it could be confusing to the user.

Also, updates of types other than [Edited]MessageUpdate are never considered as command.

btw, CommandBase.CanHandleCommand doesn't need to be virtual.

A certificate is optional for webhook.

Are they ok? )

Hi, im trying to add telegram bots after the startup class has been loaded. Any examples of that?

Thanks for a great library.

Return false if not a message update

Scoped lifetime of IUpdateManager<TBot> and polling functionality built in it don't play well together. An entity that performs polling should be a singleton.

IUpdateManager<TBot> functionality should be split to two interfaces:

• IUpdateDispatcher<TBot> that performs dispatching and could has either scoped or transient lifetime
• An entity that performs actual polling and has dependency on a factory that creates IUpdateDisptacher<TBot> instance and has singleton lifetime so it correctly incapsulates update offset

It would be nicer to handle updates of a specific type.

Cleaner code:

class MyClass {
    void RespondMessageWithWelcome(Update<MessageUpdate> msgUpdate) { }
    void ReplyToCallbackquery(Update<CallbackQueryUpdate> queryUpdate) { }
}

Possible implementation:

Update Types:

abstract class UpdateContentBase { }
class MessageUpdate : UpdateContentBase { }
class CallbackQueryUpdate : UpdateContentBase { }

New Update class:

interface IUpdate<out T> where T : UpdateContentBase, new() {
    T Content { get; }
}

class Update<T> : IUpdate<T> where T : UpdateContentBase, new() {
    public T Content { get; }
    public Update(T content) {
        Content = content;
    }
}

Not really sure if this is going to work.

Parse the args from text in the CommandBase

It seems telegram server requires TLS1.2.
Add this before botclient.SendTextMessageAsync():

Net.ServicePointManager.SecurityProtocol = Net.SecurityProtocolType.Tls12

Hi!

I see there are two similar nuget packages created by you, both for Telegram Bot. They both can target asp.net core, thus it's not clear how are they different and when to use each of those.

Could you clarify on that?

Default timeout in GetUpdateAsync method is set to 0. BotManager should take timeout from ITelegramBotClient and pass it to GetUpdatesAsync method. I think there also should be a config for timeout in BotOptions.

There is a problem with IBotManager<TBot> instances lifetime in webhook mode. Each middleware in ASP.NET Core is instantiated once and is kept in memory as a part of middleware pipeline. So it is essentially a singleton. But IBotManager<TBot> has scoped lifetime. IBotManager<TBot> should be injected as a parameter of Invoke method here.

No more Edit & Resend scores on Game Bots!

Command names are extracted from message text using a regex. Use message entities instead.

Perhaps UseCommand() should not be a terminating middleware like Map.

How should I send score to a game backend? It's not well described in the documentation.
Could you please help me with that?

When used with ASP.NET Core 2.0 and ASPNETCORE_ENVIRONMENT is set to Development and long polling mode is used UseTelegramBotLongPolling throws this exception.

Creating explicit scope inside extension methods (UseTelegramBotWebhook, etc) and passing scoped ServiceProvider to FindBotManager helps but I don't understand why. When used with webhook everything works fine and no exception is thrown.

Making requests when getting updates is a great feature but how to implement it?

nGetting build error for sample echo bot project. Tried referring the Telegram Framework project and from

Nuget.