Developing CLR bridge is troublesome - PDSOE locks assemblies - Forum - OpenEdge Development - Progress Community

Developing CLR bridge is troublesome - PDSOE locks assemblies

 Forum

Developing CLR bridge is troublesome - PDSOE locks assemblies

This question is answered

Is there a way to get PDSOE to unlock my assemblies to make changes?  I'm having to fully shut down and restart PDSOE?

I can't make changes to my .Net class library.  It appears that PDSOE won't release my assembly.  Even if I unload the entire project in PDSOE, the dll remains locked.

I found an old KB but I'm wondering if there is any other news:

https://knowledgebase.progress.com/articles/Article/ArchitectCannotUnloadDotNetAssemblies

Another thing I tried is to use the GAC instead, and change my assembly version numbers.  But unfortunately one of the dependencies isn't signed:  (c:\Progress\OpenEdge\bin\Progress.NetUI.dll) so I can't sign my assembly either.  Any pointers would be appreciated.

Verified Answer
All Replies
  • Different projects and different assembly versions at the same time with constant updates is a really horrible experience in PDSOE.

    There is this idea which would solve these problems.

    community.progress.com/.../the_net_bridge_in_pds_should_use_a_different_app_domains_for_seperate_projects

    ...but this is over 4 years old by now so i wouldn't hold my breath. Seems they do not really care about this.

  • I finally gave up on trying to use PDSOE and visual studio at the same time.  Basically I decided to set up VS to launch a new instance of _progres.exe (as a test harness).  I launch it over and over, every time I make a change to my class library.  

    As you point out, you really can't alternate back and forth to work on the code in PDSOE, unless you totally remove assembly reference from assemblies.xml (or comment it out).

    I suspect that the problem is only encountered by a very small subset of the OE customers (the ones who also use .Net on Windows).  It is probably not easy for Progress to prioritize this above other work that needs to be done (especially if the idea only gets 12 votes in 4 years).  With the purchase of Telerik, they should have more expertise to help accomplish some of these things in the .Net world.  (I'm also waiting on some changes to the .Net openclient).  But I suspect the Telerik guys are not yet very familiar with the OpenEdge side of the company.

  • Because of the way that the .NET framework is loaded, we cannot use different App Domains.  We can only use the default App Domain.  Unfortunately, this has caused a few other sporadic issues as well.  But changing this is a big deal!  So it is not really about us not caring :-0  And yes, of course, any work needs to be prioritized and balanced against other features that need to be done.