I don't believe there's a way to tell .NET not to resolve particular dependencies.
One approach: (A) Move all your code that accesses the 3rd-party code into its own assembly (call it the 3pa). (B) Define the interface to that code in another assembly (call it the IA) that's referenced by both your main assembly and the 3pa. (C) If you determine that the 3rd-party code is present, use Reflection to load the 3pa and call a factory-esque method that returns an object that implements the interface defined in the IA and assign it to a variable of the interface type. By using the IA, you'll get compile-time checking of the code you write against the interface returned from the 3pa; and you only need to call one method (the one that returns the interface) via Reflection. In other environments, you could build two version your DLL-interface assembly and deploy a "stub" version if the 3rd-party DLL isn't there -- but I don't think you can make that work in .NET (particularly if you want to strong-name your assemblies). At 04:42 AM 4/30/2004, Steve W wrote >We have a web application that calls a bunch of VB.NET objects. > >We have intgerated with a 3rd party's software which includes one of our >objects referencing one of their dlls. > >When we build our app we get a copy of all required dlls in the bin >directory of the web app. On a system where the users do not have the 3rd >party app I would like to be able to remove the 3rd party dll. If I do >that then I get an error message about it (or a dependency) not being >accessible. > >Is there any way to tell .Net not to resolve dependencies of specific >components ? > >Thanks > >Steve J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
