Resolved ClosedXML .net library | Can't view class object in Progress Developer Studio

JamesBowen

JamesBowen

19+ years progress programming and still learning.
I'm looking at replacing the COM Automation of using MS Excel and using the ClosedXML. .net library.

It looks like is going to do everything I need but I just can seem to get to all the listed namespaces, properties and methods in the class browser.

Is the some sort of hidden trick when using the Progress Developer Studio when viewing .net libraries?

ref:
github.com

GitHub - ClosedXML/ClosedXML: ClosedXML is a .NET library for reading, manipulating and writing Excel 2007+ (.xlsx, .xlsm) files. It aims to provide an intuitive and user-friendly interface to dealing with the underlying OpenXML API.

ClosedXML is a .NET library for reading, manipulating and writing Excel 2007+ (.xlsx, .xlsm) files. It aims to provide an intuitive and user-friendly interface to dealing with the underlying OpenXM...
github.com github.com
www.nuget.org

ClosedXML 0.105.0

See release notes https://github.com/ClosedXML/ClosedXML/releases/tag/0.105.0 ClosedXML is a .NET library for reading, manipulating and writing Excel 2007+ (.xlsx, .xlsm) files. It aims to provide an intuitive and user-friendly interface to dealing with the underlying OpenXML API.
www.nuget.org www.nuget.org
 
Just tried to test this and I am finding the exact same in that class browser is not listing anything.

I wondered if this was one of a few .NET components that Progress cannot access but it appears to not be the case:

Progress Customer Community

community.progress.com community.progress.com

I cannot explain why the namespaces, properties and methods are not being seen by class browser or the ABL.
 
Where do I place the start up parameter for -clrnetcore? is this a global startup parameter for Developer Studio, or for the project instance?
 
I have never used this parameter so not sure but based on this it looks to be a standard start-up parameter:

Progress Documentation

docs.progress.com docs.progress.com

As per the attached try setting for the relevant project.
 

Attachments

  • PDSOESTartupParameter.png
    PDSOESTartupParameter.png
    37.2 KB · Views: 7
Stupid question, but do I need to reference all the dependent .net assembly .dlls in the assemblies.xml?

I've noticed that if you install a package using nuget option, it will also install all the dependent .dlls as-well.
 
The majority of the time you just require the .NET DLL to be added to assemblies.xml and nothing else.

The only times I have experienced problems is if one of the following situations existed:
  1. The DLL was blocked so had to unblock.
  2. Access was required to another DLL and that DLL was missing. The DLL did not have to be added to assemblies.xml but had to be in the same folder as the main DLL. This is the situation you have noticed with the NuGet option as these would be the dependent DLL's that require access to but are not required to be in assemblies.xml.
However, if there are multiple DLL's then you could try adding them all to assemblies.xml - or at least ensure they exist in the same folder - to see if that solves.
 
Solution was to add -clrnetcore to the startup.pf file and to make sure the .NET v6/8 runtime was installed.
 
JamesBowen said:
Solution was to add -clrnetcore to the startup.pf file and to make sure the .NET v6/8 runtime was installed.
Click to expand...

I'm redacting this statement. Don't do this. It's broken my Progress Developer Studio setup.

I can no longer load or create any .NET Visual Designs Forms.

1752025820316.png
I can no longer undo my changes to revert back to using .NET Framework 4.8
1752026046797.png
 
Bit of a long shot but if you check either of these files what do they say?:

C:\progress\openedge12\oeide\eclipse\configuration\org.eclipse.osgi\bundles\336\1\.cp\Progress.clrbridge.netcore.runtimeconfig.json
C:\progress\openedge12\bin\Progress.clrbridge.netcore.runtimeconfig.json

If the values are not set as 6 then hopefully changing to 6 will solve:

Code: 
{
  "runtimeOptions": {
    "tfm": "net6.0",
    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "6.0.0"
      },
      {
        "name": "Microsoft.WindowsDesktop.App",
        "version": "6.0.0"
      }
    ],
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}
 
Osborne said:
Bit of a long shot but if you check either of these files what do they say?:

C:\progress\openedge12\oeide\eclipse\configuration\org.eclipse.osgi\bundles\336\1\.cp\Progress.clrbridge.netcore.runtimeconfig.json
C:\progress\openedge12\bin\Progress.clrbridge.netcore.runtimeconfig.json

If the values are not set as 6 then hopefully changing to 6 will solve:

Code: 
{
  "runtimeOptions": {
    "tfm": "net6.0",
    "frameworks": [
      {
        "name": "Microsoft.NETCore.App",
        "version": "6.0.0"
      },
      {
        "name": "Microsoft.WindowsDesktop.App",
        "version": "6.0.0"
      }
    ],
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}
Click to expand...

The value in the runtimeconfig file must match a .NET version that's installed. If you specify 6 when only 8 is installed, bad things happen.
 
You must log in or register to reply here.
Back
Top