Go Back
1 Vote

Documentation of DotNetAssembly Should Be Improved To Describe Logical Pathing Logic

As of 2019/08/21 looking at the BETA (v11) version of the DotNetAssembly Document (https://www.synergex.com/docs/versions/v111/#lrm/lrmChap21DOTNETASSEMBLY.htm) mentions:

Name can include an environment variable using the standard Synergy syntax (for example, MYVAR:) unless the .NET display name form is used.

Although the .NET assembly API supports search paths, we don't recommend that you use them. Search paths only work at runtime, and the gennet40 utility does not support them.

Search Paths (or as we call it Logical Pathing) are defined as a Logicals that contain this form:

When Logical Pathing is used as a parameter to DotNetAssembly the following behavior is observed:
  • The FIRST Path that Contains the File Name Will Be Sent to the ResolveEventHandler event (https://docs.microsoft.com/en-us/dotnet/api/system.resolveeventhandler?view=netframework-4.8)
  • If the file does not exist in any of the paths the LAST path will be sent to the ResolveEventHandler
Is this expected behavior? If so we request that this behavior be documented.

This behavior is observed by us due to our Interop implementing a custom ResolveEventHandler to allow us to load assemblies from the path containing the DBR Application, NOT The DBR Runtime. (See https://synergexresourcecenter.force.com/SiteIdea?id=0870d000000bppFAAQ).

Furthermore it appears that dbr.exe performs some type of caching on the INITIAL Value of the logical, such that subsequent invocations of DotNetAssembly will used this cached value. Is this expected behavior?

This is important because it is possible (as it is in our system) to have the value of this logical changed during the execution of the program. For us it is not particularly important that this value change (in fact it probably is good that it does not) but it was unexpected from a documentation standpoint.

3 Comments | Posted by Ace Olszowka to Synergy DBL, Documentation on 8/22/2019 8:23 PM
Although the API allows logical pathing, we don’t think it should be used, and we don’t officially support this usage. We’ll leave the current behavior so it will continue to work for those using it, but we don’t feel we should document it any further. We will clarify our position on it more clearly in the documentation, i.e., we’ll say the API allows search paths instead of saying it supports them.

12/12/2019 7:00 PM   0  
Ace Olszowka
What about the caching behavior? At what point is the Logical evaluated?

12/12/2019 7:16 PM   0  
Ace Olszowka
This is currently held up in my court to provide a sample that shows the scenario in action.

12/13/2019 5:32 PM   0  
Please log in to comment on this idea.