Here is what I have found:
1. do not initialize a class to null as it will cause jit compiling of the class:
Example:
internal classX property1 = null; //forces jit
internal classX property1; //does not forces jit
2. Isolate class member usage that you don't want jit compiled into seperate methods.
Example:
//this method will jit compile the class
internal void ClassXsomemethod()
{
if(property1 == null)
property1 = new classX();
property1.somemethod(); // invoking this method will jit
}
structure your code like this
internal bool usingClassX=false
internal void SomeMethod()
{
//until you set usingClassX to true, and call ClassXsomemethod it will not be
jit compiled.
//this way, unless you want to use ClassX by setting usingClassX to true it
will never be jit compiled
if(usingClassX)
ClassXsomemethod();
}
I hope this helps you, it was a real pain to code this way but it is the only way I
have found.
>> Assemblies are loaded on demand (eg. when the first method to reference it
>> is JIT compiled). So another option is to isolate all code that uses the
>> 3rd party assembly into specific methods, and avoid calling those methods
>> when you know the assembly isn't available. I'm not claiming this is
>> necessarily a great idea , depending on your situation some of the other
>> suggestions (eg. using reflection) might be a better idea. Relying on the
>> lazy-load is a little brittle, you'll will want to disable Inlining of
>> those
>> methods, never call AppDomain.GetAssemblies, and even then I'm not sure
>> the
>> behaviour is guaranteed - might change in future versions of the runtime.
>> But its probably less of a hassle than relying on reflection to bind
>> dynamically to the assembly.
>> Rick
>> ----- Original Message -----
>> From: "J. Merrill" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Monday, May 03, 2004 12:40 PM
>> Subject: Re: Stopping .Net Resolving Dependencies
>> > 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
>> >
>> ===================================
>> 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
===================================
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
