What are the steps for distributing assemblies?

Posted by goo on 20-Dec-2019 11:38

11.7

I am going to use a ChilkatDogNet48.dll on a windows 2012R2 server. I get the following error

.

How should I debug it?

All Replies

Posted by goo on 20-Dec-2019 11:43

prowin32.exe ...... -assemblies .\assemblies

where assemlies/assemblies.xml

contains <?xml version="1.0" encoding="UTF-8"?>

<references>

<assembly name="Microsoft.IdentityModel.Clients.ActiveDirectory, Version=2.29.0.1078, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<assembly name="Microsoft.WindowsAPICodePack, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<assembly name="Microsoft.WindowsAPICodePack.Shell, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<assembly name="ChilkatDotNet48, Version=9.5.0.80, Culture=neutral, PublicKeyToken=eb5fc1fc52ef09bd"/>

</references>

Posted by dbeavon on 20-Dec-2019 14:02

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...

Posted by goo on 20-Dec-2019 15:06

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 <bounce-dbeavon@community.progress.com>:


<ProgressEmailLogo-png_2D00_150x42x2-png>
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.

Posted by dbeavon on 20-Dec-2019 16:28

Yes, just google for them.  They are free.   There are lots of great sysinternals utilities.  Basically if you can imagine some tool that would be used for troubleshooting something in windows (monitoring files, processes, CPU, memory) then it probably already exists within the sysinternals toolset.   All of them are fairly intuitive and easy to use.

Posted by goo on 20-Dec-2019 18:16

Sorry, deploying for production....

Sendt fra min iPad

20. des. 2019 kl. 15:03 skrev dbeavon <bounce-dbeavon@community.progress.com>:


<ProgressEmailLogo-png_2D00_150x42x2-png>
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.

Posted by tbergman on 20-Dec-2019 19:50

In general, you can either put the DLL's into the same folder as your assemblies.xml file or in the global assemblies cache (GAC).

In this particular case, the common causes for the problem you're experiencing are.

1) A downloaded dll that has the windows "blocked" flag set. Right click on the file, choose properties, and see if there's an unblock choice.

2) Specifically for the Chilkat dll, you need to use the one with the proper "bitness". Since you're running prowin32.exe, you need the 32 bit version.

Posted by goo on 20-Dec-2019 22:36

Aaah, thanks .. that could be it. I have been using 64bit when developing. I will check that. Or check to install 64bit

Sendt fra min iPad

20. des. 2019 kl. 20:52 skrev tbergman <bounce-tbergman@community.progress.com>:


<ProgressEmailLogo-png_2D00_150x42x2-png>
Update from Progress Community
tbergman

In general, you can either put the DLL's into the same folder as your assemblies.xml file or in the global assemblies cache (GAC).

In this particular case, the common causes for the problem you're experiencing are.

1) A downloaded dll that has the windows "blocked" flag set. Right click on the file, choose properties, and see if there's an unblock choice.

2) Specifically for the Chilkat dll, you need to use the one with the proper "bitness". Since you're running prowin32.exe, you need the 32 bit version.

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.

Posted by jquerijero on 20-Dec-2019 23:38

Not exactly answering your question, but I just want to share something I've learned from my last support case about assemblies. The DLL reference in deployed assemblies.xml is not needed when deploying DLL as long as the r-code was compiled using an assemblies.xml with the original DLL reference. This makes your application sort of true load-on-demand. This means your deployed assemblies.xml can only contain references to those DLL that must be loaded early. The rest will be loaded when needed. You can even forgo deploying assemblies.xml. The startup parameter -assemblies is enough for non-GACed DLLs.

When loading DLL Progress run-time checks the following location

1. Global Assembly Cache (GAC)

2. %DLC%\bin

3. %DLC%\bin\Infragistics\winforms

4. %DLC%\bin\dotnetmsgs

5. Location specified by -assemblies (handled by the Progress AVM itself).

Posted by goo on 21-Dec-2019 07:12

Thanks, this is really great info.!

Sendt fra min iPad

21. des. 2019 kl. 00:39 skrev jquerijero <bounce-jquerijero@community.progress.com>:


<ProgressEmailLogo-png_2D00_150x42x2-png>
Update from Progress Community
<4TUD03IBCS1S-jpg_2D00_70x70x2-jpg>
jquerijero

Not exactly answering your question, but I just want to share something I've learned from my last support case about assemblies. The DLL reference in deployed assemblies.xml is not needed when deploying DLL as long as the r-code was compiled using an assemblies.xml with the original DLL reference. This makes your application sort of true load-on-demand. This means your deployed assemblies.xml can only contain references to those DLL that must be loaded early. The rest will be loaded when needed. You can even forgo deploying assemblies.xml. The startup parameter -assemblies is enough for non-GACed DLLs.

When loading DLL Progress run-time checks the following location

1. Global Assembly Cache (GAC)

2. %DLC%\bin

3. %DLC%\bin\Infragistics\winforms

4. %DLC%\bin\dotnetmsgs

5. Location specified by -assemblies (handled by the Progress AVM itself).

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.

Posted by goo on 21-Dec-2019 09:26

Not easy at all, thats for sure, but I got it to work [:D]

Nice to know stuff:

https://knowledgebase.progress.com/articles/Article/How-does-the-Progress-client-handle-NET-assembly-loading

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

At the end it is VERY important to have controll of your paths when deploying. 

Anyway, thanks! and have a merry christmas 

Posted by dbeavon on 23-Dec-2019 14:16

So what ended up being the precise problem?  How is it that you didn't have "control of your paths".  Did someone have security in place that that prevented you from deploying to those paths?  Or maybe there was a conflicting dll already in place?  Did the procmon output help to identify the problem?

Posted by goo on 24-Dec-2019 07:28

It was to steps that was the problem, first I had added the x64 version instead of x32 (developing x64, but it seems like the customer has installed a x32 bit version on the production server). Then it was the issue regarding workpath for the startup on the server. It was set to d:\progress\oneSite and my workarea was d:\progress\oneSite\thisSite. I did not see that first, so by referring -assemblies assemblies instead of -assemblies thisSite/assemblies, I was pointing to another assemblies area. I found that while I was looking into processMonitor and processExplorer. And of course it is nice to know what directories where a .dll is searched for.
 
Now the dll is working, and I am very pleased to use Chilkat as a tool for doing stuff that is not that easy to do in the openedge language, very cool. Thanks for your help!
 
//Geir Otto
 

This thread is closed