Can't display web page from Web Client Software Factory 2010

Topics: Web Guidance v-Next (not WCSF)
May 1, 2010 at 12:42 AM

After finally being able to successfully register the Web Cient Factory Guidance Package, I created an empty Web Client Solution C# Web Site. The Shell module compiles correctly, but the web site does not and displaying the created default.aspx page generates an error. The error is:

Error 1 Could not load file or assembly 'Microsoft.Practices.CompositeWeb, Version=2.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)  

None of the original assemblies from the guidance package are signed. How am I ending up with an error indicating that the strong name signature could not be verified? How can this be corrected?

Thanks,
Gilles

May 1, 2010 at 3:02 AM
gmuys wrote:

After finally being able to successfully register the Web Cient Factory Guidance Package, I created an empty Web Client Solution C# Web Site. The Shell module compiles correctly, but the web site does not and displaying the created default.aspx page generates an error. The error is:

Error 1 Could not load file or assembly 'Microsoft.Practices.CompositeWeb, Version=2.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)  

None of the original assemblies from the guidance package are signed. How am I ending up with an error indicating that the strong name signature could not be verified? How can this be corrected?

Thanks,
Gilles

 

I too had the same problem but I believe my mistake when building the WCSF source was that I didn't get the "exact" version of the Ajax Toolkit DLL as described in the readme.  Make sure you follow these specific instructions exactly:

Note:

   don't click on AjaxControlToolkit-NoSource.zip. That zip contains 1.0 version of the DLL, which is not what you want.

**copy AjaxControlToolkit-Framework3.5-NoSource.zip\SampleWebSite\Bin\AjaxControlToolkit.dll to this folder.

   Note: Please check the property of the DLL to make sure that the version number is 3.0.11119.

When I corrected this and re-compiled I got past that error.

 

May 1, 2010 at 3:14 AM

Yes, I did pay attention to that and made sure I had the correct version. However, I also noticed that the AjaxControlToolkit.dll was not added to my web client solution by the guidance package. Not sure if that is normal or not. In any case, I copied all the DLLs from the /lib/WCSFBlocks to the web site /bin folder. I am still getting the error. I spent several hours searching on the internet on a possible solution, but no success so far. Thanks for your suggestion though.

May 1, 2010 at 3:38 AM

Try also adding as a reference in your web project.   Just dropping it in the /bin folder is not always enough.

 

May 1, 2010 at 4:07 AM
Edited May 1, 2010 at 4:11 AM

I just did, but no luck. Still getting the error.

However, I noticed that the AjaxControlToolkit assembly was not in the list of references when looking at the References tab of the Property pages for the web site. I manually clicked the "Add..." button to add it (as well as all the other assemblies in the bin folder). The other assemblies are listed in the list of references, but not the AjaxControlToolkit.

Here is the list of references in the tab:

Microsoft.Practices.CompositeWeb
Microsoft.Practices.CompositeWeb.EnterpriseLibrary
Microsoft.Practices.EnterpriseLibrary.Common
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging
Microsoft.Practices.EnterpriseLibrary.Logging
Microsoft.Practices.EnterpriseLibrary.Security
Microsoft.Practices.ObjectBuilder

Plus of course the Shell project (which compiles without any problem)

Am I missing anything there?

May 1, 2010 at 4:14 AM

Another thing: looking back at the Microsoft.Practices.CompositeWeb project from the guidance solution, its only dependency is the ObjectBuilder assembly. That assembly is clearly reported as a reference in the web site. So the AjaxControlToolkit assembly should not have any relationship with the error, correct?

May 1, 2010 at 4:44 AM

I made some good progress and believe I am very close to the final resolution but need some input. The CompositeWeb assembly in the Guidance package is 148k in size. The one I have in the web site when creating the solution from the guidance package is 110k. I conclude that something got corrupted when registering the guidance package.

If I copy my 148k assembly to the bin folder and rebuild the website, it is replaced again by th 110k version and the error is produced. Since the project is defined as a website instead of a web application, I don't know how to find the original location of the 110k assembly. Where is it stored when the package is registered in VS?

May 3, 2010 at 2:04 PM

Did you have any luck in resolving this issue?

I have the same problem and I'm not quite sure how to resolve this. I've done the following steps:

