Shadow copying .NET assemblies for prowin.exe|prowin32.exe a

Posted by Mike Fechner on 11-Feb-2015 02:27

Hi,

I am currently working on a project where we are developing parts of an application as custom .NET assemblies in Visual Studio. It get's hardly annoying that we have to stop PDSOE completely in order to be able to replace a .NET Assembly with a new version - as we may have to do that every couple of minutes. I'd rather just have to "restart project AVM" on those projects that rely on the updated assembly.

Is there a chance to use the .NET Assembly Shadow Copying with PDSOE and the Progress runtime processes?

https://msdn.microsoft.com/en-us/library/ms404279(v=vs.100).aspx

My understanding is, that both the java portion of the PDSOE tools as well as the prowin.exe|prowin32.exe hold a file lock on any referenced Assembly and thus preventing us to replace it with a newer version. So we'd have to update enable the Shadow Copying for the prowin processes and probably javaw.exe.

I tried to run this code here:

USING System.* FROM ASSEMBLY.

MESSAGE "shadow?" AppDomain:CurrentDomain:ShadowCopyFiles
VIEW-AS ALERT-BOX.

And it shows "no".

Is there a way to change this? I tried various settings in prowin32.exe.config - but with no luck so far.

All Replies

Posted by cverbiest on 11-Feb-2015 07:08

Even when not actually developing in Visual Studio changing assemblies is very hard.

Our assemblies are checked-in into version control, when we check-out a new version from within PDSOE that check-out fails because of the locks.

Posted by Roger Blanchard on 11-Feb-2015 07:12

We have the same issue so we exclude the assemblies from SCM and have to manually update them.

Posted by Mike Fechner on 11-Feb-2015 07:13

But that's a PITA - right? For the occasional Assembly update from SCM I can live with using the external SCM client.  

But that still does not help with custom Assembly development.

Posted by Roger Blanchard on 11-Feb-2015 07:15

Yes it is!!

Posted by Garry Hall on 11-Feb-2015 08:09

It might not be possible to enable ShadowCopyFiles for the AVM's .NET AppDomain. This is due to the way the AppDomain is created. The AVM does not configure a new AppDomain, it uses the default AppDomain, which we get from .NET. Consequently, unfortunately, you can't configure much of it. I don't think there is much in the prowin32.exe.config file that can help, but if you do find  something, please let us know.

Posted by danielb on 06-Jul-2016 23:20

Ping. I don't suppose anyone has found a solution for this?

Posted by sublam on 07-Jul-2016 02:44

The devstudio should use different AppDomains per Project anyway -> see community.progress.com/.../the_net_bridge_in_pds_should_use_a_different_app_domains_for_seperate_projects

This thread is closed