1. Should I create multiple services under one solution?
As Anton have already said, this really depends on the scope/size of your application/each microservice. If you have several team members working on it, you should definitely divide it into separate git repos to avoid conflicts. If you're a relatively small team, then I would create one parent solution with a child solution for each microservice.

2. Should I create a new solution for each service?
Yes, but whether or not to keep them in the same git repo depends on the size of the application/the project. Read 1.

3. Should I create API Gateway as an app in seperate solution or under existing solution (e.g. along with one of the services)?
Again, depends on the scope of your project. If you need/want services such as load balancing, networking and will potentially run the solution on several nodes (servers), then I'd use something like Kubernetes or Docker Swarm to handle the gateway to your microservices API's. If you decide to do the orchestration themselves, I would use something like KrakenD to handle the gateway stuff for you, or you can create an app yourself.

4. Should I always containerize microservices or not?
I highly suggest doing so, the issue with not containerizing them is that it requires you to handle all runtimes and stuff yourself, aka installing .NET core etc. There's also other considerations when not containerizing your apps, but for a microservice solution, I don't see a reason why you wouldn't want containers, it makes your life easier.

5. Is it possible to deploy microservices apps without containerization?
Ofcourse it is, but you need to handle alot of configuration stuff yourself, making features such as CD (Continous Deployment) much harder to implement. The reason being that you manually have to go into your server, pull the changes from your repo and redeploy.

6. I have one server with one database where all data is stored. I read that each service should have its own database. Can I use one database for each service (but each service will be using different tables , not share the same tables)?
Ofcourse you can, but the problem with such a solution is that if your one database runs into issues (crashes, gets corrupted and such), your whole application goes down, which often breaks the principles of why you want a microservice architecture in the first place. If you have a database instance per microservice, then if one of the databases dies, you still have all other microservices running, because they are not dependent on each other.

7. Does it make sense to create seperate service where all required data from database/s is stored (e.g. data from a few servers)? And then other services (e.g. Payments, Products, Clients etc.) would communicate with this data service to make CRUD operations? Normally, each service should have its own database but what about this approach?
Again, definitely a solution that could work, but then the microservices becomes dependent on each other. It's your choice and it depends on your (or your customer's) requirements for your application/architecture.

1. Should I create multiple services under one solution?
As Anton have already said, this really depends on the scope/size of your application/each microservice. If you have several team members working on it, you should definitely divide it into separate git repos to avoid conflicts. If you're a relatively small team, then I would create one parent solution with a child solution for each microservice.

2. Should I create a new solution for each service?
Yes, but whether or not to keep them in the same git repo depends on the size of the application/the project. Read 1.

3. Should I create API Gateway as an app in seperate solution or under existing solution (e.g. along with one of the services)?
Again, depends on the scope of your project. If you need/want services such as load balancing, networking and will potentially run the solution on several nodes (servers), then I'd use something like Kubernetes or Docker Swarm to handle the gateway to your microservices API's. If you decide to do the orchestration themselves, I would use something like KrakenD to handle the gateway stuff for you, or you can create an app yourself.

4. Should I always containerize microservices or not?
I highly suggest doing so, the issue with not containerizing them is that it requires you to handle all runtimes and stuff yourself, aka installing .NET core etc. There's also other considerations when not containerizing your apps, but for a microservice solution, I don't see a reason why you wouldn't want containers, it makes your life easier.

5. Is it possible to deploy microservices apps without containerization?
Ofcourse it is, but you need to handle alot of configuration stuff yourself, making features such as CD (Continous Deployment) much harder to implement. The reason being that you manually have to go into your server, pull the changes from your repo and redeploy.

6. I have one server with one database where all data is stored. I read that each service should have its own database. Can I use one database for each service (but each service will be using different tables , not share the same tables)?
Ofcourse you can, but the problem with such a solution is that if your one database runs into issues (crashes, gets corrupted and such), your whole application goes down, which often breaks the principles of why you want a microservice architecture in the first place. If you have a database instance per microservice, then if one of the databases dies, you still have all other microservices running, because they are not dependent on each other.

7. Does it make sense to create seperate service where all required data from database/s is stored (e.g. data from a few servers)? And then other services (e.g. Payments, Products, Clients etc.) would communicate with this data service to make CRUD operations? Normally, each service should have its own database but what about this approach?
Again, definitely a solution that could work, but then the microservices becomes dependent on each other. It's your choice and it depends on your (or your customer's) requirements for your application/architecture.

public class Subject
{
    public Element Element { get; set; }
}

public class Element
{
    [JsonProperty("@SbId")]
    public int SbId { get; set; }

    public Fields Fields { get; set; }

    public List<Object> Objects { get; set; }
}

public class Fields
{
    public int StId { get; set; }
    public string Ds { get; set; }
    public DateTime Da { get; set; }
}

public class Object
{
    [JsonProperty("SubjectLink")]
    public SubjectLink SubjectLink { get; set; }

    [JsonProperty("SubjectAttachment")]
    public SubjectAttachment SubjectAttachment { get; set; }
}

public class SubjectLink
{
    public Element Element { get; set; }
}

public class SubjectAttachment
{
    public Element Element { get; set; }
}

public class Subject
{
    public Element Element { get; set; }
}

public class Element
{
    [JsonProperty("@SbId")]
    public int SbId { get; set; }

    public Fields Fields { get; set; }

    public List<Object> Objects { get; set; }
}

public class Fields
{
    public int StId { get; set; }
    public string Ds { get; set; }
    public DateTime Da { get; set; }
}

public class Object
{
    [JsonProperty("SubjectLink")]
    public SubjectLink SubjectLink { get; set; }

    [JsonProperty("SubjectAttachment")]
    public SubjectAttachment SubjectAttachment { get; set; }
}

public class SubjectLink
{
    public Element Element { get; set; }
}

public class SubjectAttachment
{
    public Element Element { get; set; }
}