Closed roehlerw closed 5 years ago
From Microsoft Documentation https://docs.microsoft.com/en-us/dotnet/core/deploying/
Self-contained deployments (SCD) For a self-contained deployment, you deploy your app and any required third-party dependencies along with the version of .NET Core that you used to build the app. Creating an SCD doesn't include the native dependencies of .NET Core on various platforms, so these must be present before the app runs. For more information on version binding at runtime, see the article on version binding in .NET Core.
Starting with NET Core 2.1 SDK (version 2.1.300), .NET Core supports patch version roll forward. When you create a self-contained deployment, .NET Core tools automatically include the latest serviced runtime of the .NET Core version that your application targets. (The latest serviced runtime includes security patches and other bug fixes.) The serviced runtime does not have to be present on your build system; it is downloaded automatically from NuGet.org. For more information, including instructions on how to opt out of patch version roll forward, see Self-contained deployment runtime roll forward.
FDD and SCD deployments use separate host executables, so you can sign a host executable for an SCD with your publisher signature.
Why deploy a self-contained deployment? Deploying a Self-contained deployment has two major advantages:
You have sole control of the version of .NET Core that is deployed with your app. .NET Core can be serviced only by you.
You can be assured that the target system can run your .NET Core app, since you're providing the version of .NET Core that it will run on.
It also has a number of disadvantages:
Because .NET Core is included in your deployment package, you must select the target platforms for which you build deployment packages in advance.
The size of your deployment package is relatively large, since you have to include .NET Core as well as your app and its third-party dependencies.
Starting with .NET Core 2.0, you can reduce the size of your deployment on Linux systems by approximately 28 MB by using .NET Core globalization invariant mode. Ordinarily, .NET Core on Linux relies on the ICU libraries for globalization support. In invariant mode, the libraries are not included with your deployment, and all cultures behave like the invariant culture.
Deploying numerous self-contained .NET Core apps to a system can consume significant amounts of disk space, since each app duplicates .NET Core files.
Zoho Developer Documentation https://www.zoho.com/crm/help/api/v2/#api-reference
OAuth2 Notes Agent will be responsible for initial authorization from user. Agent will pass refresh token, client id, and client secret to the plugin. Plugin will generate and maintain valid authentication tokens for making requests
.NET Core Publishing Command
dotnet publish -c Release -r [RID]
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r osx-x64
dotnet publish -c Release -r linux-x64
RID Documentation https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
grpc proto building command Run inside the Plugin-Zoho project directory Windows
%UserProfile%\.nuget\packages\Grpc.Tools\1.17.0\tools\windows_x86\protoc.exe -I../ --csharp_out ./Publisher --grpc_out ./Publisher ../publisher.proto --plugin=protoc-gen-grpc=C:\Users\Laptop\.nuget\packages\grpc.tools\1.17.0\tools\windows_x86\grpc_csharp_plugin.exe
Linux
~/.nuget/packages/grpc.tools/1.17.0/tools/linux_x64/protoc -I../ --csharp_out ./Publisher --grpc_out ./Publisher ../publisher.proto --plugin=protoc-gen-grpc=$HOME/.nuget/packages/grpc.tools/1.17.0/tools/linux_x64/grpc_csharp_plugin
Child of naveegoinc/epics#29
Create Zoho plugin.
Design plugin in such a way that the web API connection component can be picked up and moved into a common location if necessary.