Azure - cannot load assembly.

Topics: Installing Orchard
Feb 21, 2011 at 6:11 PM

Hello

I generated Azure package using script. After running instance I get error:

"Could not load file or assembly 'System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies."

What am I doing wrong?

Piotr

Coordinator
Feb 21, 2011 at 7:32 PM
Edited Feb 21, 2011 at 7:33 PM

You probably have Razor installed in the GAC of your dev machine. These assemblies aren't in the GAC of Azure VMs. The solution is to edit the "Orchard.Azure.Web.csproj" files and add a "<Private>True</Private>" element to all assemblies coming from the "lib" folder (search for "<HintPath>..\..\..\lib"). We've fixed that in the 1.1 branch but missed it in the 1.0 release. After the fix, you should see all these assemblies in the "~/bin" folder of the app, even if they are in the GAC of your dev box.

HTH,

Renaud

Feb 23, 2011 at 5:54 PM

Copy local is set to true. But I still get the same error after deployment. I checked, and this assembly is in bin directory.

Coordinator
Feb 23, 2011 at 7:34 PM

It could be one of the dependencies. Are all the assemblies present in "lib\aspnetmvc" in the "bin" directory.

Another possibility is that you have a "preview" version (i.e. pre-RTM) of MVC and/or ASP.NET WebPAges installed in the GAC. This tends to create various issues which are difficult to diagnose.

Also, we've recently noticed that "Copy Local" set to true in Visual Studio doesn't always mean "Private=True" in the csproj. The behavior seems to be that if the assembly is in the GAC and you select "Copy Local=true" in VS, sometimes the csproj files is not changed to "Private=True". So, yes, the only way to know for sure is to check the .csproj file and the content of the "bin" directory.

HTH,

Renaud

Mar 2, 2011 at 6:40 PM
Edited Mar 2, 2011 at 7:39 PM

OK, it works now. Thanks!

Mar 28, 2011 at 8:43 PM

Renaud,

Would you mind clarifying exactly which "~/bin" directory you're referring to?

My src\Orchard.Web\bin directory is "full", but my src\Orchard.Azure\Orchard.Azure.Web\bin directory remains mostly empty, even after making the changes specified above. Additionally, when I use ClickToBuildAzurePackage.cmd, my .cspkg file comes up to about 15MB in size, as opposed to the 30MB file size of the downloadable .cspkg file... I'm guessing the lack of ~\lib files is the difference (although I don't know enough about "debugging" the .cspkg file to inspect the files that are and are not included). 

Thanks in advance!

Mar 29, 2011 at 7:10 PM

I'm experiencing the same issue as cwiederspan. 

Mar 29, 2011 at 7:30 PM

All of my problems were related to the Copy Local = True issue. Once I really took some time to go through all projects and make sure all of the ..\..\lib files were <Private>True</Private> (like mentioned above), I had one final issue that took me a while to figure out... It was the log4net.dll that's referenced in the Orchard.Framework (I think) project - I couldn't get that one to be included in the ~/bin directory no matter what I tried. Eventually, I resorted to cheating - I just add a direct reference to the log4net.dll assembly right to my Orchard.Azure.Web project, and made sure it was set to Copy Local. Once I figured all of that out, everything started coming together, and I'm up and running now.

BTW, the file size of the .cspkg seems to be right at about 15MB. Not sure why the downloadable pre-canned file is so big at 30MB.

Mar 29, 2011 at 9:54 PM

One other quick note... It seems that you MUST have the Azure Local Dev Storage running on your machine when you execute ClickToBuildAzurePackage.cmd, or else you'll get some fatal test exception. I guess that makes sense.

Mar 29, 2011 at 10:03 PM
Yeah, already ran into that one a few days ago.



On Mar 29, 2011, at 5:54 PM, "cwiederspan" <notifications@codeplex.com> wrote:

From: cwiederspan

One other quick note... It seems that you MUST have the Azure Local Dev Storage running on your machine when you execute ClickToBuildAzurePackage.cmd, or else you'll get some fatal test exception. I guess that makes sense.