Error with module using types from external assembly.

Topics: General, Writing modules
Jan 20, 2012 at 5:58 AM

Hey all.
I have a new module that is using some old items and databases. I am getting this error when I try to view the Index from AdminController.

Compiler Error Message: CS0234: The type or namespace name 'Manager' does not exist in the namespace 'CR.Settings' (are you missing an assembly reference?)

Source Error:

 
Line 31: #line default 
Line 32: #line hidden 
Line 33: using CR.Settings.Manager; 
 Line 34: 
Line 35: #line 2 "F:\SourceCode\Website\Trunk\Modules\CR.Settings\Views\admin\index.cshtml"

Here are the first to lines of my view
@model CR.Settings.VewModels.SettingsIndexViewModel
@using CR.Settings.Manager.Contracts.DataContracts;

I have CR.Settings.Manager refecenced and if I look in the App_Data/Dependencies folder of Orchard I can see that the dlls are there. Any ideas?

I found one link fro the Googles that suggested I try adding a certain sectionGroup to the web.config in my Views folder. I followed those directions and have this, where the link instructed, in the web.config:

<add namespace="CR" />
<

add namespace="CR.Settings" />
<
add namespace="CR.Settings.Manager" />

 

 

Thanks for any insight,
Will

 
Jan 20, 2012 at 12:36 PM

You have to reference it in the project by right-clicking on your project and select "Add References". The Web.config entries won't work on your module, you'd have to change the ones in Orchard.Web, which means your module wouldn't be so easy to install, best never to modify Web.configs at all in Orchard.

Jan 20, 2012 at 4:57 PM

Thanks Pete, but I don't think that's the problem. The external libraries are referenced in the module project (project references, not assembly references).
I have two external projects referenced, one containing service implementation and one containing service contracts only.

The referenced dlls end up in the orchard dependencies folder, so I know they are moving around with the project.

I agree with not editing the web.config but I was just trying something from another site. It was the web.config specific to my modules view folder - edit didn't help, so I've rolled it back at this point.

Any other ideas?

Thanks,
Will

 

Jan 20, 2012 at 5:10 PM

I referenced an external library in my ImageResizing integration. That was by referencing the dll. So maybe a project reference won't work when the project is outside of the Orchard directory structure.

Jan 20, 2012 at 7:46 PM
Edited Jan 20, 2012 at 7:59 PM

