Generated server lvlib should not make methods private that are needed to start the service

[jplotzke]

When using the latest v1.5.1.1 generation tool (I'm not sure how far back this was implemented), the generated server lvlib makes several top-level VIs in private scope. In my opinion, this limits useability and workflow of the toolkit. Specifically, Register gRPC Messages.vi, Register Descriptors.vi, and Get Service Class Instances.vi should be public scope.

For my use case, I have a set of gRPC services which I generate server/client VIs for, but I keep each service as a separate generated lvlib. I have several versions of a top-level gRPC server which pulls in different gRPC service lvlibs as necessary. Because these generated VIs are now in private scope, I have to manually reset these to public scope to use these methods outside the lvlib.

I personally only use the generated Run Service.vi for individual testing purposes. I love that it is there, but we shouldn't limit running the generated services to only that VI.

AB#3135155

[KarthikAbiram]

I faced the same issue and I agree with the above suggestion.

[BShermanator]

This is an issue, not an announce in my opinion. Now ever time I recompile my team has to manually go into every service and change the scope. Just updated from 1.2 to 1.5.1.1 due to security initiatives.

For reference, no one in the ADG System R&D team is using the "Run Service" VI. This VI is recreated every compile and cannot be be edited. All code from the gRPC scripting tool is seen as "autogenerated, do not edit" code.

An example of one of my LV gRPC servers that registers multiple services. The register messages cannot be private without a public way to achieve the same functionality.

[jplotzke]

@BShermanator - this will be fixed shortly with PR #451 . We've encapsulated the Register gRPC Messages.vi and Instantiate.vi into one Create Services.vi which is public scope of the lvlib.

For older code that was previously generated, there will be a small amount of rework to use the Create Services.vi instead, but then re-generation of a service in the future would not require any further modifications.

[BShermanator]

@kt-jplotzke - does this also take care of the "Server gRPC UEs.ctl" being moved to protected? I need that type definition and access so I can register for all the events of each service.

[jasonmreding]

I think #451 is an improvement. The only potential issue still for the code shown in the comment above is that you will get an array of service classes out that are typed to the base service class type. So if you want to store those instances in type specific fields of a cluster, you would need to perform trial and error downcasting to determine which instance is which. It is possible to do, but it is also pretty tedious.

[jasonmreding]

does this also take care of the "Server gRPC UEs.ctl" being moved to protected? I need that type definition and access so I can register for all the events of each service.

@BShermanator what is the desire for doing this outside of the generated Start Sync.vi and Start Async.vi? Is this because of the poor separation between the generated code and how you would extend it without modifying the generated code? If so, I would rather focus on improving the server code generation so that this sort of thing was unnecessary.

[jplotzke]

I think #451 is an improvement. The only potential issue still for the code shown in the comment above is that you will get an array of service classes out that are typed to the base service class type. So if you want to store those instances in type specific fields of a cluster, you would need to perform trial and error downcasting to determine which instance is which. It is possible to do, but it is also pretty tedious.

...but only if you generate an lvlib with multiple services in it. If you create one service in each lvlib, you'd have multiple Create Services.vi, one from each lvlib, which each output one service class element. You'd still have to cast those elements to a specific type if desired, but the trial and error goes away.

I agree that this isn't the perfect approach, but given some current limitations in the generator provides a step in the right direction.

[BShermanator]

Talked to Jason on Teams at NI.

Going to post another issue and link to the PR