Generate DTOs in the client-side for static c# proxy generation

[hikalkan]

Static c# proxies currently depending on target service's application.contracts package, so they can reuse the DTOs and other related classes. However, that can be a problem when we want to create fully independently developed and deployed microservices. We want to use the static proxy generation even without depending target service's application.contracts package.

So, generate all the classes/enums/other types in the client side (including application service interfaces) when we use the abp generate-proxy -t csharp ... command (actually, only the types used in services - they are already exposed in the application configuration endpoint). This will be default, so it is a breaking change. If we have reference to the target contracts package, then we can pass a parameter --without-contracts (shortcut: -c). In this way, it exactly works like current (so, it won't be a big breaking change since we allow to go with the current style if user wants).

--without-contracts is also used by our own modules. Because, that's the only way to make a module as monolith & microservice (distributed) compatible. We should also remember to pass this parameter in the future, while generating proxies in the HttpApi.Client packages.

While generating application service interfaces, DTOs and other types, declare the types in the same namespace of they are declared. In this way, switching between static and dynamic proxies would be easier. We can also generate the classes in a similar place of their original folder/namespace structure. For example, we can place Volo.Abp.Identity.UserDto class in the /ClientProxies/Volo/Abp/Identity/UserDto.cs file (but with the Volo.Abp.Identity namespace) and Volo.Abp.Identity.IUserAppService in the /ClientProxies/Volo/Abp/Identity/IUserAppService.cs file, (but with the Volo.Abp.Identity namespace). For folder-namespace mismatch, we can use ReSharper disable once CheckNamespace like we do for the client proxy classes. We can also move the current client proxy classes inside the right folder (like /ClientProxies/Volo/Abp/Identity/IdentityRoleClientProxy for current IdentityRoleClientProxy)

Note: Users should be careful. If the client project already references to the app.contracts package, they should use the --without-contracts parameter. Otherwise, they will have conflicts for app service interfaces and DTO classes (they will be duplicated, one in the referenced app.contracts package, and one in the current project, with the same namespace and name).

[AdemAygun]

Can't proxy classes be used in domain layer? For example I would like to use it in a manager class.