Well, I added the other dlls directly into a Dependencies folder in my module and referenced from there. Getting the same error. :(
I can access them just from from inside the controller, it's just the view that is wonky...
Below is part of what is in the view (actual code in the div was replaced for shortness).
Might also be helpful to note that VS has decided to red-underling my @model line and showing a message that System.Web.WebPages must be referenced (which it is)...

Will

@model CR.Settings.VewModels.SettingsIndexViewModel
@using CR.Settings.Manager.Contracts.DataContracts;
@using CR.Settings.ViewModels;
@using Orchard.Mvc.Html;
@using Orchard.Utility.Extensions;
@{
    Layout.Title = T("CR Setting").ToString();
}

<div>Hello Orchard - @Model.Setting.Name</div>
Jan 20, 2012 at 8:27 PM

Ok first of all, it looks like you just have the web project, not a full source code enlistment. For any serious module development it's just better to have the full source from the Mercurial repository on codeplex.

Next, I meant that when you "Add Reference", select the actual dll, rather than adding a project reference. VS nor anything else can't automatically find the dll in Dependencies if it doesn't know what it's looking for.

Jan 20, 2012 at 10:10 PM

Hey Pete, are you using objects from that external assembly in your views, or just in your code behind files?

I made a little bit pf progress with this but it still isn't right. Turns out that the view will throw this error until I drop the external dll into the bin folder of Orchard - then it recognizes the namespace. It didn't matter that I referenced the actual dll from a Dependencies folder local to the module. The dll would get into the module bin and to the Orchard/App_Data/Dependencies folders, but the view would still throw that error. I drop the dll into Orchard/bin and it works... This is not exactly a suitable work-around :(

Any ideas on this?

I see a few core Orchard modules (like Comments) reference external dlls, but I don't see them using any of the objects in views. Could this be the sticking point? Do I have to create corresponding objects, "ViewModels", in the module, to match the contracts from my service? Man, I hope not...

Thanks,
Will 

Jan 21, 2012 at 1:36 AM

It shouldn't make any difference, if it works in your project then it should work in the views too. But this could be an old error that sometimes crops up and doing a Clean / Rebuild All of the solution sometimes helps.

If something is referenced in your project, and therefore is in your project's bin folder, Orchard will usually copy it to its own dependencies folder for you. You definitely shouldn't need to manually copy anything into Orchard's bin folder, otherwise your module can't just install and run.

It all seems pretty strange but maybe someone else will know more?

 

Jan 23, 2012 at 4:41 AM

A few days later and still at a wall on this one. :(
I've even gone as far as recreating the whole module from scratch using the code generator module for Orchard and manually moving over all of the previous code to it. It just refuses to let my views use objects from external assemblies.

I have tried everything I can think of, short of reinstalling Visual Studio...
Even spun up a brand new Orchard site (even though the one I was working in was only 2 weeks old...).

This one has gone from being a curiosity to an annoying time sucker. :(

Will

Jan 23, 2012 at 5:43 AM

FINALLY stumbled upon something that works!

In the web.config for my module, if I add:
<add assembly="CR.Settings.Manager"/>
<
add assembly="CR.Settings.Manager.Contracts"/>
..Other necessary assemblies like System.Runtime.Serialization...

then it works. All this time I've been ignoring the module web.configs (just copying from other modules) because for all I knew they were only serving the purpose of allowing Razor intellisense and allowing the views to be served by IIS. Apparently they are doing way more than that.

Kinda a pain to have to add these manually. Wonder if there is a way to automatically add these lines when an assembly is references in the project?

Either way, I am happy to finally be over this obstacle. Now back to actual productivity.

Thanks for the help Pete - this one falls into that catogory of Orchard "gotchas" that would make a great blog post.
Maybe I'll write it. :)

Will

  

Jan 23, 2012 at 8:30 AM

It's certainly something I haven't had to do, well done for figuring it out, it'll definitely save me some headaches if I ever run into the same thing!

Mar 8, 2012 at 5:08 PM

I think I have a similar problem, this didn't help me though. Quite simply I have a module referencing an assembly. I'm referencing it from the bin of my module (modeled after the Lucene module). That referenced assembly never gets copied to App_Data\Dependencies.

Even with the Lucene example, I can't for the life of me see why Lucene.Net.dll get copied over, yet my assembly doesn't. They are set up the same, I even added the assembly code you suggest although Lucene doesn't seem to need it and it did nothing for me.

I can make my site work by placing the .dll I need in a place the runtime can see it. But if I wanted to distribute this module, not being able to use external assemblies is a big problem.  Anyone know how the heck Lucene manages to get Lucene.Net.dll copied to App_Data\Dependencies?

Coordinator
Mar 8, 2012 at 5:15 PM

Is the assembly in the GAC ?
Have you referenced the assembly from Orchard.Web (it's not a suggestion, just a question to identify why the dll doesn't get copied)

 

Mar 8, 2012 at 6:14 PM
Edited Mar 8, 2012 at 6:29 PM

No, it isn't a GAC assembly.  Its our general .Net lib assembly.

I think the problem might be my project type- it doesn't have the little globe icon other modules do, I think it got created as a class library. Is the correct project type "ASP.NET MVC 3 Web Application"?

Mar 8, 2012 at 6:56 PM
Edited Mar 8, 2012 at 7:02 PM

No, that didn't do it. Could there be something I need to add to the proj file?

In the admin, I get this handy message:

The assembly reference 'PlanetTelex, Version=2.0.0.0, Culture=neutral, PublicKeyToken=d5e74e497a944cb3, processorArchitecture=MSIL' could not be loaded for module 'PlanetTelex.Coverflow'.

There are generally a few ways to solve this issue:
1. Install any dependent module.
2. Remove the assembly reference from the project file if it's not needed.
3. Ensure the assembly reference is present in the 'bin' directory of the module.
4. Ensure the assembly reference is present in the 'bin' directory of the application.
5. Specify the strong name of the assembly (name, version, culture, publickey) if the assembly is present in the GAC.

Sadly, tip #3 isn't doing the trick. I can do #4 clearly, but don't want to.

Mar 8, 2012 at 7:58 PM

Well, I'm giving up on this for now. I'd like to eventually distribute this module though so if there are any suggestions I'd like to hear them.  

The assembly PlanetTelex.Coverflow.dll does get added to the dependencies folder, its just its referenced assembly PlanetTelex.dll does not. I've now converted the project to MVC 3, so it wasn't that. I added an "add assembly="PlanetTelex" to the web.config file and that didn't help either.

I take it that, in general, Orchard copies all referenced assemblies from a module's bin.  So putting a .dll in a module's bin and referencing it from there is supposed to work, correct? This leads me to assume there is something about the assembly that is weird? You asked earlier if it was registered in the GAC. It is not- but it does have a strong name. Could that be a problem?

Mar 8, 2012 at 8:23 PM

Sorry for my delay. Here are some things to check.
On the reference in your project, did you set Copy Local = True
Did you verify that you have the <add assembly="xyz.abc" /> in the web.config (the one local to your module, no to the website). These need to be in the
<system.web><compilation targetFramwork="4.0"><assemblies> node.

These two things are what made it work for me.

Thanks,
Will

Coordinator
Mar 8, 2012 at 9:10 PM

If you want to be really sure about the reason why it doesn't copy it, you can debug the dynamic compilation code. It must be one of the IAssemblyLoader implementations

Developer
Mar 8, 2012 at 10:00 PM

Did you also try copying it to the Dependencies folder (in App_Data)? That always worked for me when referencing other libraries that are not Orchard modules.

Developer
Mar 8, 2012 at 10:01 PM

Oh never mind, your first post states that you already checked that.

Developer
Mar 8, 2012 at 10:14 PM
PlanetTelexInc wrote:

The assembly PlanetTelex.Coverflow.dll does get added to the dependencies folder, its just its referenced assembly PlanetTelex.dll does not


Just wonderwing if you tried coying the PlanetTelex.dll manually to the Dependencies folder?

Mar 28, 2012 at 1:03 AM

Oh sure, of course it works if I copy the dll manually to that directory, but I was trying to build a module that could be installed and activated normally via Orchard. I've shelved the problem for right now since it really only applies to distribution of the module. Worst case scenario I'll copy the few methods from that referenced assembly out and not deal with it at all.

As for your suggestions, websitewill- yes to both. I do have copy local and in web.config for the module, in that section I have:

<add assembly="PlanetTelex" />
If I debug the assembly loader and figure it out, I'll post what happened.

Coordinator
Mar 28, 2012 at 1:21 AM

Did you look at any of the modules on the gallery that come with similar references?