views:

1243

answers:

5

I have a assembly made in another project (projA). Now I want to import this dll in another project (projB). How can I achieve this? This is what I've tried (in projB).

1 Put dll in same dir as my project. (the bin dir)

2 In we.config:

<assemblies>
  <add assembly="projA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</assemblies>

This is the error I get:

Could not load file or assembly 'projA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

EDIT:

The point is that eventually the assembly reference must me added dynamically

EDIT 2:

The name of the assembly (and namespace) are stored in the database. The physical assembly (dll) is added (by installation) in projB. Now the code in projB must read the assembly name from the database and then add a reference to the dll which is added by installation.

+2  A: 

Are all of projA's dependencies in projB? Usually I'd just add a reference from one project to another if they are in the same solution.

Edit:

If you want to add an assembly dynamically then maybe a service reference maybe something to consider. By dumping in projA's DLL into the bin that doesn't really give all the DLLs that it may require, thus there are ways to tie things together so that objects can be understood across systems, like web services using XML to give a common example.

My question back about adding an assembly dynamically is where would you get it from and can that part be automated to be part of projB as that is really the general solution to this kind of problem.

Edit 2:

How could you get all of projA's dependencies? Is it possible to get it so that it doesn't depend on a bunch of other DLLs that may or may not be on the system that this is to run. That is what the error is telling you, that there exists some assembly projC that is also required. Note that this adding of assemblies can continue for a long time if there are many levels of dependencies used.

Summarizing the answer: What would you need to reference in order to load projA into some new project? That's your problem which without knowing what the dependencies look like is rather hard to answer directly.

JB King
The point is that eventually the assembly reference must me added dynamically
Martijn
I'm sorry for being so confusing, I've edited my post. Hopefully this makes it more clear
Martijn
+1  A: 

You do not need to add anything in Web.config if the assembly DLL is in the Bin folder - you only need to do this if you are referencing an assembly that is in the GAC.

The error message you are getting is basically saying that the assembly can't be found in the GAC, which is presumably because it isn't there!

Mark B
The assembly loader will look in the local /bin folder first, various other combinations of /bin/ and assembly name, framework folders, etc before going to the GAC.
Zhaph - Ben Duguid
See my edit on the startpost
Martijn
A: 

You don't need to manually add the reference in the web.config file. Right click on your project in the Solution Explorer window in Visual Studio and select 'Add Reference'. Go to the Browse tab and find the DLL you created in the other project, select it and click OK. Optionally, you can add the project A to the same solution as project B and then add the reference through the Projects tab of the Add Reference window.

TLiebe
See my edit on the startpost
Martijn
A: 

The error

The located assembly's manifest definition does not match the assembly reference.

suggests that a DLL was found but did not match the version, or public key. I would suggest double checking to ensure that the assembly reference matches the version information and that no rogue DLL's with old version numbers are located in the /bin paths or the GAC

Causas
A: 

Well, I guess to some extent it depends on what you are planning on doing once you've loaded the assembly, and what you've got in the assembly.

I'll assume you've got some sort of plugin architecture, with a known interface or base class that you're going to be calling methods on, lets say IPlugin.

Anyway, here's how to load an assembly dynamically, based on storing a reference to it in either a config section or a DB column somewhere:

private IPlugin LoadPlugin(string fullTypeName) {
  Type type = Type.GetType(fullTypeName, false, true);

  Object plugin = Activator.CreateInstance(type);

  if (plugin is IPlugin) {
    return (IPlugin) plugin;
  }

  // Handle the fact you've not got what you expected however you like
  throw new ApplicationException(error);
}

So this will take a string such as "projA.PluginClass, projA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" load the assembly, and return you an instance of the class you're interested in.

You would then use it like this:

// Call to DB to get details of class and assembly
string pluginClass = GetPluginDetails();

IPlugin plugin = LoadPlugin(pluginClass);

// Call known method to do something on IPlugin
plugin.SomeMethod();
Zhaph - Ben Duguid