PublicKeyToken=null when using 'Edit Enterprise Library Config' designer

Topics: Enterprise Library Core, General discussion, Security Application Block
Mar 24, 2009 at 10:16 AM
Hello,
I am trying to get a security demo working by using an AzMan provider, to handle authorization requests to areas of an application.
I have installed Enterprise library 4.1, and have referenced the DLLs from the installed location in c:\Program Files.

When I right-click on the web.config and  'Edit Enterprise library configuration', I add an AzMan Provider to the Security Block and what this does is to put the following line into the web.config (line 4):
<section name="securityConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Security.Configuration.SecuritySettings, Microsoft.Practices.EnterpriseLibrary.Security, Version=4.1.0.0, Culture=neutral, PublicKeyToken=null" />
When I try to call
IAuthorizationProvider provider = AuthorizationFactory.GetAuthorizationProvider("AzMan Provider");
it throws an exception:
"An error occurred creating the configuration section handler for securityConfiguration: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Security, Version=4.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) (c:\Temp\WebApplication1\web.config line 4)"
If I manually edit the web.config and take the PublicKeyToken=null out, then it works.  But, the designer puts it back in again whenever I use it to save the web.config so obviously I would like to try to find a better solution i.e. get to the bottom of what is actually going wrong.
It seems to me like it is trying to load an assembly with a PublicKeyToken of null, when the Microsoft.Practices.EnterpriseLibrary.Security assembly hasn't got a public key token of null, so why is it trying to demand that it be null?
I should also point out that I did also install the source code, and initially referenced the dlls from there. But I suspected conflicts between these DLLs and the installed ones may be an issue, so I removed all reference to these (including deleting them from 'temporary asp.net files' folder), and referenced the DLLs instead from the installed location in C:\program files, which I gather is the location where the designer runs from... and this doesn't seem to have solved the problem.

Any ideas much appreciated!
Thanks very much
Ben

Mar 24, 2009 at 10:33 AM
I suspect that you are using the configuration tool from the source code.  Try opening it with the EntLibConfig.exe from the installation folder of entlib, under the bin folder.


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc
entlib.support@avanade.com
Mar 24, 2009 at 10:39 AM
OK thanks very much for the speedy reply. What you've said works. If you know of any way to update the visual studio designer version to match the installed binaries, that would be great but if not it's no big issue because it would seem using the standalone is ok. 

Mar 24, 2009 at 10:59 AM
I'm not sure I get what you mean.  If you used the configuration tool from the source code, it would definitely use the assemblies against which it is built, which is the unsigned ones.  In addition,
4.1 is already integrated in Visual Studio.  In fact, if you right click on the configuration file, a context menu item of "Edit Enterprise Library Configuration" is already included which allows you
to use the configuration tool within the Visual Studio designer.


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc
entlib.support@avanade.com
Mar 24, 2009 at 11:24 AM
What I mean is, the config file designer that is launched from within Visual Studio itself would appear to be the one that was built by compiling the source code, rather than the one that was installed as part of the installation, hence the wrong one. (If that's possible?)
If I use the standalone one I can choose whether to use the one that was built from the source code, or the one that was installed - no problem there. But I don't have that choice when invoking it from within Visual Studio.

And just another question if I may on a slightly different but related matter: I use a custom security provider called MyAuthorizationProvider in its own assembly, which I have given [assembly: AssemblyVersion("1.0.*")], so it gets a new version number each time. However, the line in the web.config file that the config editor has put there says 

      <add type="SecurityDemoLibrary.MyAuthorizationProvider, SecurityDemoLibrary, Version=1.0.3370.18597, Culture=neutral, PublicKeyToken=null"
name="Custom Authorization Provider" />

yet it still manages to load the newly built version even though its version number is now incremented to something greater than 1.0.3370.18597, this is what I want to happen - but how is it managing to do this?

Mar 24, 2009 at 11:43 AM
If you invoked it from the Visual Studio, you can still choose which configuration editor to use.  Just right click on the configuration file, select Open With and then you get to Add other
tools to use to open your config file.  In your case, you can click Add and then browse to the location of the config tool from the source code and then it will get added to the list. 

Regarding on your second question, I think you have to redirect it to other forums, I believe it's a question on how Visual Studio does assembly loading and I'm no expert on that matter. :)


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc
entlib.support@avanade.com