<probing> element in Web.config

[Jiho Han]

This has been asked many times before but it seems there haven't been clear
answers.

I have an application root at

http://localhost

and subdirectories

http://localhost/app1

which is not a virtual directory. So normally all assemblies will be
searched for in http://localhost/bin directory. I want to change this so
that for app1, the runtime searches in http://localhost/app1/bin and for
app2, in http://localhost/app2/bin, etc...

I've set up <probing> element in my web.config and found some issues and was
wondering whether some of these are bugs, *features*, etc.

1. <probing> element specified in web.config under app1 folder seems to have
no effect. Thus <probing> element must be specified once in the app root's
web.config for all app1..N.

2. Regardless of the existence of <probing> element, the assembly that
contains your Page derived class(your typical presentation layer) must still
be located in app root's bin folder. All other business, DAL, utilities can
be located in app1/bin folder.

3. Q: Can <codeBase> be utilized in my situation? Note that these are all
private assemblies.

Thanks for any information you can provide. Please feel free to share your
experiences with <probing> and general assembly location issues.
Jiho Han

[bruce barker]

1) there is only 1 web.config per asp.net application. because your /app1
and /app2 are not vdirs (asp.net applications) they use the base web.config

2) asp.net doesn't actually use the bin directory, it shadow copies it to
another directory (tempDirectory=) that it creates to run the application.

3) to compile a page, asp.net needs a reference to the base page dll, to
pass to the compiler. probe is only used by assembly loader, not the
compiler. try adding path references to the <compiler> section of your web
config (you will need to add the <compilation> section).
-- bruce (sqlwork.com)
"Jiho Han" <ji******@infinityinfo.com> wrote in message
news:O8**************@tk2msftngp13.phx.gbl...

This has been asked many times before but it seems there haven't been clear answers.

I have an application root at

http://localhost

and subdirectories

http://localhost/app1

which is not a virtual directory. So normally all assemblies will be
searched for in http://localhost/bin directory. I want to change this so
that for app1, the runtime searches in http://localhost/app1/bin and for
app2, in http://localhost/app2/bin, etc...

I've set up <probing> element in my web.config and found some issues and was wondering whether some of these are bugs, *features*, etc.

1. <probing> element specified in web.config under app1 folder seems to have no effect. Thus <probing> element must be specified once in the app root's web.config for all app1..N.

2. Regardless of the existence of <probing> element, the assembly that
contains your Page derived class(your typical presentation layer) must still be located in app root's bin folder. All other business, DAL, utilities can be located in app1/bin folder.

3. Q: Can <codeBase> be utilized in my situation? Note that these are all
private assemblies.

Thanks for any information you can provide. Please feel free to share your experiences with <probing> and general assembly location issues.
Jiho Han

[Jiho Han]

A couple of notes...

1) This is not true. There is one *root* web.config per vdir. However,
each subdirs underneath the vdirs can have web.config as well with some
limitations.

2) I know this but do only the page page dlls get copied over to the temp
folder or do all referenced assemblies?

3) Unfortunately, <compiler> section doesn't seem like it would help.
<assemblies> section seemed like it would but depending on what the
following statement from the doc means:

"You can optionally specify the wildcard character * (an asterisk) to add
every assembly within an application's private assembly cache" and the doc
states to refer to Assembly.Load, which may indicate assembly loader at
work. However, it still only insists on searching inside approot/bin folder
only.

"bruce barker" <no***********@safeco.com> wrote in message
news:Ov**************@TK2MSFTNGP11.phx.gbl...

1) there is only 1 web.config per asp.net application. because your /app1
and /app2 are not vdirs (asp.net applications) they use the base web.config
2) asp.net doesn't actually use the bin directory, it shadow copies it to
another directory (tempDirectory=) that it creates to run the application.

3) to compile a page, asp.net needs a reference to the base page dll, to
pass to the compiler. probe is only used by assembly loader, not the
compiler. try adding path references to the <compiler> section of your web
config (you will need to add the <compilation> section).
-- bruce (sqlwork.com)
"Jiho Han" <ji******@infinityinfo.com> wrote in message
news:O8**************@tk2msftngp13.phx.gbl...

This has been asked many times before but it seems there haven't been

clear

answers.

I have an application root at

http://localhost

and subdirectories

http://localhost/app1

which is not a virtual directory. So normally all assemblies will be
searched for in http://localhost/bin directory. I want to change this so that for app1, the runtime searches in http://localhost/app1/bin and for
app2, in http://localhost/app2/bin, etc...

I've set up <probing> element in my web.config and found some issues and

was

wondering whether some of these are bugs, *features*, etc.

1. <probing> element specified in web.config under app1 folder seems to

have

no effect. Thus <probing> element must be specified once in the app

root's

web.config for all app1..N.

2. Regardless of the existence of <probing> element, the assembly that
contains your Page derived class(your typical presentation layer) must

still

be located in app root's bin folder. All other business, DAL, utilities

can

be located in app1/bin folder.

3. Q: Can <codeBase> be utilized in my situation? Note that these are all private assemblies.

Thanks for any information you can provide. Please feel free to share

your

experiences with <probing> and general assembly location issues.
Jiho Han