4

I'm working with assembly.CreateInstance, and it returns null, while it was fine using it with a different project with the same DLL file "assembly file", Can you please suggest reasons when and why it returns null?Please this is urgent??

Edit

The type I'm searching for has a default constructor, but it implements another interface, like this. Project1, has the interface A and makes the DLL which contains the new type let it be typeB which implements A. Project2, has the same interface A and use the "CreateInstance" method to locate the type typeB, but here the CreateInstance returns null, any suggestions?

Lisa
  • 3,121
  • 15
  • 53
  • 85
  • 3
    You really should post some code - it is very difficult to guess at these things without seeing some code samples. – Oded Jun 27 '10 at 19:05
  • If `Project1` "has the interface A", and `Project2` "has the same interface A", then you have **two different** interfaces. See my answer for more info. All types, including interfaces, are defined by their assembly. – Marc Gravell Jun 27 '10 at 21:32

7 Answers7

7

I doubt it applies here, but there is 1 edge-case wher CreateInstance returns null (namely Nullable<T>), and one extreme corner-case (ProxyAttribute, discussed here) where a regular class can construct to null.

But more likely:

  • it doesn't exist (name wrong, perhaps)
  • you are using as, and the interface isn't implemented (perhaps the interface is declared in two different assemblies; it counts separately as different interfaces in each, even if the name and namespace are identical)

From the edit, it sounds like the last point; you should have the interface defined once only, and a reference between assemblies so that other assemblies can see (and implement) that interface.

Community
  • 1
  • 1
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • That's my mistake, having two different interfaces, I included that interface in a Class library and used the DLL in both projects and the worked perfectly thanks for the idea. – Lisa Jun 27 '10 at 21:56
4

The function returns a null if it cannot find the type specified or if the type does not have a default constructor. See the documentation on MSDN.

You need to make sure that your code is looking for the right assembly and type in the right place and that you have the appropriate permissions.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
3

Please see the documentation:

http://msdn.microsoft.com/en-us/library/aa329906(v=VS.71).aspx

It is returning null because the type you are passing in is not found. If you post your code perhaps we can be more specific!

Kieren Johnstone
  • 41,277
  • 16
  • 94
  • 144
0

A more reliable way to do this might be to use Activator.CreateInstance and pass in the type directly.

Dave
  • 900
  • 6
  • 22
0

As a follow up to the other replies, it can also occur because dependent assembly cannot be found (or loaded). Possible reasons include file not existing, different versions, strong name verification, permissions, etc.

cristobalito
  • 4,192
  • 1
  • 29
  • 41
0

You can try troubleshooting your issue by using Assembly Binding Log Viewer (fuslogvw) to try to see if there are any failed binds.

Randy Levy
  • 22,566
  • 4
  • 68
  • 94
-1

It just so happens that Assembly.CreateInstance will return null if it is called by a class that resides in the same assembly as the requested type. I guess the .NET folks thought you would never need to do such a thing, which was a very wrong assumption.

The Assembly.CreateInstance call must be made from a class residing outside the assembly that contains the object-type you are trying to create.

Go figure.

Mark Jones
  • 2,024
  • 1
  • 19
  • 12
  • Do you have a source backing this up? I'm curious to learn more. – Matt Jun 05 '16 at 18:36
  • This is trivially disprovable; sorry, but you are wrong. Whatever it is that you saw: the cause is not this. https://gist.github.com/mgravell/210673bfa7df0fddbe69ea50e6bd6fc8 - or, perhaps to be more generous: if there *is* a scenario in which it behaves this way, it is more nuanced and subtle than described here – Marc Gravell Mar 26 '18 at 10:20