- Installed GAX/GAT for VS2010 Ultimate RC (don't have the released VS yet)
- Grabbed the AjaxControlToolkit, from the link specified in the readme.txt
- Double checked the AjaxControlToolkit.dll version (it says version 3.0.11119.0)

Created a Release build for the WebClientFactoryPackage project and executed the bin\Release\Microsoft.Practices.WebClientFactory.GuidancePackage.vsix file to install the templates into Visual Studio.

I can create a new Web Client Solution (C#, WAP) though the File -> New Project options in Visual Studio and build the solution without problems, but when I try to run the web application I get the same exception (Could not load file or assembly 'Microsoft.Practices.CompositeWeb, Version=2.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered....)

I somehow doubt it has anything to do with the AjaxControlToolkit.dll file. But then again, I don't have a clue what else it could be.

By the way, my system runs:
- Visual Studio 2010 RC
- Windows 7, 64-bits

Any help would be appreciated! Thanks in advance!

 

Cheers,

Groggy

May 4, 2010 at 10:24 AM

To follow up on yesterday's post.

Today I discovered something strange. I still don't understand it, but hopefully someone here can explain me what to do about this.

At first I had been following the line of thought of the poster(s) above. Thinking that somehow the AjaxControlToolkit.dll might have caused something to happen. When I started tracing the way down, there's absolutely no reference or anything that points towards the AjaxControlToolkit assembly. I figured to myself, it must be something else, I also had a gut feeling that I was approaching this problem in the wrong way. This morning, I started the ModularityQuickstart project that came with the WCSF2010.Source files. I started the project and I was kind of amazed to find that this project didn't give the exception about Composite.Web.

I had a look at the Composite.Web reference in the ModularityQuickstart project and found it pointed to: WCSF2010.Sourece\Trunk\Source\Lib\WCSFBlocks\

Further investigation learned that the Composite.Web assembly in this folder gets placed in there when I compile the CompositeWeb project. So far so good. I learned from this that at least the compilation process worked fine and that there is nothing wrong with my Composite.Web assembly. Curious about what would happen if I replaced the assemblies in the Library folder in my newly created WCSF C# WAP, I copied them over. After doing so I hit the rebuild solution button and started the debugger. To my surprise the strong named assembly exception was gone!

Next I tried to be smart. I replaced the Composite.Web assemblies in the folder where the WCSF templates are installed (C:\Users\MyUsername\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Microsoft\Web Client Software Factory 2010\3.0). After doing so, I restarted Visual Studio and created a new project:
File -> New Project -> Guidance Packages -> Web Client Software Factory 2010 -> Web Client Solution (C#, WAP)

Without changing anything, I built the solution and started it. And sadly, the same exception ocurred:
Could not load file or assembly 'Microsoft.Practices.CompositeWeb' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

I replaced the Composite.Web assemblies in the Library folder again, rebuilt the solution and started it: all worked fine.

Can anyone explain this to me?

 

Cheers,

Groggy

May 4, 2010 at 4:01 PM

Hi Groggy, yes I resolved the problem although not permanently. It will come back if I uninstall and re-install the guidance package. Here is how you can resolve things at the moment: copy the assemblies from the WCSF2010.Sourece\Trunk\Source\Lib\WCSFBlocks\ folder to the C:\Users\MyUsername\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Microsoft\Web Client Software Factory 2010\3.0 folder. Then recompile your WCSF C# WAP project and you should be good to go.

I hope this problem will be fixed in the next release.

Gilles

May 5, 2010 at 9:57 AM

Hmm, that's what I have done. Still, when I create a new C# WAP project, it will copy the wrong assemblies.

In my C:\Users\MyUsername\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Microsoft\Web Client Software Factory 2010\3.0 folder the Microsoft.Practices.CompositeWeb.EnterpriseLibrary.dll is 7KB, but after I have created the new solution/projects there is a 17KB Microsoft.Practices.CompositeWeb.EnterpriseLibrary.dll in the Library folder with a different timestamp as well.

So, to me it looks as if the created project does not take the composite.web assemblies out of the mentioned folder?

In either case, it doesn't matter right now. It's only a matter of copying over assemblies once after creating a new project, so it's not overly important.

I'll await the next release anxiously!

Thanks for the response!

 

Cheers,

Groggy

Coordinator
May 5, 2010 at 5:03 PM

Hi Groggy/Gilles,

Sorry for the delayed response on this. I have tried to reproduce your issue successfully. It appears to be because, as you said, the assemblies are not signed.

Another possible workaround, instead of manually copying the assemblies, could be disabling assembly strong name verification for those assemblies. You can do this following these steps (with Visual Studio closed):

  1. Open the Visual Studio 2010 Command Prompt as Administrator.
  2. Run the command sn Vr *,31bf3856ad364e35.

After that I was able to follow these steps:

  1. Downloaded the WCSF 2010 Beta Source.
  2. Unzipped the file.
  3. Copied the AjaxControlToolkit.dll(version 3.0.11119) to the \BlocksTrunk\Source\Lib\AjaxControlToolkit3.5\ folder.
  4. Opened the Web Client Guidance Package solution.
  5. Built the solution.
  6. Executed the .vsix installer.

I was able to create Web Client solutions with no issues and they built and ran correctly.

Please let me know if this helps.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman