The check of the signature failed for assembly 'Spring.Core'

[kingdona]

I am new to Spring.NET so please excuse me if this is simple or already asked somewhere. I did a search of the forum and did not seem to find the issue I am having.

I am using Spring.NET in conjunction with DotNetNuke and I keep getting the error:

'The check of the signature failed for assembly 'Spring.Core'

In my web.config file I have the below defined as a section group:

<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler , Spring.Core" />
</sectionGroup>

And then lower in my web.config I have the following:

<spring>
<context type="Spring.Context.Support.XmlApplicationContext , Spring.Core">
<resource uri="config://spring/objects"/>
</context>
<objects>
<description>Integration of Spring.NET Framework into DotNetNuke.</description>
<object name="GuestBookController"
class="SBG.SE2.SE2GuestBook.SE2GuestBookMockContro ller, SBG.SE2.SE2GuestBook"/>
<objects xmlns="http://www.springframework.net"/>
</objects>
</spring>


Here is more information about the error I am getting:

=== Pre-bind state information ===
LOG: DisplayName = Spring.Core
(Partial)
LOG: Appbase = file:///C:/Downloads/dnn
LOG: Initial PrivatePath = bin
Calling assembly : (Unknown).
===

LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Post-policy reference: Spring.Core
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/dnn/705dfc7d/54b51e9c/Spring.Core.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/Temporary ASP.NET Files/dnn/705dfc7d/54b51e9c/Spring.Core/Spring.Core.DLL.
LOG: Attempting download of new URL file:///C:/Downloads/dnn/bin/Spring.Core.DLL.
LOG: Publisher policy file is not found.
LOG: No redirect found in host configuration file (C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspn et.config).
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\confi g\machine.config.
LOG: Post-policy reference: Spring.Core, Version=0.6.0.0, Culture=neutral, PublicKeyToken=65e474d141e25e07


Any help is appreciated.

Thanks,

DK

[Mark Pollack]

Hi Dona,

I'd bet this is related to my mistake is only delay-signing the .dll in the RC2 release. Doh! You can try this work around to skip assembly verification

sn -Vr *,65e474d141e25e07

Let me know if that is on OK solution for you now. If not I'll post a properly signed .dll on the web for you.

Keep us posted!

Cheers,
Mark

[Anonymous]

Hi Mark - Thanks for the reply. I actually had found that post when I searched the forums earlier. I ran the command but it didn't seem to help and I still have the same error. Do I need to do something additional such as a recompile? I just replaced the assemblies in my DotNetNuke bin but perhaps that was not enough. Thanks!

Don

[kingdona]

Mark - I did a recompile again as I failed to notice that it was building into a separate directory instead of the bin folder. (Had I checked the date on the assembly there and noticed that it had not changed it would have saved me some trouble :-))

Anyway, your fix worked and once I replaced the DLLs in my DotNetNuke bin with the correct newly compiled ones DNN fires right up.

Thanks for your help!

Don

[Mark Pollack]

Hi Dona

Yea - the main build compiles 'off to the side'.

Great, though you shouldn't need to recompile in order for sn -Vr to work. There is still something odd going on here. I'll have to look into this some more and get DNN up and running.

- Mark

[kingdona]

Mark - My original reference pulled to the Spring.Core assembly came from the bin folder instead of the VS.NET build area. Perhaps that is why it worked after I replaced it. The rebuild may have just been coincidental.

You had mentioned something else about my config section, can you tell me what that was? I am getting an error now in the <spring> section I have added:

<spring>
<context>
<resource uri="config://spring/objects"/>
</context>
<objects>
<description>Integration of Spring.NET Framework into DotNetNuke.</description>
<object name="GuestBookController"
class="SBG.SE2.SE2GuestBook.SE2GuestBookMockContro ller, se2.dnn.modules.se2guestbook"/>
</objects>
</spring>

It is saying there is an error with the line that has <context> (Line 35 below). The XML is well formed so I don't know why it is blowing up. Any ideas?

Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Exception in configuration section handler.

Source Error:


Line 33: </appSettings>
Line 34: <spring>
Line 35: <context>
Line 36: <resource uri="config://spring/objects"/>
Line 37: </context>




Thanks!

Don

[Mark Pollack]

Hi,

If you look back at your original post, there were two <objects> tags in the XML.

Turning off the validation should have worked with the .dll in the distribution ./bin directory - so maybe it is some other issue. We'll look into that.

What version of spring are you using? In RC2 we changed the DTD to be 'type' instead of 'class', and I see the 'class' attribute in your XML so that looks suspicious but it isn't at the line indicated in your error log. (Current CVS now uses schema for parsing instead of the DTD. ) Also what version of DNN?

If you are editing inside web/app.config you can install a schema into the VS.NET program directory by typing 'nant deploy-schema'. Then adding <object xmlns="http://www.springframework.net" > will give you validation inside VS.NET. You can read a little more about that in the vs integration docs.

The errors you are showing look like some interaction with DNN because Spring doesn't print exceptions like that. Where are you creating the context and with what code?

A simple sample xml config file for app.config looks like this

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

    <configSections>
        <sectionGroup name="spring">
            <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
            <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
        </sectionGroup>
    </configSections>
 
    <spring>
    
        <context>
            <resource uri="config&#58;//spring/objects"/>
        </context>
        
        <objects>
            <description>An  example that demonstrates simple IoC features.</description>
            <object name="MyMovieFinder" type="Spring.Examples.MovieFinder.SimpleMovieFinder, MovieFinder"/>
        </objects>
    
    </spring>
    
</configuration>

If you can send me a private message in the forum we can exchange some email with your config files for DNN. (Click on member list and then you will see a PM icon to send a message.) It obviously it shouldn't be this hard to get started so it is probably something silly or subtle.

(BTW In CVS there is initial ASP.NET support to perform dependency injection on pages and other functionality. There are docs on our wiki, but lets tackle one thing at a time.)


Cheers,
Mark

[Aleks Seovic]

Mark,

There is an issue with rebuilding and delay signing of RC2 -- public key is not included in the distro, so if users rebuild DLLs they end up with random public key (or no public key at all, not sure which one exactly happens). In that case, turning verification off doesn't do anything -- rebuilt DLLs are still verified because verification is turned off for our public key and they don't have the same key.

I fixed build script to include public key in the future, but RC2 recompilation won't work as is. Sandu and I tracked this down few weeks ago when he had the same problem, sorry I forgot to let you know. The easiest fix is to add public key file manually to RC2 zip.

As for the config section parsing problem, I believe duplicate <objects> tag is the problem. Otherwise, config looks fine to me and should work. The fact that XmlApplicationContext is used doesn't matter, as resources are loaded from the config section so there are no issues with the resource path.

-- Aleks

[kingdona]

This has been resolved. I had some issues with the config file as you mentioned and I also had some development "issues" with my own code :-).

Thanks for your help!

Don