G
goo
Guest
Thanks, I really appreciate your input. I am not familiar with either of them. Are the tools easy to get / download? Sendt fra min iPad 20. des. 2019 kl. 15:03 skrev dbeavon : Update from Progress Community dbeavon Is this still in development or are you deploying to production? Your best friends in the Windows and .Net world are procmon and procexp (sysinternals tools). Procexp will allow you to see what assemblies are loaded into the memory of a given process (to verify any theories about what assemblies can be found vs the ones that cannot). Procmon will monitor file access as your process is launching, and it will tell you exactly where the app is trying to look for those dlls. Procmon is like "tusc" in unix and is used for for tracing system calls. But procmon is much, much more easy to use. Both of these should be run as administrator to ensure you aren't missing any information. I'd guess that your relative path might be a good place to start troubleshooting. Why don't you test with an absolute path and see if that works or not. Another thing to test is whether things would work any better if the assembly is added to the GAC. Another thing you should do is ensure that the version of .Net that the assembly relies on is installed on the deployment machine where you are running the application. Good luck with the CLR bridge. I've found it extremely helpful to supplement the API's that aren't available in ABL. The development experience in Eclipse was the thing that I found most annoying, since it would constantly lock the dll and force an endless amount of restarting, whenever I needed to make a change to it... View online You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here . Flag this post as spam/abuse.
Continue reading...
Continue reading...