ProxyGen for .Net is not working (when using "PathFinder.exe") - Forum - OpenEdge Development - Progress Community

ProxyGen for .Net is not working (when using "PathFinder.exe")

 Forum

ProxyGen for .Net is not working (when using "PathFinder.exe")

This question is answered

Does anyone have experience with .Net proxygen?  There is a wierd little executable that is run during proxygen called "PathFinder.exe" (at C:\Progress\OpenEdge\bin\).  It seems to only be used if the compiler option is set up for "default csc" (instead of "custom").

To make a long story short, the "PathFinder.exe" is a bit confused on my machine and it is finding the wrong csc, and not finding xsd.exe at all.  Would love to hear if anyone else is using the "default csc" option, and understands the expected behavior of "PathFinder.exe" as it tries to find the paths for compiler tools.

Based on the only KB article I could find, https://knowledgebase.progress.com/articles/Article/P101529 , I'm wondering if it does little more than search the PATH environment variable.  It seems to be a pretty unreliable way of locating compiler-related tools.  It reminds me of the old "I'm feeling lucky" button in google. 

Verified Answer
  • When you use the /csc option PathFinder does the following:

    Check that HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\\.NETFramework exists. If not, throw an exception.

    Look at the InstallRoot value in SOFTWARE\\Microsoft\\.NETFramework to see where .NET is installed on the machine. Call this frameworkdir. It will be something like c:\Windows\Microsoft.NET\Framework64

    Enumerate the keys under SOFTWARE\\Microsoft\\.NETFramework\\Policy. If a key starts with the letter 'v' get the first subkey. For example, if it finds SOFTWARE\\Microsoft\\.NETFramework\\Policy\v4.0 it looks there to find the first subkey. On my machine it's SOFTWARE\\Microsoft\\.NETFramework\\Policy\v4.0\30319.

    Put everything together: frameworkdir + version + subkey -> c:\Windows\Microsoft.NET\Framework64\v4.0.30319

    Look for csc.exe in that directory.

    It will look through all installed versions looking for the highest framework version supported by the version of OpenEdge you're using.

All Replies
  • When you use the /csc option PathFinder does the following:

    Check that HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\\.NETFramework exists. If not, throw an exception.

    Look at the InstallRoot value in SOFTWARE\\Microsoft\\.NETFramework to see where .NET is installed on the machine. Call this frameworkdir. It will be something like c:\Windows\Microsoft.NET\Framework64

    Enumerate the keys under SOFTWARE\\Microsoft\\.NETFramework\\Policy. If a key starts with the letter 'v' get the first subkey. For example, if it finds SOFTWARE\\Microsoft\\.NETFramework\\Policy\v4.0 it looks there to find the first subkey. On my machine it's SOFTWARE\\Microsoft\\.NETFramework\\Policy\v4.0\30319.

    Put everything together: frameworkdir + version + subkey -> c:\Windows\Microsoft.NET\Framework64\v4.0.30319

    Look for csc.exe in that directory.

    It will look through all installed versions looking for the highest framework version supported by the version of OpenEdge you're using.

  • That is helpful.  With the /xsd option I wasn't able to get anything working until I added the Windows SDK into my path.  Am I right that it is based primarily on the PATH environment variable?

  • The code for /xsd is more complex than /csc but I don't see anything which searches the path. It looks at a bunch of keys in the registry to find the path. I don't see why adding the Windows SDK to your path would have any effect on how /xsd works.

  • In the docs (such as they are) there is a bit about xsd as follows.  

    https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvoci%2Fadvanced-.net-options-dialog-box.html%23

    XSD Generator — This is the location of the xsd.exe tool, which is used in the generation of a strongly typed ADO.NET DataSet or DataTable. If Default csc is selected in the Compiler field, the XSD Generator field is read-only and displays the appropriate command.
    If Custom is selected in the Compiler field, you can modify the XSD Generator setting as appropriate. You must specify the full path or a path that is relative to the system path for the XSD executable.

    (While it says this about the "custom" option, I suspect it is true for the "default csc" option too since it wasn't finding xsd.exe anywhere in the system until I added it to the PATH environment variable)
  • I was just talking about what PathFinder.exe does. I had blinders on. The system path search probably happens in ProxyGen itself.

  • I was talking about pathfinder too.  The following is working now.  It wouldn't return anything until I added the path to my PATH environment.  

    proenv>pathfinder /xsd
    C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\

    I guess I will assume that pathfinder relies on the PATH for the xsd and uses the other magic you had described for the csc.  My machine has all the tooling for both PDSOE and VS2017.  I was surprised that proxygen made me change my PATH (given that I haven't had to manually change my PATH for any of the other development tools that I use).

    At this rate I think I just as soon use the "custom" option and tell proxygen exactly which csc and which xsd to use.  Setting the path in via my environment variables seems like a round-about way of accomplishing the goal.