Or how about fixing the actual problem, BETTER ERROR MESSAGES.

The problem isn't always a poor error message, Mr. "Vackoff". Sometimes you need to see the probing paths to figure out how the assembly is being located. Load, LoadFrom, and LoadFile all use slightly different hueristics for loading assemblies. Many customers also will place extra probing paths in thier .exe.config file. Reflection has no idea where an assembly is SUPPOSED to come from -- only that it did not resolve it appropriately. When looking at the logs and seeing the probe paths and results per path, the problem is much easier to identify.

"Customers" have no freakin' idea what an .exe.config file is, nor do they know about XML or anything. To be honest, even developers are having a hard time understanding this GAC/Fusion versioning nightmare. "Customers" get stupid error messages like "mscoree.dll not found", never look at you app again and blame it all on the app developer.

No no they blame Windows!!!

Alot of customers dont even know what a Control Panel is nevermind a log file (especially one that is burried deep in teh system and crptic) or worse, the event log.

To Quote Alien the movie

"Did IQs just drop when I was away".

"mscoree.dll not found" sounds like the .Net framework was not installed on thier system. If you have a repro or a specific instance of this problem with enough detail, I can try to get it resolved for you.

"Customers" in this context means app developers -- not the consumers of the app. But I agree with both of you -- there are both a lot of app developers and consumers who do not know what an .exe.config is -- and the end user (as opposed to the app develepor) getting these cryptic error messages is terrible.

My suggestion was solely geared towards devs who are testing thier app and encountered an error. Should error messages be explicit? Yes. Can an error message give you as much as a trace log? No. That is why the fusion log is so useful -- you can parse through the (sometimes) complex logic fusion is using.

In todays climate, I wouldnt trust a dev to know what a config file is either. :D

I'm trying to create a WebService that uses a managed DLL that in turn uses unmanaged C++ DLLs.
I can't get the unmanaged DLLs to be copied in the assembly cache. I've tried everything... except the right thing, of course. I'm lost. Any help ?
Thanks

Are the unmanaged dll's COM objects? You should be able to either register the native dll and use managed interop wrappers or place the native dll in the system path (if its not a COM object) to allow the webservice to find it. I'm no expert in the web space, but have you tried this?

No, they are not COM objects. Plain old C++ DLLs.
I can put them in the System32 directory, and it works, but it is Wrong, I guess.

As for "registering the native DLL and use managed interop wrappers"... well I guess that I'll have to google to know what it means :-/

Thanks
-- JM

PingBack from http://feeds.maxblog.eu/item_584336.html