|
|
Rank: Advanced Member
Groups: Member
Joined: 10/4/2016
Posts: 104
|
Hi,
Sorry if my question is a dup. I understand they are a number of restrictions and approaches when it comes to deploy .Net DLLs in a different folder than the one where the executable is being installed.
I was wondering if you would have any suggestion or recommendation to actually deal with this aspect when it come to the EO DLLs?
Ideally I would like to deploy those DLLs in a folder (e.g. C:\Program Files\EOWeb\...) then have my packages that deploy applications which all depends on the EO DLLs (C:\Pogram Files\App1; C:\Pogram Files\App2; ... C:\Pogram Files\AppXYZ)
The idea being that I could just deploy a small foot print package for each application (provided the EO Web package has been installed), and whenever new EO DLLs are available (of course after regression testing on all dependent applications), they could be deploy to the workstation and every dependent applications would benefit from the EO update(s).
Similarly I could have my application owners just dealing with their specificities and deploying their customized components as long as they can reference the EO Web DLL located in a different folder.
Thank you very much for your insight.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
Hi,
This is a general .NET deployment issue. The location should not be an issue for our DLL as long as you have all of our DLLs in one place. The bigger issue is the DLL version.
When your application is compiled with DLL version 1.1.1.1, you can't just later replace the 1.1.1.1 DLL with 1.1.1.2 DLL. Your application would still be looking for version 1 and it will complain that it can't find it even if version 2 is right in front of it. There are a number of possible solution to this issue, one is instead of compile to our DLL directly, you can use reflection to load our DLL dynamically. This will introduce significant amount of extra code and lose compile time type checking. Another solution is to use version redirection through application config file. Even with version redirection, you would still need to dynamically set DLL loading location since it is not the default location anymore. Neither is specifically related to our product so you can search online for more details.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/4/2016
Posts: 104
|
Thank you for your reply. I did not think about the version constraint but I understand where it is coming from. And based on your inputs plus the general feeling in regards to .Net DLL dependencies, we will just give up on trying to deal with a common package and its dependent ones.
Thank you again for your quick turn around on this one.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
You are welcome. Please feel free to let us know if there is anything else.
|
|