# Introduction

### Why was Telegram.Bots made?

I wanted to make a Telegram bot for my personal use and C# happened to be a reasonable language to write it in. I tried using the popular .NET Client for Telegram Bot API but found various issues with it during my use of it that I decided to make a wrapper for the Telegram Bot API from scratch, free from the implementation and interface issues I experienced in that library.

### Why did you not simply fix those issues in that popular library?

Two words: **breaking changes**. My ideas for the Telegram Bot API wrapper were different enough to warrant breaking changes in that library. I did not want to break it and it would have been unreasonable to expect the caretakers of that library to accept my breaking changes, especially since the library does get its work done in most cases without really needing the changes I wanted in the library.

### Can you give an example of a major difference between that popular library and Telegram.Bots?

Sure. I will give three but there are more:

* That popular library throws exceptions when the Telegram servers return a failure response. That library also throws exceptions in cases where tasks are canceled or a timeout occurs. `Telegram.Bots`, on the other hand, returns the failure response during a failure. Even when a task is canceled or a timeout occurs, a failure response is returned with appropriate information. I found the exception-based approach to require me to learn the ways of the library in order to write resilient code. `Telegram.Bots` leaves the exceptions for exceptional cases.
* That popular library maps each type made known by the Telegram Bot API documentation in pretty much the same manner as the documentation does. It does improve in some ways, particularly in places where types involve inline message targeting but it is still limited. `Telegram.Bots`, on the other hand, uses types in a manner which facilitates pattern matching on the types and allows only the data which is reasonable for any given type. For example, `Telegram.Bots` has a `TextMessage` type for text messages and `StickerMessage` for messages that are stickers, and so on. That popular library has a `Message` type to denote all kinds of messages and so there is a relative overhead with respect to object creation as well (since that class is bloated with unnecessary properties for any given type of message).
* `Telegram.Bots` does not allow you to send useless information. Like, did you know that you can set up the title of an audio only when you are sending it as a file or as an inline audio result? If you send an audio as a URL or as a cached file, setting up the title in the request does not make any difference. `Telegram.Bots` takes care of all these cases.

### For whom is Telegram.Bots written?

`Telegram.Bots` was primarily written to meet my particular aesthetic preferences and simplicity standards and I will be happy if you try it out and see the difference it makes in your journey to make interesting bots. That is why I made it available as a free and open source software and am writing all this documentation to make the process easier for those interested in trying `Telegram.Bots` out for themselves.

`Telegram.Bots` supports .NET Standard 2.1. Using `Telegram.Bots` will be a good idea for you if you are also interested in utilizing the new language and runtime features.

### Alright, I am interested. Show me some code.

`Telegram.Bots` has some niceties which can be leveraged by utilizing the `Microsoft.Extensions.DependencyInjection` package. We will use that as it makes the code more manageable.

Here is one way you can get and then print the information about your bot:

```csharp
using System;
using System.Threading.Tasks;
using Microsoft.Extensions.DependencyInjection;
using Telegram.Bots.Requests;
using Telegram.Bots.Types;

namespace Telegram.Bots.Example
{
  public static class Program
  {
    private static async Task Main()
    {
      var provider = new ServiceCollection()
        .AddBotClient("<bot-token>")
        .Services
        .BuildServiceProvider();

      var bot = provider.GetRequiredService<IBotClient>();

      Response<MyBot> response = await bot.HandleAsync(new GetMe());
      
      var serializer = provider.GetRequiredService<ISerializer>();

      Console.WriteLine(serializer.Serialize(response, Styling.Indented));
    }
  }
}
```

�Of course, both Telegram and I expect you to not hard-code your bot token if you intend to make your program's source code free and open source (which is a great idea). But this one's an example. You can read the configuration from `appsettings.json` or read the bot token from the environment variable or load it up from some secret vault. Your choice.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://telegrambots.gitbook.io/book/master.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.