Differences between <codeBase> and <probing>?

  • Thread starter Thread starter learner
  • Start date Start date
L

learner

Can someone explain the differences between <codeBase> and <probing>, or
point me to some Web pages that explain these in an easy to understand
manner? Thanks.
 
Can someone explain the differences between <codeBase> and <probing>, or
point me to some Web pages that explain these in an easy to understand
manner?
Click to expand...

<probing> lets you specify subdirectories of the application base
directory that should be searched for assemblies.

<codeBase> lets you specify the absolute location of an assembly. It
doesn't have to be below the app directory, and it doesn't even have
to be a file system location.

There's more to it, that you can read about in Suzanne Cook's blog at
http://blogs.gotdotnet.com/suzcook/



Mattias
 
Thanks Mattias.

So <probing> can only specify subdirectories, right?

Can I have <codeBase> without supplying the "version" attribute?

If I have a Windows Form application that uses a strong-named assembly that
is not located in the GAC or in a subdirectory, and the Windows Form app is
not required to use a specific version of the assembly, where should I
specific the exact location of the assembly? In <codeBase> or <probing>? I
picked a similar question from a study material, and they gave the answer as
<probing>. I think the answer should be <codeBase>, isn't it? Furthermore,
<codeBase> is searched before <probing>, right?

Thanks a lot.
 
Hi

The key to your question lies in the mechanism that the
runtime uses to locate an asembly at runtime.

Probing is a mechanism that the runtime uses to locate a
referenced assembly and load it in certain specified
locations. These locations are limited to the bin
directory + the sub-directories of bin directory mentioned
in the <probing privatepath> element in the config file.
The pts a,b below are related to probing

When a assembly is to be loaded

a) App Base : By default the runtime looks at the appbase
directory to load the dll. Such assemblies are called
Private Assemblies as each application can have their own
copy of the assembly. Use this feature if you want the
assembly to be maintained in the bin directory of ur
application. This is by default and the probing mechanism
of the runtime will check for the assembly in this
location with a few combinations(bin, bin +
culture, .exe, .dll etc... Look up Probing in MSDN)

b) Private Path : You may want to customise this a
little, where you might want the Assembly not in the bin
dir but in one of the sub-dirs of bin. you can create
such a sub-dir of bin and mention the name of the sub-
folder in the <probing privatepath> element of the config
file. This will make the runtime check those sub-folders
also to load the assembly

The following are used when the referenced assembly is
neither in the bin nor in one of its sub-folders

c) Global assembly cache(GAC) - Any assembly that is
shared by multiple applications can be placed on the GAC
so that they can be accessed by these client
applications. Assembly is made unique by the identity of
the assembly which is AssemblyName+Version+Public key

d) CodeBase : It is possible that you want multiple
applications to share an assembly, but it is not common
ebnough to be placed in the GAC. Or it might be possible
that it ios on a remote location like a http Server. In
such cases you can place such assemblies in a File/Http
Server and make the runtime look up this location by
specifying the codebase element. One condition is that
such codebase element referenced assemblies should be
strong-named. So the runtime will look up code-base
referred locations also during the binding process.
Use this when you want a assembly which is shared(shared
in the literal sense,and not to be confused with the
technical term "Shared Assemblies", which is used to refer
to Assemblies placed in GAC) by multiple apps but not to
be placed in the GAC.

So these are the various options available to you
regards,

sr
Message-----
 
Back
Top