It might be a display issue or just displaying what's in assemblies.xml. We are using some new .NET Framework features that come with later version of .NET Framework 4.0, and they seem to work OK.

Each Progress version is targeted to a certain .NET Framework version.  For example, version 11 is targeted to 4.6.  However, if only a later version is installed on the machine, that is what will get used.  If both 4.6 (for example) AND a later is installed, I can never remember whether it will use the targeted version or always the newest it can find.

P.S.  This is up to Microsoft, not us.  We only control the targeted version, not the version that is actually used at run-time.

Is the targeted version specified via a registry entry... ? Something else..?

In PDSOE, I have no assemblies file in my project. If I open the class browser and select the System node, it shows:

Assembly System

Location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.dll

Is that the same version that is being used if I use the Procedure Editor (outside of PDSOE)?

You can try the start up parameter to preload the CLR

documentation.progress.com/.../index.html

-Shelley

The assembly version # will probably not reflect which Framework version is being used.  This was explained on some  Microsoft website, but I can't find it right now. Each release of the 4.x .NET line may contain bug fixes or may contain new features.  Some assemblies may not change at all and their version # will NOT change just because the Framework version is different. Even if the assembly is updated, I don't know if the version # will necessarily change to start with the digits that match the Framework version (e.g., 4.6.xxxxx).  I think the rules for assembly versioning are independent of that.

I guess I should ask - why do you need to know?

"I guess I should ask - why do you need to know?"

I was experimenting with a System.Net class (based on a C# example) but cannot pass syntax check:

"Could not find class or interface . (12886)"

I do not see it in the class browser so the error makes sense but I was wondering why.

I believe you need to add it to your assemblies.xml.

Correct - add it to your assemblies.xml file.

I don't use this stuff much so please bear with me..

I am able to use other System.Net.* classes without an assemblies.xml file.

I was trying to experiment with HttpClient in the System.Net.Http namespace.

We have reference to System.Web in our assemblies.xml. Verify if the feature you are using is one of those that was moved from .Net to .Web namespace.

I'll try the ABL implementation. :)

But one doesn't always need an assemblies reference it seems.. for example, this passes syntax check just fine without an assemblies reference:

USING System.IO.*.
USING System.Net.*.

DEFINE VARIABLE req        AS  System.Net.WebRequest    NO-UNDO.
DEFINE VARIABLE resp       AS  System.Net.WebResponse   NO-UNDO.
DEFINE VARIABLE dataStream AS  System.IO.Stream         NO-UNDO.
DEFINE VARIABLE reader     AS  System.IO.StreamReader   NO-UNDO.
DEFINE VARIABLE json       AS  LONGCHAR                 NO-UNDO.

Interesting.  Something else must be causing it to be loaded.  

Before using the ABL implementation, you could try adding the one you need to your assemblies.xml file to see that it does fix it.  Aren't you curious now?  :-)

Yes, adding to my assemblies.xml works.

For my other example, I just opened a fresh copy of the Procedure Editor (stand-alone) and it seemed to compile.