Fix: unify Grpc dependency

[Wi1l-B0t]

There are different Grpc dependency versions.

So add this to unify Grpc dependency.

[ajara87]

require #945

[vncoelho]

It will possibly solve #942, but other loading problems will remain, we can address later.

[vncoelho]

Not in this specific case, but related.

Does SignPlugin needs to specify all these versions listed below?

	
		<PackageReference Include="Grpc.Net.Client" Version="2.71.0" />
		<!-- NOTE: Need install rosetta2 on macOS ARM64 -->
		<PackageReference Include="Grpc.Tools" Version="2.76.0" PrivateAssets="all" /```

[Wi1l-B0t]

Not in this specific case, but related.

Does SignPlugin needs to specify all these versions listed below?

		<PackageReference Include="Google.Protobuf" Version="3.33.1" />
		<PackageReference Include="Grpc.Net.Client" Version="2.71.0" />
		<!-- NOTE: Need install rosetta2 on macOS ARM64 -->
		<PackageReference Include="Grpc.Tools" Version="2.76.0" PrivateAssets="all" /```

Other versions are also OK.

[vncoelho]

I mean, do we need to really specify each sub-library of GRPC in SignPlugin? @shargon

Do we really need this for safety?
Maybe also incompatibilities can reach in such use.

[Wi1l-B0t]

I mean, do we need to really specify each sub-library of GRPC in SignPlugin? @shargon

Do we really need this for safety? Maybe also incompatibilities can reach in such use.

Optimized.

[vncoelho]

How about GRPC tools still in a different version?

[erikzhang]

I think the core to solving this problem is to load each plugin into a different AppDomain, so that they can avoid interfering with each other.

[vncoelho]

@erikzhang, I think that different AppDomain solves this dependencies problems in way that each plugin could indeed have its own packages without conflicts.

Additionally, we still have plugins that depends on each other, for example plugins that depends on RPCServer.
In this sense, we need to understand when each AppDomain will interact with the other and avoid duplicating loading of RPCServer dll for example.

[vncoelho]

In any case, although its is important and good to create a better design of these plugins loading and its domains, this is not really critical.
But I believe that a good design here opens possibilities for better security and organization of the project.

[shargon]

I think the core to solving this problem is to load each plugin into a different AppDomain, so that they can avoid interfering with each other.

Agree, but we tried with lot of erros, because we need to comunicate between plugins

[erikzhang]

Agree, but we tried with lot of erros, because we need to comunicate between plugins

What kind of communication?