尝试将其引用到其他项目中时出现dnlib库问题

Question

Using VisualStudio 2013 I've successfuly compiled the latest version of dnlib which is part of the ConfuserEx and de4dot projects, the dnlib project by default targets .NET Framework 2.0 so it should be compatible to reference it in other projects that targets a greater version but when I reference the resulting dnlib.dll in a new project that targets a .NET framework greater than 3.0 the project can't compile.

There is any compiling error information just a VisualStudio messagebox that says:

There were build errors. Would you like to continue and run the last successful build?

I've tried the dnlib.dll in a (new, empty) WinForms project using both the debug and the release version of dnlib.dll , I've tried targeting FW 3.5, 4.0, 4.5 and 4.5.1 but the project has been compiled successfuly only targeting FW 2.0 and 3.0.

By the other hand, I'm totally able to navigate through the library members and instance the classes inside and all that, but no way to compile a project with that referenced dnlib.dll .

I think that if the default FW targeting in the dnlib project is 2.0 should be for a good reason 'cause it touchs external assemblies and that, so I'm not sure to try to solve this issue by increasing the FW targeting in the dnlib project, but anyways I've tried to increase it to 4.0 to see what hapens and I get a lot of compiler errors about type defs in mscorlib.dll .

I'm missing something?

How I can solve this problem to be able to compile a project that targets FW4.0 with the dnlib.dll that targets FW2.0 referenced?

Answer 1

Ok, fiddling around, I could get some Warnings but not errors. As per MSDN, ExtensionAttribute came into being with Net 3.0 and HandleProcessCorruptedStateExceptionsAttribute with NET 4.0. So, in order to make the NET 2.0 code compatible with 4.0 projects, it provides the missing Attributes. The warnings are just that they are multiply defined, and since they are just Attributes, I don't think it matters.

Rather than comment them out, there are 2 easy ways to get rid of the Warnings.

Method 1 (better, I think): Create solutions for Net 2.0 and 4.0 builds.

Open the basic Net 2.0 solution. Select the Solution (dnlib) in Solution Explorer. On the File menu pick Save dnlib.sln As and use dnlib20.sln as the file name. This is your NET 2.0 FrameWork Solution.

Do Save As again, this time to dblib40.sln . This will be your Net 4.0 Framwwork solution in a moment. Switch both the console test project and dnlib library projects to Net 4.0 Target platform. Then, in Solution Explorer, exclude the last 2 files from the solution: HandleProcessCorruptedStateExceptionsAttribute.cs and ExtensionAttribute.cs . Save it, clean and build, and you should be good.

You don't need these 2 files because NET has them defined (which is the warning); they are only meant for 2.0 projects/solutions.

Note: You can also set it up so that the solutions compile to their own folders, so you dont get them confused. On the Build Tab, next output add a folder( ..\\Debug\\bin\\Net20 and ..\\Debug\\bin\\Net40 ). You'll have to change/update for both Debug and Release versions.

Method 2: Define some conditional compiler constants.

Create dblib20.sln and dblib40.sln solutions as above (unless you dont want to even use 2.0). Be sure to set the Framework to NET 4 in the 4.0 solution.

In the Net 2.0 dnlib project file, go to Project Properties --> Build --> General add the conditional compile symbol NET20 . Now, in HandleProcessCorruptedStateExceptionsAttribute.cs wrap the code there in a #if :

#if NET20

using System;
#pragma warning disable 1591    // XML doc warning

namespace System.Runtime.ExceptionServices {
    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
    sealed class HandleProcessCorruptedStateExceptionsAttribute : Attribute {
    }
}

#endif

In ExtensionAttribute.cs , do the same thing. Then Clean and Rebuild, and all should be well. Since the symbol is only defined in the NET20 solution, those classes will only be compiled when you use/open the Net 2.0 solution. If you download another update, you will have to redo this unless they provide a NET 4.0 solution file.

AFAIK, there still are not any built in FrameWork constants.

Finally, when those warnings are cleared away, there are 5 compare warnings, but from the looks of it, those can be ignored (the code seems to be doing what it wants).

Answer 2

This worked for me:

Change dnlib project's target version to .NET 4.0 Framework Client Profile. Change the Example project target version to .NET 4.0 Framework Client Profile. Remove/comment out ExtensionAttribute in ExtensionAttribute.cs in dnlib Remove/comment out HandleProcessCorruptedStateExceptionsAttribute in dnlib I then compiled and got no errors.

I used Visual Studio 2012.