Connecting to strong-named DLL outside of appbase

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Hi again,

I'm working on an app that will be using an assembly that will be
sitting on the network. I thought once I got the public key from the
assembly I'd have it figured out, but alas, I don't. Any help would be
appreciated. (And sorry in advance for a long message)

Here's my setup:

The application (DBAuthTest.exe) is sitting in a directory, the DLL
(DBAuth.dll) is in another directory (not a subdirectory of where
DBAuthTest.exe is).

In the directory with DBAuthTest.exe, I have DBAuthTest.exe.config,
which contains:

-------------snip---------------
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DBAuth"
publicKeyToken="c7d47cb0d27711c5"
culture="neutral" />
<codeBase version="1.1.1.1"
href="file:///c:/dllpath/DBAuth.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
--------------snip-------------


When I execute DBAuthTest.exe, I get an uncaught exception, here's the
results from that window:


-------------begin----------------
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.FileNotFoundException: Could not load file or assembly
'DBAuth, Version=1.1.1.1, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. The system cannot find the file specified.
File name: 'DBAuth, Version=1.1.1.1, Culture=neutral,
PublicKeyToken=null'
at DBAuthTest.Form1.Form1_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean
fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at
System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
msg, IntPtr wparam, IntPtr lparam)

Assembly manager loaded from:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Documents and
Settings\me\Desktop\dbauthtest\DBAuthTest.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = myshop.COM\me
LOG: DisplayName = DBAuth, Version=1.1.1.1, Culture=neutral,
PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/me/Desktop/dbauthtest/
LOG: Initial PrivatePath = NULL
Calling assembly : DBAuthTest, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Documents and
Settings\me\Desktop\dbauthtest\DBAuthTest.exe.config
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private,
custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Documents and
Settings/me/Desktop/dbauthtest/DBAuth.DLL.
LOG: Attempting download of new URL file:///C:/Documents and
Settings/me/Desktop/dbauthtest/DBAuth/DBAuth.DLL.
LOG: Attempting download of new URL file:///C:/Documents and
Settings/me/Desktop/dbauthtest/DBAuth.EXE.
LOG: Attempting download of new URL file:///C:/Documents and
Settings/me/Desktop/dbauthtest/DBAuth/DBAuth.EXE.



************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
DBAuthTest
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:
file:///C:/Documents%20and%20Settings/me/Desktop/dbauthtest/DBAuthTest.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

-------------end----------------


Funny thing is, when I remove the publickeytoken item from the config
file, it looks like it actually finds the DLL file, just chokes on the
public key not being right. Here's the difference in the error message
from when that happens.

-------------begin----------------

=== Pre-bind state information ===
LOG: User = myshop.COM\me
LOG: DisplayName = DBAuth, Version=1.1.1.1, Culture=neutral,
PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/me/Desktop/dbauthtest/
LOG: Initial PrivatePath = NULL
Calling assembly : DBAuthTest, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Documents and
Settings\me\Desktop\dbauthtest\DBAuthTest.exe.config
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private,
custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///c:/dllpath/DBAuth.dll.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY
TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing
terminated.

-------------end----------------


It's odd that it attempts to download the dll when there's no public
key specified in the config file, but seems to ignore the config file
(or the dll) when the public key token is specified.

Any help or point in the right direction would be, again, greatly
appreciated.

Thanks,
Mike
 
Mike said:
The application (DBAuthTest.exe) is sitting in a directory,

This is on your machine, right?
the DLL
(DBAuth.dll) is in another directory (not a subdirectory of where
DBAuthTest.exe is).

OK, risky, but it is possible.
In the directory with DBAuthTest.exe, I have DBAuthTest.exe.config,
which contains:

-------------snip---------------
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DBAuth"
publicKeyToken="c7d47cb0d27711c5"
culture="neutral" />
<codeBase version="1.1.1.1"
href="file:///c:/dllpath/DBAuth.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
--------------snip-------------


When I execute DBAuthTest.exe, I get an uncaught exception, here's the
results from that window:


-------------begin----------------
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.FileNotFoundException: Could not load file or assembly
'DBAuth, Version=1.1.1.1, Culture=neutral, PublicKeyToken=null' or one
of its dependencies. The system cannot find the file specified.
File name: 'DBAuth, Version=1.1.1.1, Culture=neutral,
PublicKeyToken=null'

Oops! This is a different file, the name of the file you mention in the
config file is

DBAuth, Version=1.1.1.1, Culture=neutral,
PublicKeyToken=c7d47cb0d27711c5

1) has DBAuth been signed?
2) have you compiled DBAuthTest against the signed DBAuth?
Funny thing is, when I remove the publickeytoken item from the config
file, it looks like it actually finds the DLL file, just chokes on the
public key not being right. Here's the difference in the error
message from when that happens.

The file *must* be signed if you want it to be in a folder that is not
under the app folder.
LOG: Attempting download of new URL file:///c:/dllpath/DBAuth.dll.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY
TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing
terminated.

It's odd that it attempts to download the dll when there's no public
key specified in the config file, but seems to ignore the config file
(or the dll) when the public key token is specified.

I agree, this should not happen.
Any help or point in the right direction would be, again, greatly
appreciated.

Sign the library and build the process against the signed library. Once
you have done that you need to set up code access security to allow the
library to be executed. Details of all of this can be found in my
tutorials (see my sig).

Richard
 
Thanks Richard,

The application itself (DBAuthTest.exe) is not compiled against the
signed DLL. This is what I would like to happen, because the whole
reason I'm going through this mess is to emulate the current setup we
have, where we can currently change the DLL and the application will
use the new DLL without having to re-deploy the application. If the
application itself must be compiled against the signed DLL, if I later
change & re-sign the DLL, I will have to re-compile the application
again, right? This is probably the part that is giving me my
headaches...

This whole mess has me wondering if I need to go back to the
requirements and re-think a solution that can be better implemented in
..NET.

Thanks again for your response,
Mike
 
Back
Top