preventing excessive probing when launching an exe via href

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

If i create a simple windows form .exe then launch it via a href, ( simple
one touch deployment ), why does
the .net framework/iis search in multiple places and for multiple files
derived from the actual .exe name. ( most of which don't exist )

eg;
2005-03-01 04:47:35 10.2.5.229 GET
/Components/Softix.Platform.Application.Startup.exe - 80 - 10.2.5.232 200 0 0
16621 314 15
2005-03-01 04:47:40 10.2.5.229 GET
/Components/Softix.Platform.Application.Startup.DLL - 80 - 10.2.5.232 404 0 2
1795 264 0
2005-03-01 04:47:40 10.2.5.229 GET
/Components/Softix.Platform.Application.Startup/Softix.Platform.Application.Startup.DLL - 80 - 10.2.5.232 404 0 3 1795 300 0
2005-03-01 04:47:40 10.2.5.229 GET
/Components/bin/Softix.Platform.Application.Startup.DLL - 80 - 10.2.5.232 404
0 3 1795 268 0
2005-03-01 04:47:40 10.2.5.229 GET
/Components/bin/Softix.Platform.Application.Startup/Softix.Platform.Application.Startup.DLL - 80 - 10.2.5.232 404 0 3 1795 304 0
2005-03-01 04:47:40 10.2.5.229 GET
/Components/Softix.Platform.Application.Startup.EXE - 80 - 10.2.5.232 200 0 0
16621 314 0
2005-03-01 04:47:40 10.2.5.229 GET
/Components/Softix.Platform.Application.Startup.exe - 80 - 10.2.5.232 304 0 0
184 314 171

Is there anyway to stop this behaviour ?
 
Hi,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to know how to stop .net from
looking for assembly from multiple directories. If there is any
misunderstanding, please feel free to let me know.

As far as I know, this is the default behavior of .net. It is doing so to
ensure that it can find the correct assembly under certain folder.

You can specify the looking up URL in <codeBase> element in the
configuration file. For more information, please check the following link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht
ml/gngrfCodeBase.asp

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Hi again Kevin,

Yes your understanding of my problem was correct.

I'd actually tried specifying the codebase in the .config file but had no
success with this approach, however, during my various attempts to solve this
problem i'd either missed or failed to register the pertinent line contained
in the page that you referenced in your reply, that being..."If the assembly
is a private assembly, the codebase setting *MUST* be a path relative to the
application's directory."

I'd only ever tried setting my codebase as a url
"http://whatever/myAssembly.dll", which only works if my assembly has a
strong name. ( i don't use strong names because i need to be able to patch
any number of referenced dll's individually, but thats another story. )

Anyway, now i specify the codebase correctly in my .config file the
excessive probing has gone away, and things look a lot cleaner.

My .config file now looks like this...

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Whatever.Platform.Application"
culture="neutral" />
<codeBase href="Whatever.Platform.Application.exe"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

I don't appear to need the publicKeyToken or version attributes. Can you
foresee any problems in not setting these ?

Thanks again for your help with this issue.
 
Hi,

If the assembly is not a strong named one, and we just use in the current
application, I don't think there will be problems.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I've done a fair bit of testing now during the day and all seems well just
specifying the codebase.

Thanks again for your help.
 
You're welcome.

Thanks for sharing your experience with all the people here. If you have
any questions, please feel free to post them in the community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top