4

I have a dll created in VS2010 using the 4.0 framework (yes it's the full 4.0, NOT the client profile). I would like to reference it in a VS2008 project (meaning I can't re-target the referencing project to 4.0 even if I wanted to) and upgrading that project to VS2010 is not an option.

I understand why there are issues with referencing 4.0 'projects' in 3.5 projects, but I don't understand why I should have a problem referencing a 4.0 dll in a 3.5 project. And for all I know this may not be the issue, but I can't seem to think of what else it could be.

I am trying to use Fasterflect (http://fasterflect.codeplex.com/) which relies heavily on 4.0 features in my 3.5 project (and again, my company is not ready to shell out the money for VS2010 so I can't change that). Everything seemed to be going okay at first until I tried to compile then errors about the Fasterflect assembly not being signed popped up. So I downloaded the actual source code, signed it, recompiled it, and referenced my newly signed assembly. The problem is that now it displays the caution symbol and says:

Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'C:....\Fasterflect.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

I tried following the answer suggested here: http://social.msdn.microsoft.com/Forums/en/clr/thread/36b1a209-55d5-4323-91dc-0919ba2e1d03. However, I get another error message when I do that:

Could not find schema information for the element 'supportedRuntime'. C:....\DynamicSql\App.config

And I can't seem to figure that error out either.

Surely there has to be SOME way for me to use this dll in VS2008??

Brandon Moore
  • 8,590
  • 15
  • 65
  • 120
  • I believe this is impossible, but I'm not sure. Let's wait for people who are more certain. – zmbq Mar 17 '12 at 06:32
  • @zmbq I wonder if it could be loaded dynamically? – Brandon Moore Mar 17 '12 at 06:33
  • I still believe this is impossible. But again, I'm not sure. – zmbq Mar 17 '12 at 06:37
  • or possibly even through COM... – Brandon Moore Mar 17 '12 at 06:41
  • If you put the two in two different processes it'll work. You could try two AppDomains, but I seriously doubt it'll work. – zmbq Mar 17 '12 at 06:43
  • 2
    The linked post just showed you can get it running by forcing your program to use the version 4 CLR with the .config file. What you can't do is get your program compiled. The 3.5 C# compiler cannot read the metadata of a 4.0 assembly, the format was changed. Debugging can't work either. – Hans Passant Mar 17 '12 at 06:56
  • Related: *[Can I develop for .NET Framework 4 in Visual Studio 2008?](http://stackoverflow.com/questions/1836410)* – Peter Mortensen Jul 22 '15 at 19:34

1 Answers1

7

When you create a project that targets a specific version of the framework, you're telling the compiler which version of the framework libraries and runtime that the computer on which the project will run has installed. For example, System.dll in 3.5 and System.dll in 4.0 aren't the same, much like why System.dll in 2.0 and 3.5 aren't the same.

In theory, you can't guarantee forwards compatibility (3.5 referencing a 4.0) because the 4.0 assembly may use APIs that aren't present in 3.5. Likewise, you can't guarantee 2.0 backwards compatibility in 4.0 because some of the APIs may have been deprecated and removed.

In practice, 4.0 has enough backwards compatibility with 3.5 that they allow you to reference 3.5 assembles in 4.0 applications, with some caveats (you sometimes need to add a directive in your configuration file, since assembly loading in 4.0 changed from 3.5). Unfortunately, 3.5 doesn't have much forwards compatibility with 4.0 due to the massive number of new APIs that 4.0 introduced, so I don't think that you can reference 4.0 assemblies from 3.5.

You're seeing that schema information exception for probably this reason. the "supportedRuntime" is a configuration element that was introduced with .NET 4.0. But since you're referencing the assembly in 3.5, the .NET 3.5 version of System.Configuration, which parses the configuration file, doesn't recognize that element and thus throws an exception.

The only way is probably to (1) change the source and re-compile, fixing all the API calls to 4.0 libraries that don't work in 3.5, or (2) do the same thing, but at the IL level, generating a new assembly (you can do this with al.exe).

atanamir
  • 4,833
  • 3
  • 24
  • 20
  • Thanks for the suggestions. Thankfully, I found out there was actually a version of the dll available that targeted the 3.5 framework. I just didn't think to look for one at first since I had seen the source code and it used the dynamic keyword and other 4.0 features and I didn't know they maintained another version of the sourcecode. – Brandon Moore Mar 18 '12 at 02:39