Dynamic compilation and .dll-s? (Facebook.dll)

Topics: Troubleshooting, Writing modules
Developer
Aug 26, 2011 at 9:57 PM

Hi all!

Are there any known issues regarding Orchard's dynamic compilation of modules and they having several .dll files? I tried to install the two modules from the gallery that implement Facebook authentication (http://orchardproject.net/Gallery/List/Modules/Orchard.Module.NGM.OpenAuthentication/0.4.5 and http://orchardproject.net/gallery/List/Modules/Orchard.Module.FacebookConnect) and they both died with various exceptions. One common problem was that both modules apparently failed to load the Facebook.dll assembly (this is part of the FB SDK: http://facebooksdk.codeplex.com/) as the compiler couldn't load a class inside this assembly. The assemblies are however properly referenced in the modules's csproj file (and are there in the referenced folder). Could it be that somehow these dlls are not picked up by Orchard? Should I provide details?

Coordinator
Aug 26, 2011 at 10:08 PM

Well, that should just work. You could try copying the dll to bin I suppose.

Developer
Aug 27, 2011 at 3:35 PM
Edited Sep 2, 2011 at 10:54 AM

Turns out it was most likely some naming clash! When I deleted the Facebook module (http://orchardproject.net/gallery/List/Modules/Orchard.Module.Facebook), OpenAuthentication became normal. An interesting fact is, that the Facebook Connect module still couldn't install properly, at last dying with the problem that its tables weren't created. I can only assume that this also had to do with other installed modules, because when I started with a fresh install of Orchard, this module installed properly as well.

So I have concerns of Orchard modules clashing with each other. One remarkable point is a name clashing with content parts: there can't be content parts with the same name in different modules as this leads to problems with schema creation and also when selecting them in them admin menus (because then their displayed name is also the same). With some general names (like "comments") this could be an issue. Maybe simply advising developers to prefix their content parts with the module name could be a solution, although this would create horrible table names.

Developer
Aug 28, 2011 at 1:27 PM
Edited Aug 28, 2011 at 1:28 PM

Hey Piedone, thanks for finding the steps to reproduce. I had an initial converation about it but forgot how to reproduce. http://orchard.codeplex.com/discussions/253588

I also logged an issue to fix something similar to this a while ago - Two modules with the same Orchard Feature name causes a crash - http://orchard.codeplex.com/workitem/17749

Nick

Coordinator
Aug 29, 2011 at 9:15 PM

Yes, our general approach so far to name conflicts has been to wait and see, a.k.a. the jQuery strategy. Installing two modules that solve a similar problem increases the chances of collision. Would it be an option to contact the authors of both modules and try to see what it would take to make them compatible?

Developer
Aug 31, 2011 at 10:08 AM

Ah but the problem is that the two modules are different to each other. The one I have is based on Authentication, and then enablign the 'Facebook' feature allows the user to logon through Facebook. Another module maybe for I dunno content sharing, and that could be made up of many Features.

I think rather than make them compatible with each other it would be best to fix this in Orchard - After all with a larger eco system collisions will increase

Nick

Coordinator
Aug 31, 2011 at 8:58 PM

For the moment they will have to both use the latest version of their dependency. Running two versions of the same assembly in a single app domain is not something that we can fix in Orchard unless I'm mistaken. It would have to be doable at the .NET framework level, which it isn't unless I'm missing something.

Developer
Aug 31, 2011 at 9:05 PM

Hmm... What if I changed one of the facebook dlls names to I dunno FacebookA.dll?? Would that work?

Coordinator
Aug 31, 2011 at 9:08 PM

If you have the source code, you might be able to compile it to a different assembly name, but just changing the file name won't be enough.

Developer
Aug 31, 2011 at 9:11 PM

Yeah I have the source code for my module, So if I change the external Facebook.dll filename, and then recompile the module, you think that should be fine?

Coordinator
Aug 31, 2011 at 9:27 PM

I was referring to the source code for facebook.dll. I don't think renaming the file would suffice.

Developer
Aug 31, 2011 at 9:55 PM

Hmm the thing is that I would use an assemblybinding, but the way orchard does compilation I dont think it will work and loading two versions of the same dll should be avoided as its not best practice. Also how would this affect other modules?

What about this http://www.tobinharris.com/past/2008/8/6/using-two-net-assemblies-with-the-same-name-but-different-versions/ and then put the path to the lib folder of the dlls.? To me this seems like a complete and utter hack, so I would rather you said, 'nick dont do that'

Hmm... Is there nothing that we can do in Orchard it's self?

Coordinator
Aug 31, 2011 at 10:18 PM

Well, the way we've dealt with similar situations in our own code is by first making a module with the dependency, and then have other features depend on it. It does not exactly solve the problem but it makes the process easier to discover. The example I'm thinking about is TinyMce.

In this case, there should probably be a Facebook module that does nothing but bring the dll in. Then, all modules that do Facebook stuff would take that dependency. It does require some coordination between those modules, but nothing that seems unmanageable.

Developer
Sep 2, 2011 at 11:04 AM
Edited Sep 2, 2011 at 11:10 AM

Having a module to only contain the dependency dlls looks great but I still have weird issues. The problem persists (the one Jetski5822 made a screenshot of: http://twitpic.com/4mtkdp/full) even with a reseted install of Orchard (App_Data deleted), and with any conflicting module folders deleted (only one remains). The dlls are there and are correctly referenced. I don't have a clue.

So to conclude: it seems that if there is a clash with dlls (like two modules using Facebook.dll), there is no way to bring things back to track unless getting a fresh clone of Orchard source. I can't understand why the error remains even if App_Data is wiped out.

Sep 2, 2011 at 11:32 AM
Hi,

This happened to me and I deleted the Facebook Connect module from the modules folder and it worked again.

I think that there needs be some guidelines on namespacing your modules so conflicts like this don't occur.

Steve



On 2 Sep 2011, at 11:04, "Piedone" <notifications@codeplex.com> wrote:

From: Piedone

Having a module to only contain the dependency dlls looks great but I still have weird issues. The problem persists (the one Jetski5822 made a screenshot of: http://twitpic.com/4mtkdp/full) even with a reseted install of Orchard (App_Data deleted), and with any conflicting module folders deleted (only one remains).

So to conclude: it seems that if there is a clash with dlls (like two modules using Facebook.dll), there is no way to bring things back to track unless getting a fresh clone of Orchard source. I can't understand why the error remains even if App_Data is wiped out.

Developer
Sep 2, 2011 at 11:49 AM
Edited Sep 2, 2011 at 11:52 AM

SOLVED, SOLVED, SOLVED! (and it was only half a day from my life :-))

It seems what I've previously written is only partially true. There is one Stack Overflow contribution that hinted the solution. The root of the problem was that the assemblies were not referenced in the module's root Web.config! Strange it is, but assemblies should be referenced not only in the csproj file, but also in the Web.config!

So for example for the Facebook dlls, in the Web.Config write:

 

        <add assembly="Facebook, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL" />
        <add assembly="Facebook.Web, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL" />
        <add assembly="Facebook.Web.Mvc, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL" />

 

into

 

<system.web>
    <compilation targetFramework="4.0">
      <assemblies>

 

The assembly attribute should contain the same as it is in the csproj references' Include attributes:

 

<ItemGroup>
    <Reference Include="Facebook, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>bin\Facebook.dll</HintPath>
    </Reference>
    <Reference Include="Facebook.Web, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>bin\Facebook.Web.dll</HintPath>
    </Reference>
    <Reference Include="Facebook.Web.Mvc, Version=5.2.1.0, Culture=neutral, PublicKeyToken=58cb4f2111d1e6de, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>bin\Facebook.Web.Mvc.dll</HintPath>
    </Reference>

 

Installing the Facebook SDK with NuGet is not properly working as it only installs the dlls partially (I tried with Facebook.JavascriptMvcWebsite as advised here, but only Facebook.dll was downloaded and referenced), and it doesn't touch the Web.config.

I think this is a decent issue but I don't know what can be done to eliminate the need of referencing assemblies in the Web.config. Anyway, I think it is something worth mentioning in the docs.

Developer
Sep 2, 2011 at 11:55 AM

Regarding the use of multiple versions of assemblies: http://www.lavgupta.com/2011/03/type-systemxmlixmllineinfo-is-defined.html

May 31, 2012 at 10:23 AM
Piedone wrote:

Regarding the use of multiple versions of assemblies: http://www.lavgupta.com/2011/03/type-systemxmlixmllineinfo-is-defined.html

That url has changed to http://blog.lavgupta.com/2011/03/type-systemxmlixmllineinfo-is-defined.html

May 31, 2012 at 10:34 AM

So Piedone, in your solution here, does this mean that the app will look to the Modules bin folder instead of the Orchard Dependencies folder for the dll when executing the module code? If this is the case, as far as you know, will Orchards ExtensionLoaderCoordinator still load these dlls from the project into AppData\Dependencies ? I suppose I could try this for myself, but I thought I'd see if you recall.

Developer
May 31, 2012 at 10:57 AM

This was a long time ago... :-) I can recall that later I still got issues, so I've came to the solution that finally works for me, but I guess is not a real option for you: I've sorted the dependency out to a separate module (that's the FacebookSDK module), referenced the dlls in it from the consumer module, then added this simple entry to the Web.config (more is not needed):

  <system.web>
        <add assembly="Facebook" />
      </assemblies>
    </compilation>
  </system.web>

This is with the v6 SDK, so there is only one dll (formerly there were three to use with an Orchard module). I didn't try further to solve the problem of conflicting assemblies.

You probably could ask the author of the module you use and includes the SDK to rather depend on the FacebookSDK module.