Click here to Skip to main content
15,943,477 members

Comments by Kosta Cherry (Top 12 by date)

Kosta Cherry 18-May-16 12:40pm View    
Ok, there is not config file in the app, so no help here.
"when A.DLL don't require other assemblies, does .\Bin\Ext\A.DLL works" - yes, it does.

"Now, let's assume that .\Bin\B\B.dll and .\Bin\B.dll both work. What's wrong with it?" - nothing, except the this I'm doing is a proof of a concept; it willbe many more dependencies and interdependencies, so client does not want to pollute .\Bin, and does not want to create additional folders for each referenced assembly (it is estimated it'll be over 100 of them).

When I say "works", it means "B.DLL" gets loaded by A.DLL when needed.
Anyway, I just found a solution and will post it right now.
Kosta Cherry 18-May-16 11:54am View    
No, application explicitly required user extensions to be in AppName\Bin\Ext, not AppName\Bin. Basically, I cannot place A.DLL into AppName\Bin - it will not let me "register" it. Yeah, this is 3rd party, you know...

For the 3 items "works-works-doesn't work" I mentioned, A.DLL always resides in AppName\Bin\Ext. It just cannot reside anywhere else.

Of course, I can add folder AppName\Bin\B, add there B.DLL and be doe with it, or place B.DLL into AppName\Bin, but end client does not approve this. They want A.dll and B.dll reside side by side in App\Bin\Ext, and I've no idea why search is not done there.

I just tried SetDllDirectory, as mentioned above - did not help at all. Pulling my hair now :(
Kosta Cherry 28-Mar-15 0:48am View    
I doubt that they will ever pay attention to the request of a stranger...
Kosta Cherry 12-Jan-15 23:42pm View    
Reason for my vote of 2 \n Test code is irrelevant to the target of the article
Kosta Cherry 7-Nov-13 13:18pm View    
Yes, really. From your own answer: "The assembler generated was just about identical". And this is exacly the case I pointed out (see my original reply): "as in such case they are implemented as bit shifts or bit maskings". Division is optimised in one, and only one case: "if the second operand is a constant power of two". If you take a habit of mindlessly using division, you are bound to a case when second operand is NOT a power of two, and performance drains down. It's not a premature optimisation, it's a habit of writing code that is optimised from the beginning, instead of brute force approach and hope that compiler writers foresaw your case. The best solution here (performance wise) was a union trick. Premature optimisation? Nope, just a good code to begin with, and experienced programmer who "been there, done that".